Re: CVE Request: PHP: out of bounds read crashes php-cgi

[Stanislav Malyshev <smalyshev () gmail com>]

Hi!

On 12/31/14 9:30 AM, cve-assign () mitre org wrote:
> > https://bugs.php.net/bug.php?id=68618 (out of bounds read crashes
> > php-cgi).
>
> > http://git.php.net/?p=php-src.git;a=commit;h=f9ad3086693fce680fbe246e4a45aa92edd2ac35
>
> Use CVE-2014-9427.
>
> Can you clarify what threat models exist that cross privilege
> boundaries? Bug #68618 says "could disclose server memory, but anyone

I'm not sure if it's exploitable at all. For starters, it requires
feeding arbitrary files to PHP - which means you already have the
equivalent of full shell access to the host in question as the user
running PHP. In theory, it can result in memory contents disclosure -
though since we're talking about mmap it requires the map used for this
file to be aligned just next to another one, otherwise it'd just segfault.

> that can upload php scripts can do far worse." Is the only relevant
> scenario that the attacker uploads a crafted .php file and thereby
> obtains read access (that would otherwise be unavailable) to memory
> locations within a parent process?

The potential for reading memory is for the php-cgi process, since CGI
is its own process. So the only data that can potentially be disclosed
is from the CGI process itself. Also, to result in disclosure and not
just segfault the attacker will need to somehow achieve that memory
beyond the region to which the file is mapped would be a valid memory
and contain something that PHP's lexer would interpret as a complete PHP
script (otherwise it'd just keep scanning until it hits unmapped memory
where it would segfault). I'm not saying it's not possible at all, but
it'd probably be very non-trivial to do this if possible. I'm pretty
sure none of it is possible without, as described above, the equivalent
of shell access under the user running PHP. So I'm not sure if there's
any privilege escalation anyway - maybe if PHP setup is very restricted
so no outside file/program access is possible.

> Or is it relevant that a victim may accidentally upload an
> incorrect .php file, and may expect that this is harmless, but the
> actual behavior is that PHP reads and executes out-of-bounds data that
> the victim did not wish to execute?

It's impossible with "accidental" script - it has to be specially made.
E.g. for the problem to happen the file has to start with '#' and have
no newlines (i.e. not be an actual PHP script).
-- 
Stas Malyshev
smalyshev () gmail com