sshd does not properly initialize libgcrypt

Bug #1397666 reported by Pieter H
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

The following warnings can be found in syslog:

pieter-local@test-02:~$ grep "please fix the application" /var/log/syslog |grep sshd
Nov 30 12:19:21 test-02 sshd[1226]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 12:20:06 test-02 sshd[1293]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 12:24:27 test-02 sshd[1089]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 12:40:34 test-02 sshd[1257]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 12:40:58 test-02 sshd[1324]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 12:41:36 test-02 sshd[1403]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 13:16:30 test-02 sshd[1095]: Libgcrypt warning: missing initialization - please fix the application
Nov 30 13:16:46 test-02 sshd[1228]: Libgcrypt warning: missing initialization - please fix the application

These seem to be related to the following change:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff_plain;h=7627f9646701e88c827bbadd1231221d5f0c89a6

It looks like that sshd does not properly initialize libgcrypt. From looking at the above patch, it does not seem to do any harm, since the lib will then initialize itself. When trying to find issues on a system, warnings like this will make things a bit more cloudy then needed. A proper implementation for this would be beneficial to the system in general.

These warnings are present in 14.04.

Revision history for this message
Pieter H (ubuntu-low) wrote :
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to file this bug and helping to make Ubuntu better.

I cannot reproduce this on Trusty. Additionally, I don't see that the openssh-server or openssh-client binary packages pull in gcrypt at all. Are you sure this isn't some PAM module that uses gcrypt that ssh is simply calling due to its configuration? This would explain sudo as well.

Please could you post steps to reproduce this bug on a fresh 14.04 installation and then change the bug status back to New?

Changed in openssh (Ubuntu):
status: New → Incomplete
Revision history for this message
Pieter H (ubuntu-low) wrote :

thanks for the quick response... well.. it is sort of a clean trusty install. but.. with the first things being installed are kerberos and some pam modules ;-) Your remark about the pam module makes sense.

in short.. I installed the debug symbols of packages that interested me. Installed dbg and setup sshd on a different port. started a new ssh session, started the debugger and attached it to the process serving my new session. added a breakpoint on global_init and logged in with the session.. the breakpoint was hit ;-)

below the backtrace. so I guess I found the module responsible for this.. unfortunately I was not able to find any debug packages for libpam-ccreds (version 10-6)... so how to continue.. is there any way I can get the debug symbols for this package and narrow down to the functions being involved? or is this information below enough?

#0 global_init () at global.c:100
#1 0x00007f6e26a991b1 in _gcry_global_is_operational () at global.c:169
#2 0x00007f6e26a97c31 in gcry_md_open (h=0x7fffd2ab1d08, algo=2, flags=0) at visibility.c:771
#3 0x00007f6e26d0fa3e in ?? () from /lib/security/pam_ccreds.so
#4 0x00007f6e26d0fced in pam_cc_store_credentials () from /lib/security/pam_ccreds.so
#5 0x00007f6e26d10989 in ?? () from /lib/security/pam_ccreds.so
#6 0x00007f6e26d10f80 in pam_sm_authenticate () from /lib/security/pam_ccreds.so
#7 0x00007f6e2abdcdff in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#8 0x00007f6e2abdc64d in pam_authenticate () from /lib/x86_64-linux-gnu/libpam.so.0
#9 0x00007f6e2b24ad76 in ?? ()
#10 0x00007f6e2b2296eb in ?? ()
#11 0x00007f6e2b23dc2a in ?? ()
#12 0x00007f6e2b240b91 in ?? ()
#13 0x00007f6e2b241a94 in ?? ()
#14 0x00007f6e2b226ae3 in ?? ()

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.