Analysis of php arbitrary file Upload Vulnerability cve-2015-2348

Last night, security news burst out a "php arbitrary file Upload Vulnerability", CVE number: cve-2015-2348.

At that time, the landlord is ready to pack things home, see this news in the heart a surprise: Lost in the river for many years 0 characters truncation upload vulnerability and reproduce it? And it affects so many versions! If the loophole is true, it looks like we're going to patch up overnight tonight.

But after a simple analysis, found that the use of loopholes is very harsh (many people are curious how harsh), the landlord simply record their own analysis process and share with you, if there is improper, please correct me.

I. Overview of Vulnerabilities

The vulnerability reporter said that the PHP upload function move_uploaded_file The purpose path parameter can use NULL character truncation, bypassing the detection of jpg,png upload type, resulting in arbitrary file upload. Test exp given by the speaker:

Move_uploaded_file ($_files[' x ' [' Tmp_name '], "/tmp/test.php\x00.jpg")

According to the vulnerability reporter's description 5.3 Later versions are affected (https://bugs.php.net/bug.php?id=69207)

Second, the vulnerability test

To verify the effectiveness of the vulnerability landlord build a test environment, version 5.3.6, the construction test code is as follows:

Upload Front page upload.htm:

Upload processing Script upload.php

Test upload upload.php always return failure false

So change a version 5.3.29, still not tested successfully, is I test the method is wrong, then look at the source bar.

Third, the vulnerability debugging

Move_uploaded_file code implemented in the EXT/STANDARD/BASIC_FUNCTIONS.C file, the key code:

There are several logic in the code that return false, so the test is not successful, it must have hit one of the logic.

The landlord uses the most primitive way to debug the log, verify that the test code is filtered by the above red code, and then see the values printed out strlen (new_path) and New_path_len-respectively, 19 and 23.

New_path is the length of the pathname string "/tmp/whoisdashuaige\x00jpg", since strlen is calculated to the empty word prompt \x00 end, so the length of 19 is understandable.

So why is New_path_len 23?

All variable types in the PHP language are stored in a structure of the following, new_path_len corresponding to the red Len. The Len here is a binary length and does not encounter a null character end so the length is 23. So the test demo uses the.

What about the success of the test, another colleague from the group sent a message saying that in 5.6.6 version can be tested successfully, open 5.6.6 vulnerability code to see the shock, 5.6.6 code as follows:

Originally in the high version (affected version), PHP to thelength comparison of the security check logic to remove, resulting in the occurrence of the vulnerability, do not know this code is the developer of the update, what hatred.

Iv. exploit conditions of exploitation

The exploit needs to control the second parameter (the target path), such as:

However, in the actual development scenario, the target path is usually generated by the program itself (to avoid file coverage with the same name), even if you step back, the program ape students want to take the original file name, often also used to use the $_files variable to take the file name.

The $_files variable, if it is truncated, does not affect the program logic:

Commits a.php\0jpg and a.php are equivalent.

The test method is as follows:

Upload Grab Package Modify the name to A.php\0jpg (the NUL character), you can see that the string stored by $_files[' xx ' [' name '] is a.php, does not contain the characters after the "after" truncation, and therefore does not affect the validation logic of the code.

However, if the $_request method is obtained, it is possible for the extension to have inconsistent expectations , resulting in "arbitrary file Upload".

V. Summary

1, the vulnerability impact version must be in 5.4.x<= 5.4.39, 5.5.x<= 5.5.23, 5.6.x <= 5.6.7, see CVE announcement: Https://web.nvd.nist.gov/view/vuln/detail ? vulnid=cve-2015-2348

2, the exploit conditions are harsh, and the actual business writing code habits have a large difference, so the risk is lower

Act hastily, please correct me if there is any improper.

Excerpt from: TSRC

Analysis of php arbitrary file Upload Vulnerability cve-2015-2348