Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
There are multiple ways to cause segfaults in php, not sure whether local code execution is possible as well (1., 2. and 3. look like it could be possible to execute code): 1. stream_wrapper_register() crashes with long strings passed as second argument [1], no upstream fix yet, I might try to fix it myself I discovered that this affects a lot more functions (all functions in PHP which take a class name?), for example: is_subclass_of(), get_class_vars(), class_exists(), property_exists(), get_class_methods() and probably many more 2. gettext: multiple crash issues with long strings [2], no upstream fix yet 3. xmlrpc_server_call_method() crash [3], fixed by upstream, patch already part of our next patchset 4. multiple getopt() crashes [4] 5. php security limit (safe_mode etc.) bypass through mbstring I don't have any details; no upstream fix yet, mattiasb offered to give us a patch 6. php -r 'trigger_fatal_error();' crashes php as well. This only works on CLI and is probably not a big security issue. It also seems to be not a bug in php itself but in one of our patches :( This is mainly a tracker bug for myself for now, but you (as in: security) should know about it as well, of course. Restricting as some of the bugs are not public yet. Disclaimer: It's not my fault that this happens right after php-5.2.5 release. Somehow all those bugs appear right after new releases... :) [1] http://www.securityfocus.com/archive/1/483644/30/0/threaded [2] http://www.securityfocus.com/archive/1/483648/30/0/threaded [3] http://bugs.php.net/bug.php?id=42736 [4] http://bugs.php.net/bug.php?id=43293
Regarding 1): I'm unable to fix the long-class-name-thing myself, filed upstream bug http://bugs.php.net/bug.php?id=43298
more issues with PHP: http://secunia.com/advisories/27648/
(In reply to comment #2) > more issues with PHP: > http://secunia.com/advisories/27648/ According to hoffie, those are already fixed in our stable 5.2.4_p*
Some status updates: 1. This looks like a pretty severe problem. Apparently it *is* possible to execute code locally (and remotely if any web app takes a user-supplied class name, I guess), and the fix does not seem to be easy. Upstream does not seem very keen on getting this fixed, see [1]. So: No fix until now; that means it's probably possible to circumvent all php security restrictions (safe_mode, open_basedir etc.) 2. Still no fix 4. Clarification: We have a patch for that in the overlay (from upstream) 5. no updates 6. had no time to track it down New: 7. Fixed bug #43092 (curl_copy_handle() crashes with > 32 chars long URL) patch in overlay (from upstream), couldn't reproduce it, maybe win32-specific 8. Fixed bug #43301 (mb_ereg*_replace() crashes when replacement string is invalid PHP expression and 'e' option is used) patch in overlay (from upstream) (In reply to comment #3) > (In reply to comment #2) > > more issues with PHP: > > http://secunia.com/advisories/27648/ > > According to hoffie, those are already fixed in our stable 5.2.4_p* Yes, I'm pretty sure they were -- even if not, 5.2.5 (final) should have fixed them (as secunia and the official ChangeLog say) and 5.2.5 is stable anyway. Security, I can package a new patchset / revision whenever you want. Personally I would like to wait for a fix for 1), but it's up to you. (Forgot that php-bugs@ in CC doesn't mean that everyone from PHP herd can see it, sorry jakub. also CC'ing CHTEKK now)
CVE assigned a name to issue (1). CVE-2007-6039 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6039): PHP 5.2.5 and earlier allows context-dependent attackers to cause a denial of service (application crash) via a long string in (1) the domain parameter to the dgettext function, the message parameter to the (2) dcgettext or (3) gettext function, the msgid1 parameter to the (4) dngettext or (5) ngettext function, or (6) the classname parameter to the stream_wrapper_register function. NOTE: this might not be a vulnerability in most web server environments that support multiple threads, unless this issue can be demonstrated for code execution.
Short status update... I hacked up a patch for issue #1 and sent it upstream. I want to wait on their feedback (if possible). There were some other crash bugs in the meantime, I will post a full status report in the next two days.
Ok, php-5.2.5-r1 is in the tree. The following issues are FIXED: 1. stream_wrapper_register() crashes with long strings passed as second argument, also affects a lot more functions (all functions in PHP which take a class name?), for example: is_subclass_of(), get_class_vars(), class_exists(), property_exists(), get_class_methods() and probably many more; CVE-2007-6039 (partly) 3. xmlrpc_server_call_method() crash 4. multiple getopt() crashes 7. phpbug #43092 (curl_copy_handle() crashes with > 32 chars long URL) 8. Fixed bug #43301 (mb_ereg*_replace() crashes when replacement string is invalid PHP expression and 'e' option is used) 9. phpbug #42978 pdo_pgsql bound param mismatch crash 10. phpbug #43377 DateTimeZone invalid arg crash 11. phpbug #43386 uninitialized array_globals (unverified possible crash) 12. uninitialized sapi_headers.mimetype (unverified possible crash) 13. phpbug #43495 array_merge_recursive() crash So we fixed 10 bugs, with all of them being (possible) crash bugs and no verification whether it is possible to (locally) execute code. Not sure what we should do about the bug -- keep it restricted? The initial reason for restricting it was issue #5 as it was (and still is) non-public. On the other hand there are no details about it in this bug, so I guess unrestricting would be OK if it makes it easier for stabling... I will open a new bug for the unfixed issues tomorrow (or you can do if you want). php-5.2.5-r1 should be ready to stable, but better wait until Sunday evening at least so we can get some more testers (the patch for issue #1 is pretty intrusive and is no official patch (yet)).
All issues which I mentioned in comment #7 are now being handled in bug 201885. That means the following issues are left unfixed (I'm restarting numbering, it gets too confusing otherwise): 1. gettext: multiple crash issues with long strings (was: #2), no upstream fix 2. php security limit (safe_mode etc.) bypass through mbstring (was: #5) still no fix and no details 3. php -r 'anything_which_triggers_fatal_error();' crashes php. This only works on CLI and is probably not a big security issue. Gentoo-specific, still not tracked down. (was: #6)
(In reply to comment #8) > 1. gettext: multiple crash issues with long strings (was: #2), no upstream > fix Still didn't find any updates. > 2. php security limit (safe_mode etc.) bypass through mbstring (was: #5) > still no fix and no details Mattias? =) > 3. php -r 'anything_which_triggers_fatal_error();' crashes php. > This only works on CLI and is probably not a big security issue. > Gentoo-specific, still not tracked down. (was: #6) This one turned out to be a general problem and not Gentoo-specific. It was related to GCC over-optimization and is fixed (or rather workarounded) in >=php-5.2.5_p20080206.
Ok, i misinterpreted that -- the issue Mattias pointed out to me was about mcrypt, not mbstring. Basically this issue allows loading arbitrary libraries (probably as long as they match a certain structure) and as such bypassing php's security restrictions (safe_mode, open_basedir, ...) as it is possible to execute arbitrary code (locally). For all this to happen, libmcrypt needs to be compiled with --enable-dynamic-loading, which is never the case on Gentoo. As such, this is not a vulnerability for us. Mattias agreed that it is ok to open the bug, he notified upstream weeks ago and they seem to ignore it, so someone please unrestrict it (apparently I miss privs to do that). There is still one issue left (gettext). Yes, it's still unfixed, I'll see about investigating a bit in the near future. Do we still want to handle that in this huge tracker bug or rather file an individual one?
gettext: http://bugs.php.net/bug.php?id=44938
Hoffie, any news here? some of these vulns were probably fixed with GLSA 200811-05.
(In reply to comment #10) > [...] > Mattias agreed that it is ok to open the bug, he notified upstream weeks ago > and they seem to ignore it, so someone please unrestrict it (apparently I miss > privs to do that). > done.
So, URL in comment #11 states it's been fixed in CVS on 10/30/2008. Hoffie, did it make it into 5.2.6-r6? In which case we could finally close as it's covered with GLSA 200811-05.
(In reply to comment #11) > gettext: http://bugs.php.net/bug.php?id=44938 FYI, this appears to have been fixed in current stable release: my php-5.2.8-r1 seems unaffected.
(In reply to comment #15) > (In reply to comment #11) > > gettext: http://bugs.php.net/bug.php?id=44938 > FYI, this appears to have been fixed in current stable release: my php-5.2.8-r1 > seems unaffected. Right. Somehow I forgot to comment here.. Closing. Covered by GLSA 200811-05.
