php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Sec Bug #77431 openFile() silently truncates after a null byte
Submitted: 2019-01-08 15:21 UTC Modified: 2019-03-16 13:33 UTC
From: 64796c6e69 at gmail dot com Assigned: stas (profile)
Status: Closed Package: SPL related
PHP Version: 7.1.26 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: 64796c6e69 at gmail dot com
New email:
PHP Version: OS:

 

 [2019-01-08 15:21 UTC] 64796c6e69 at gmail dot com
Description:
------------
openFile() silently truncates anything after a null byte in a string. The suffix used for SplFileInfo is completely lost.

This happens in older versions as far as I tested.

Test script:
---------------
echo bad >badfile.txt
php -r 'var_dump((new SplFileInfo("badfile.txt\0goodfile.txt"))->openFile("r")->fread(3));'

Expected result:
----------------
An error about the file not existing or the null byte.

Actual result:
--------------
string(3) "bad"

Patches

fix-77431 (last revision 2019-01-09 13:29 UTC by cmb@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-01-08 19:11 UTC] 64796c6e69 at gmail dot com
Without command line:
----------------
<?php
$file = "../../../../../../../../../../etc/passwd\0.txt";
var_dump((new SplFileInfo($file))->openFile("r")->fread(4));

Actual result:
----------------
string(4) "root"
 [2019-01-09 13:29 UTC] cmb@php.net
-Status: Open +Status: Verified -Package: Filesystem function related +Package: SPL related
 [2019-01-09 13:29 UTC] cmb@php.net
Thanks for reporting!  I can confirm the issue.  However, I think
that the constructor should throw an exception in the first place
if a string containing NUL bytes is passed, analogous to
`SplFileObject::__construct()`.
 [2019-01-09 13:29 UTC] cmb@php.net
The following patch has been added/updated:

Patch Name: fix-77431
Revision:   1547040579
URL:        https://bugs.php.net/patch-display.php?bug=77431&patch=fix-77431&revision=1547040579
 [2019-01-09 13:30 UTC] cmb@php.net
-Assigned To: +Assigned To: stas
 [2019-01-09 13:30 UTC] cmb@php.net
Stas, can you please take it from here?
 [2019-01-09 14:53 UTC] 64796c6e69 at gmail dot com
I completely agree. It may also make sense to reject empty paths for consistency with SplFileObject and fopen(). SplFileInfo::openFile() already throws an exception in that case, but since an empty path is never valid, I would think it makes more sense for that to happen in the constructor.

php -r 'new SplFileObject("");'
Fatal error: Uncaught RuntimeException: SplFileObject::__construct(): Filename cannot be empty in Command line code on line 1

php -r 'fopen("", "r");'
Warning: fopen(): Filename cannot be empty in Command line code on line 1
 [2019-02-06 14:50 UTC] 64796c6e69 at gmail dot com
Are there any updates on this bug?
 [2019-03-04 02:24 UTC] stas@php.net
-PHP Version: master-Git-2019-01-08 (Git) +PHP Version: 7.1.26
 [2019-03-04 02:24 UTC] stas@php.net
-Status: Verified +Status: Assigned
 [2019-03-04 07:35 UTC] stas@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=254a5914ad7f9dbdc4f6090229f6b0f4317a695e
Log: Fix #77431 SplFileInfo::__construct() accepts NUL bytes
 [2019-03-04 07:35 UTC] stas@php.net
-Status: Assigned +Status: Closed
 [2019-03-04 07:35 UTC] stas@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ae1fad5bb773c4c58c2249472b5c06ca05ebe702
Log: Fix #77431 SplFileInfo::__construct() accepts NUL bytes
 [2019-03-16 13:33 UTC] 64796c6e69 at gmail dot com
Thanks for the fix! Will this be assigned a CVE-ID?
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Fri Jan 31 07:01:30 2025 UTC