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
