Description of problem: suPHP does bad things the first time you request a document that should return... --- Internal Server Error File "/home/life/rollercow/public_html/gallery/view_album.php" is not in document root of Vhost "/home/httpd/html" suPHP 0.6.1 --- type messages. Version-Release number of selected component (if applicable): mod_suphp-0.6.1-1.fc5 How reproducible: Every time Steps to Reproduce: 1. Install suphp 2. Try to access something in a user directory 3. Look at the error log Actual results: [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] *** glibc detected *** /usr/sbin/suphp: double free or corruption (fasttop): 0x0000000000534340 *** [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] ======= Backtrace: ========= [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /lib64/libc.so.6[0x395636d7a3] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /lib64/libc.so.6(__libc_free+0x84)[0x395636d924] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /usr/sbin/suphp[0x409fb8] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /usr/sbin/suphp[0x40a03d] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /usr/sbin/suphp[0x40a19f] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /usr/sbin/suphp[0x40a2eb] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /lib64/libc.so.6(exit+0xe5)[0x3956332405] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /lib64/libc.so.6(__libc_start_main+0xfb)[0x395631d08b] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] /usr/sbin/suphp(__gxx_personality_v0+0x79)[0x402fb9] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] ======= Memory map: ======== [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 00400000-00430000 r-xp 00000000 08:13 15574490 /usr/sbin/suphp [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 00530000-00533000 rw-p 00030000 08:13 15574490 /usr/sbin/suphp [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 00533000-00554000 rw-p 00533000 00:00 0 [heap] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956100000-3956119000 r-xp 00000000 08:13 4190434 /lib64/ld-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956219000-395621a000 r--p 00019000 08:13 4190434 /lib64/ld-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395621a000-395621b000 rw-p 0001a000 08:13 4190434 /lib64/ld-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956300000-395643f000 r-xp 00000000 08:13 4190435 /lib64/libc-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395643f000-395653f000 ---p 0013f000 08:13 4190435 /lib64/libc-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395653f000-3956543000 r--p 0013f000 08:13 4190435 /lib64/libc-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956543000-3956544000 rw-p 00143000 08:13 4190435 /lib64/libc-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956544000-3956549000 rw-p 3956544000 00:00 0 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956800000-3956880000 r-xp 00000000 08:13 4190437 /lib64/libm-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956880000-3956980000 ---p 00080000 08:13 4190437 /lib64/libm-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956980000-3956981000 r--p 00080000 08:13 4190437 /lib64/libm-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 3956981000-3956982000 rw-p 00081000 08:13 4190437 /lib64/libm-2.4.so [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395d900000-395d90d000 r-xp 00000000 08:13 4190438 /lib64/libgcc_s-4.1.0-20060304.so.1 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395d90d000-395da0d000 ---p 0000d000 08:13 4190438 /lib64/libgcc_s-4.1.0-20060304.so.1 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395da0d000-395da0e000 rw-p 0000d000 08:13 4190438 /lib64/libgcc_s-4.1.0-20060304.so.1 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395f500000-395f5e9000 r-xp 00000000 08:13 15566131 /usr/lib64/libstdc++.so.6.0.8 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395f5e9000-395f6e8000 ---p 000e9000 08:13 15566131 /usr/lib64/libstdc++.so.6.0.8 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395f6e8000-395f6ee000 r--p 000e8000 08:13 15566131 /usr/lib64/libstdc++.so.6.0.8 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395f6ee000-395f6f1000 rw-p 000ee000 08:13 15566131 /usr/lib64/libstdc++.so.6.0.8 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 395f6f1000-395f703000 rw-p 395f6f1000 00:00 0 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 2aaaaaaab000-2aaaaaaad000 rw-p 2aaaaaaab000 00:00 0 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 2aaaaaabc000-2aaaaaabf000 rw-p 2aaaaaabc000 00:00 0 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 2aaaaab00000-2aaaaab21000 rw-p 2aaaaab00000 00:00 0 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 2aaaaab21000-2aaaaac00000 ---p 2aaaaab21000 00:00 0 [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] 7fffffa16000-7fffffa2b000 rw-p 7fffffa16000 00:00 0 [stack] [Fri May 19 16:37:13 2006] [error] [client 137.44.10.6] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] Expected results: No glibc error Additional info:
Which apache version are you using?
The stock FC5 apache: httpd-2.2.0-5.1.2
glibc wasn't wrong. valgrind agrees too (when running suphp from the command line where it spits out an error). Patch to come:
Thx a lot. I've been trying to reproduce this and found the same error. However, I couldn't really find the reason for the double free yet. A patch would be greatly appreciated.
Created attachment 131147 [details] A hard won patch for the double free error (I'm new to C++ - I just started doing it yesterday so this patch could well be wrong) The problem appears to stem from the "static initialization order fiasco" (see http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 ). SmartPtr uses the std::map object internally but when a SmartPtr object is made in a static scope there is a chance that other object destructors will have been called before SmartPtr's destructor. Thus when SmartPtr goes to use std::map's find in its destructor there's a chance that either std::map or possibly the pairs inside the map have already been deleted causing an invalid read. glibc doesn't notice this. When the freed object is returned by the find, SmartPtr goes and tries to free the returned item again causing the double free (which glibc does notice). The change I made was to use a static pointer to an object so that SmartPtr's destructor is called when all the other regular objects' destructors are called rather than when the static classes' destructors are called (all non static object destructors always seem to be called before static objects or classes' destructors).
Created attachment 131148 [details] Updated specfile (watch out for the FC5 define at the top!) (Side note. I'm mildly worried about how complex suphp is. If subtle bugs like this are cropping up what other horrors might be lying in wait? I wish it were simpler C but I guess this C++ version doesn't leak any memory...) While I'm here, here's an updated specfile that tightens up the permissions and ownership on the suexec binary so that they are similar to those of suexec and less likely to be exploitable. Also adds a changelog entry and forces a define at the top for FC5 (which probably needs to be removed). It would be nice if things could be reworked slightly so that a plain old make works because inbetween that define and needing to make suphp I found compiling this RPM rather frustrating...
(In reply to comment #6) > While I'm here, here's an updated specfile that tightens up the permissions and > ownership on the suexec binary so that they are similar to those of suexec and > less likely to be exploitable. Uhm, you're changing the permissions to 4550, root, apache instead of 4755, root, root. The Owner change is actually a good idea, but why 550? that would make the binary not executable. > Also adds a changelog entry and forces a define at the top for FC5 (which > probably needs to be removed). It would be nice if things could be reworked > slightly so that a plain old make works because inbetween that define and > needing to make suphp I found compiling this RPM rather frustrating... Sorry. This is problematic as the spec should be compilable on FC3 to rawhide. What you could do however is call rpmbuild --rebuild --define "fedora 5" mod_suphp-0.6.1-2.src.rpm That way, you do not need to hardcode fedora 5 in the .spec.
OK thanks for the --define (I'm just lazy and couldn't find the correct thing in man rpmbuild). However it might be nice to make the default case the one that compiles it correctly on the newest FC. > Uhm, you're changing the permissions to 4550, root, apache instead of 4755, > root, root. > The Owner change is actually a good idea, but why 550? that would make the > binary not executable. Check your octal. The perms should come out as -r-sr-x--- (i.e. setuid root, and executable by only root and apache group). Since httpd runs within the apache group that means the number of people who can run the setuid binary has been restricted somewhat to those who actually need to run it.
This bug and a couple of others have been fixed in the upstream version 0.6.2