OpenSSH 4.0p1 segfaults on keyboard-interactive login

[Darren Tucker]

Andreas M. Kirchwitz wrote:
> Please don't laugh, but the mere existance of the directory
> "/var/empty/sshd/lib" is sufficient to make Fedora Core 2 happy.
> (I started with a complete copy of /lib and removed the libraries
> step by step to see which one I need. And to my surprise, I could
> safely delete everything except the "lib" directory itself.)

It's reproducable with a minimal test case, and it's definitely deep in 
libc.  It's been confirmed to be a known problem in glibc, but the fix 
does not seem to have made it to a released rpm yet.  In the mean time, 
the workaround is to create /var/empty/lib.

References:
https://bugzilla.redhat.com/beta/show_bug.cgi?id=144303
http://sources.redhat.com/ml/libc-hacker/2005-02/msg00005.html

$ cat chroot-dns-test.c
#include <stdio.h>
#include <netdb.h>

int
main(void)
{
         chroot("/tmp");
         chdir("/");
         gethostbyname("foo");
}

$ gcc -g chroot-dns-test.c
$ sudo gdb -q ./a.out
Using host libthread_db library "/lib/tls/i686/libthread_db.so.1".
(gdb) run
Starting program: /home/dtucker/a.out

Program received signal SIGSEGV, Segmentation fault.
open_path (name=0xbff34b30 "libnss_dns.so.2", namelen=16, preloaded=0,
     sps=0x955ed0, realname=0xffffffff, fbp=0xbff345c4) at dl-load.c:1791
1791          sps->dirs = (void *) -1;
(gdb) bt
#0  open_path (name=0xbff34b30 "libnss_dns.so.2", namelen=16, preloaded=0,
     sps=0x955ed0, realname=0xffffffff, fbp=0xbff345c4) at dl-load.c:1791
#1  0x00948630 in _dl_map_object (loader=0x9564e0,
     name=0xbff34b30 "libnss_dns.so.2", preloaded=0, type=2, trace_mode=0,
     mode=-1879048191, nsid=0) at dl-load.c:1961
#2  0x00a3b516 in dl_open_worker () from /lib/tls/i686/libc.so.6
#3  0x0094cbd1 in _dl_catch_error (objname=0xbff349a0, errstring=0xbff349a4,
     operate=0xa3b41c <dl_open_worker>, args=0xbff349a8) at dl-error.c:161
#4  0x00a3c0a9 in _dl_open () from /lib/tls/i686/libc.so.6
#5  0x00a3d3ad in do_dlopen () from /lib/tls/i686/libc.so.6
#6  0x0094cbd1 in _dl_catch_error (objname=0xbff34aec, errstring=0xbff34af0,
     operate=0xa3d398 <do_dlopen>, args=0xbff34af4) at dl-error.c:161
#7  0x00a3d461 in __libc_dlopen_mode () from /lib/tls/i686/libc.so.6
#8  0x00a1d611 in __nss_lookup_function () from /lib/tls/i686/libc.so.6
#9  0x00a1d711 in __nss_lookup () from /lib/tls/i686/libc.so.6
#10 0x00a1ed42 in __nss_hosts_lookup () from /lib/tls/i686/libc.so.6
#11 0x00a21788 in gethostbyname_r@@GLIBC_2.1.2 () from /lib/tls/i686/libc.so.6
#12 0x00a21154 in gethostbyname () from /lib/tls/i686/libc.so.6
#13 0x08048421 in main () at chroot-dns-test.c:9

 > Do you have any idea what code change from OpenSSH 3.9p1 to 4.0p1
 > may have triggered this strange bug in system libraries? Especially
 > the workaround with "mkdir /var/empty/sshd/lib" is, hmmm, confusing.

It's probably just a DNS lookup somplace where there wasn't previously. 
It could be something as simple as a debug() call.

 > Hopefully, this isn't a general security risk for applications that
 > do nameservice lookups within a chroot'ed environment.

I don't think it is.  The description I got was that the segfault is 
caused because libc attempts to write to a segment mapped readonly.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.