libsafe broken by glibc-2.3.2?

(Yes, this is on topic because libsafe is a valuable and easy to install
system security tool, adding a little extra exploit protection to many
Linux servers.  I'm guessing that this will be problematic for many
people as they transition to glibc-2.3.2 based systems (latest RH,
Mandrake, SuSE, etc.), so it would be great if we can find a solution
quickly.)

The following was posted to Red Hat's shrike-list when I discovered what
I believe to be libsafe breakage due to changes in glibc-2.3.2.  Since
this post I have confirmed that it also crashes useradd in Mandrake 9.1,
further confirming my glibc cause suspicion rather than useradd.  My
debugging skills are poor so I ask for your expert opinion on this
question.  Thanks!

=== Original Message Below ===

libsafe stack protection library seems to have worked well enough as an
optional add-on to Red Hat 6.x through 8.0, but I am able to
consistently reproduce this segmentation fault on Red Hat Linux 9 with
libsafe.  This same operation works fine on Red Hat Linux 8.0.

[root@vserver:rh9 /]useradd temp2
Segmentation fault

http://www.research.avayalabs.com/project/libsafe/doc/libsafe.8.html
If you are not already familiar with libsafe, it intercepts calls to
several functions that are common causes of buffer overflows or format
string exploits, and replaces its functionality with a "safe" version.

Starting program: /usr/sbin/useradd temp3
 
Program received signal SIGSEGV, Segmentation fault.
strcmp () at ../sysdeps/i386/i686/strcmp.S:39
39      ../sysdeps/i386/i686/strcmp.S: No such file or directory.
        in ../sysdeps/i386/i686/strcmp.S
Current language:  auto; currently asm
(gdb) bt
#0  strcmp () at ../sysdeps/i386/i686/strcmp.S:39
#1  0x0804d16e in is_on_list (list=0x805fbe8, member=0x8064f30 "root")
at list.c:157
#2  0x0804aaf3 in grp_update () at useradd.c:870
#3  0x0804be78 in usr_update () at useradd.c:1760
#4  0x0804c55e in main (argc=-72539124, argv=0xbffff884) at
useradd.c:2121
#5  0x420156a4 in __libc_start_main (main=0x804c2d0 <main>, argc=2,
ubp_av=0xbffff884, init=0x80517d0 <__libc_csu_init>,
    fini=0x8051800 <__libc_csu_fini>, rtld_fini=0x40015920
<_rtld_local>, stack_end=0x8064f30)
    at ../sysdeps/generic/libc-start.c:193

*list is a pointer to a place in memory with another pointer address if
I understand the code correctly.  useradd crashes in strcmp() when *list
is given an erroneous memory address.  I stepped through this code using
the gdb with and w/o libsafe, and in the case without libsafe the memory
address pointed to zero (?), an acceptable value.  It appears that
libsafe is causing this memory mishap somewhere long before it reaches
this fatal strcmp(), but I didn't have enough time to locate the
decisive spot(s) yet.


http://www.fedora.us/pkglists/9/stable/libsafe-2.0-16.fdr.1.rh90.src.rpm.html
You can try it yourself with Fedora's libsafe package.  Be sure to read
the warnings and remove libsafe later.  You can quickly do testing of
the behavior of with and w/o libsafe by editing /etc/ld.so.preload and
commenting out the one line.  In order to get useful backtraces you will
need to recompile glibc and shadow-utils SRPMS and install the debuginfo
packages.  My test results were from:
glibc-2.3.2-27.9
shadow-utils-4.0.3-6
libsafe-2.0-16.fdr.1.rh90

Could some change in glibc-2.3.2 have broken an assumption that libsafe
makes (thus libsafe needs fixing) or is this exposing a potential flaw
in useradd?  This seems to be the only 100% reproducible libsafe induced
crash that I am able to find so far.

I am very curious about this odd behavior.  Thanks in advance!

-- 
Warren Togami                                   Fedora Linux Project
warren-ZewH/[email protected]                               http://www.fedora.us
GPG 0x54A2ACF1       3rd party packaging community for Red Hat Linux
785A 304B 08C1 F291 F54F  9A68 6BDD FE8E 54A2 ACF1
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers