libsafe broken by glibc-2.3.2?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx: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@xxxxxxxxxx                               http://www.fedora.us
GPG 0x54A2ACF1       3rd party packaging community for Red Hat Linux
785A 304B 08C1 F291 F54F  9A68 6BDD FE8E 54A2 ACF1

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Fedora Users]     [Centos Users]     [Kernel Development]     [Red Hat Install]     [Red Hat Watch]     [Red Hat Development]     [Red Hat Phoebe Beta]     [Yosemite Forum]     [Fedora Discussion]     [Gimp]     [Stuff]     [Yosemite News]

  Powered by Linux