[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 3 Jan 2015 00:57:44 -0500 (EST)
From: cve-assign@...re.org
To: smalyshev@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: PHP: out of bounds read crashes php-cgi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> Use CVE-2014-9427.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9427
now has this.
> ... 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.
The main threat model is exactly this scenario that you've described,
except that the person with shell access is the victim, not the
attacker. This person intentionally uploads a one-character # file,
but does this because of an oversight (e.g., they hadn't properly
saved the file in a text editor). The person would reasonably expect
that, if an attacker then visits the URL for this file, the php-cgi
process would either print the # character or print nothing. (The
attacker happens to know the URL, or maybe guesses that one-character
# files often have a "test.php" filename.) A security impact could
occur if, when the attacker visits this URL, something else happens,
excluding a crash. First, the php-cgi process could print characters
that were not actually present in the uploaded file. Second (and the
more general case for data sent to the php_execute_script function),
the php-cgi process could execute PHP code that was not actually
present in the uploaded file.
We agree that your "somehow achieve that memory ..." requirement is
necessary for each of those security impacts. However, the unpatched
code does appear to move on to data corruption fairly soon. The
purpose of the code is to skip past a #!/usr/bin/php line and arrange
for the buffer to start at the beginning of the next line of the .php
file. If there's an invalid file with no '\n' character, the code can
(at least for a theoretically possible architecture and memory layout)
reach the "file_handle.handle.stream.mmap.buf += i" and
"file_handle.handle.stream.mmap.len -= i" lines. This len is a size_t
and nothing prevents i from being larger than this len value.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJUp4QiAAoJEKllVAevmvmsEOoH/inxXnd64CP8G5EoRvZ4JcdV
opgYo7QHm+0l8mZ/rHzef5n/E/l/jhVLMMA73iYMKFJlwF+lQow4rbZ1ukj7tmNg
7FDh3C3lFrflJoWpfi5DhGv9NLvvuUzvEHqq5UyQdIab7Ogcixn6YnEm8qFUUozp
kq4BbozQfEkGblW/0DRxh+/Jl0Yv5///4AILvM9dayI/R5H5l99x1gJguWITXsM1
sQmcwzsg076hOHP+cDfs80W/mB4ZQ7GPoltwhuqavjXeL1pF1AE7+il+4oHMfRT1
taIgIinuF2qigm1FYl94JExR4Q/PZRIT280gNprGm+28c71iMTK9orfrjrGzVj4=
=ZBxF
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
