php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
42 + 19 = ?
Subscribe to this entry?

 
 [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)

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 18 17:01:28 2024 UTC