|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2015-04-06 05:21 UTC] stas@php.net
-Assigned To:
+Assigned To: stas
[2015-04-14 07:29 UTC] stas@php.net
[2015-04-14 07:29 UTC] stas@php.net
-Status: Assigned
+Status: Closed
[2015-04-14 08:31 UTC] stas@php.net
[2015-04-15 08:43 UTC] jpauli@php.net
[2016-02-11 12:57 UTC] kaplan@php.net
-CVE-ID:
+CVE-ID: 2015-3411
[2016-02-11 12:57 UTC] kaplan@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Oct 26 15:00:01 2025 UTC |
Description: ------------ Having been inspired by CVE-2014-5120, I did a little digging and found a few more examples of PHP extensions which aren’t checking for null bytes when handling file paths. The exploitability varies a bit depending on what the extension is doing (and of course depends on application code allowing user input to control a partial path that’s supposed to have a particular suffix). Examples I’ve found are included below (likely non-exhaustive: some of the DB extensions appear to lack checks as well, but I didn’t build PoCs for them) Test script: --------------- <?php $doc = new DOMDocument(); $doc->load('/etc/fonts/fonts.conf' . chr(0) . 'somethingelse.xml’); echo $doc->saveXML(); <?php xmlwriter_open_uri('/tmp/thisisatest'. chr(0) . 'foobar.xml’); <?php $f=finfo_open(FILEINFO_NONE); echo finfo_file($f, '/etc/passwd' . chr(0) . 'foobar.txt’); <?php var_dump( hash_hmac_file('md5', '/etc/passwd', 'secret') === hash_hmac_file('md5', '/etc/passwd' . chr(0) . 'foobar', 'secret') ); Expected result: ---------------- Lots of warnings/errors about null bytes Actual result: -------------- Null byte causes truncation in path names, leading the functions to return results.