Bug 192415 - suphp: double free says glibc
suphp: double free says glibc
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: mod_suphp (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Andreas Thienemann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-19 11:44 EDT by Chris Jones
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-08 14:23:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A hard won patch for the double free error (1.91 KB, patch)
2006-06-19 14:01 EDT, Sitsofe Wheeler
no flags Details | Diff
Updated specfile (watch out for the FC5 define at the top!) (4.17 KB, text/plain)
2006-06-19 14:08 EDT, Sitsofe Wheeler
no flags Details

  None (edit)
Description Chris Jones 2006-05-19 11:44:33 EDT
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:
Comment 1 Andreas Thienemann 2006-05-23 20:44:42 EDT
Which apache version are you using?
Comment 2 Sitsofe Wheeler 2006-05-24 03:13:40 EDT
The stock FC5 apache:
httpd-2.2.0-5.1.2
Comment 3 Sitsofe Wheeler 2006-06-19 13:48:16 EDT
glibc wasn't wrong. valgrind agrees too (when running suphp from the command
line where it spits out an error). Patch to come:
Comment 4 Andreas Thienemann 2006-06-19 13:53:08 EDT
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.
Comment 5 Sitsofe Wheeler 2006-06-19 14:01:31 EDT
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).
Comment 6 Sitsofe Wheeler 2006-06-19 14:08:27 EDT
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...
Comment 7 Andreas Thienemann 2006-06-19 14:21:26 EDT
(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.
Comment 8 Sitsofe Wheeler 2006-06-19 15:24:36 EDT
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.
Comment 9 Chris Jones 2007-01-12 08:15:56 EST
This bug and a couple of others have been fixed in the upstream version 0.6.2

Note You need to log in before you can comment on or make changes to this bug.