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-ha.../msg00005.html

$ cat chroot-dns-test.c
#include
#include

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 , 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 , 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.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev