Bugtraq mailing list archives
Exploiting out of memory crashes and null pointers [was: Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2]
From: 86400s () nerim net
Date: Wed, 12 Apr 2006 21:23:56 +0200 (CEST)
Additionally, people who attended my talk at the CanSecWest event last year may remember that it is possible (although not trivial) to exploit this kind of "out of memory crash" bug to actually run arbitrary code on some operating systems. This is explained in the slides at : http://cansecwest.com/core05/memory_vulns_delalleau.pdf For those interested, please note that in this research I also talked about other new results like NULL pointer exploitation, jumping the stack gap, mapping overflows, etc. The slide titled "Heap / Stack overlap Demo : exploiting mod_php 4.3.0 on Apache" seems most relevant as it presents the concept of such an exploit for Linux 2.6 systems. An actual proof-of-concept exploit code (running a shellcode from a PHP script by allocating large amounts of heap memory, then calling a recursive function to make the stack and heap overlap, and finally writing in the heap blocks to overwrite a saved EIP address on the stack) can be found at page 17 of the french article on this topic published for the SSTIC conference : http://actes.sstic.org/SSTIC05/Vulnerabilites_et_gestion_des_limites_memoire/ Note (and this is very infortunate) that one year after I published these results, I am not aware of any vulnerable system or application which (at least publicly) patched some of these issues. I can even remember that Linux developpers decided not to patch the issues, despite of my various discussions with them. Maybe this answer to a Bugtraq post will make some people start to move to patch these issues... Cheers, Gael Delalleau
Michal Zalewski asked:...but how come there's no CVE entry for the bash script in my signature?To which I'll answer the underlying question, i.e. "why assign a CVE identifier to what appears to be a non-vulnerability?" 1) To clarify: while we changed the CVE naming scheme in October 2005 so that the "CAN" prefix is no longer used, there is still a conceptual difference between candidates and entries. The number in the advisory was (and is) a candidate [1]. Any candidate can be rejected in the future if there is sufficient dispute - along with a record of the dispute itself. 2) The candidate number was reserved pre-disclosure; the researcher is responsible for verifying the issue and working with the vendor before disclosure. SecurityReason can clarify the nature of their interaction with PHP, and their rationale for publishing this issue. 3) One does not expect an interpreted language to segfault, and there have been enough issues in the past couple years in which people have casually dismissed resource-focused "DoS" attacks that turned out to be buffer overflows, array index errors, or other memory corruption problems. This can only be proven with deeper analysis; the simplicity of an attack is not evidence itself, as your own research recently highlighted with an obvious attack on script handlers in IE, which exposed a much more interesting vulnerability underneath. 4) SecurityReason's advisory does not state the specific impact of the issue. However, what if the entire Apache server could be caused to crash? If the server is supporting multiple users, then this is not just a self-DoS. The vulnerability becomes context-dependent. 5) Interpreted languages could conceivably be held to a higher security standard than applications written in those languages. Suppose that this segfault is actually exploitable in some sense. If a PHP application can be manipulated into making recursive calls, then it might become exploitable - remotely if the application happens to be remotely accessible. Recall the the Perl interpreter format string vulnerability, which is also context-dependent since it depends on the existence of vulns in Perl apps to even succeed. 6) The scenarios listed in (3) through (5) might seem unlikely, but not impossible. Without deeper analysis, we cannot be sure. - Steve [1] Note: the distinction between candidates and entries is currently blurred and under review, since the old process of voting became too unwieldy due to the growing volume of candidates.
Current thread:
- function *() php/apache Crash PHP 4.4.2 and 5.1.2 cxib (Apr 10)
- Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2 Michal Zalewski (Apr 11)
- <Possible follow-ups>
- Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2 Steven M. Christey (Apr 12)
- Exploiting out of memory crashes and null pointers [was: Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2] 86400s (Apr 12)
- Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2 Michal Zalewski (Apr 13)
- Re: Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2 sp3x (Apr 14)