Could you please provide more information about what you think is the problem, what is the expected result and what is the actual result?

Hi, @stats

Sure. why not. the problem is that, the null byte is deprecated (I think to stop LFI... and similar attacks). Nullbytes are dangerous and thus, are not actually avilable since php 5.3.1, however, using \x00 it is still possible to use them.

say the script:

move_uploaded_file($_FILES['x']['tmp_name'],"/tmp/test.php\x00.jpg")

Should actually have created /tmp/test.php\x00.jpg when in reality, it creates /tmp/test.php which should bypass .jpg extenssion checking scripts. I still don't know why this nullbyte works when the %00 is deprecated.

Anyway, I guess I have answered your question

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Hi, Again.

This has been assigned with CVE-2015-2348. it will be published in mitre as soon as a fix is publicly available (if it hasn't already) 5.3.7, maybe?

This has been classified as remotely exploitable  modernate-critical issue following the reason(s):

- If you allow file uploads and you check them on extension, its very probable you pass the file using move_uploaded_file and thus causing an RCE.
- Checking on mime type, size, content header, extension... won't stop the exploit from passing as a valid file. consider the code https://github.com/RandomStorm/DVWA/blob/master/vulnerabilities/upload/source/high.php that code is suppose to be a secure/unbreakable code for RCE. its the highest level of DVWA. many developers follow the same practice and I am sure no one still blacklists null-bytes.

Thanks for pushing a fix so fast! :)

I'm not sure how you achieve remote exploit with this, unless you already have security vulnerability, such as allowing writing arbitrary remotely specified files or trusting extension supplied externally. Trusting remotely supplied extension is a grave security error as naturally you can be given any file under any extension, regardless of its contents. DWVA is an example of this error, but nobody should be actually writing such code if they want any security.

"... but nobody should be actually writing such code if they want any security."

Indeed. but most of the codes I audit have similar checks. extension & mime checking, its how everybody does it. and I see no problems with it, (at-least to cause RCE) until this bug. I agree with you that this like you said won't happen if the name got randomized and explicitly moved to a custom extension.

But considering how many sites are out there with such vulnerabilities like the one in DVWA, this is remotely exploitable. but there is no use in debating while this issue has been fixed! :)

Thanks!

I can't validate the CVE you've mentioned. It does appear as assigned, but no details (or any PHP reference) although the fix is public for more than 10 days. I'm going to ignore it for now.

@kaplan Yes I know. I have been trying to reach the CVE team for days. they haven't provided any public info just yet. I don't know what is wrong with them but I am hoping they will release public info soon.

Thanks!

Confirmed with https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2348