[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0604131959460.29954@dione>
Date: Thu, 13 Apr 2006 20:20:45 +0200 (CEST)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: "Steven M. Christey" <coley@...re.org>, 86400s@...im.net
Cc: bugtraq@...urityfocus.com
Subject: Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2
Steven M. Christey wrote:
> 3) One does not expect an interpreted language to segfault
Behavior of an application in resource exhaustion scenarios is, for
objective reasons, quite hard to handle. There might be no stack available
to invoke an error handling routine, there might be no memory for I/O
libraries to allocate necessary buffers, etc. Memory regions may collide.
For this reason, I would be extremely careful before making such a
statement. Programs can't be reasonably expected to always die gracefully
in such conditions.
But don't get me wrong, Steven - I was merely making a half-baked joke. I
have no strong objection to this being classified as a new vulnerability
(as opposed to "homebrew programs may crash when the author writes them so
that they allocate more resources than they're allowed to", which may seem
more appropriate to some).
Gael Delalleau wrote:
> 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.
Indeed, on systems that do not properly guarantee stack / heap separation,
this is a problem, but probably not with PHP as such; it seems to be hard
for a specific application to know this and take precautions without going
very platform-specific.
/mz
Powered by blists - more mailing lists