PHP Arbitrary File Upload Vulnerability (CVE-2015-2348)

PHP Arbitrary File Upload Vulnerability (CVE-2015-2348)

Security researchers today released a critical vulnerability-PHP Arbitrary File Upload Vulnerability (CVE-2015-2348 ).

When uploading a file, you can determine that the file name is a valid file name and that the file is not a malicious file. This does cause other security problems. In this case, it is unrealistic to check the vulnerability in your own files, because this vulnerability can bypass your file name suffix, file Type (Content-Type), Mime type, file size, and so on, so relying solely on these checks can not save you.

Vulnerability details

This vulnerability exists in a very common function in php: move_uploaded_files. Developers always use this function to move uploaded files, this function checks whether the uploaded file is a legal file (whether it is uploaded through the HTTP post mechanism). If it is a legal file, it must be included in the specified directory.

Example:

move_uploaded_file ( string $filename , string $destination )

The problem here is that you can insert null characters in the file name (This vulnerability has been fixed many times, such as CVE-2006-7243), using the insertion of null characters, attackers can upload arbitrary files, remote Code Execution Vulnerability.

I will use DVWA to demonstrate this example. The most advanced DVWA question is not easy to pass for various reasons and is intended to tell developers how to develop safer File Upload components. Let's take a look at this example:
 

<?phpif (isset($_POST['Upload'])) {$target_path = DVWA_WEB_PAGE_TO_ROOT."hackable/uploads/";$target_path = $target_path . basename($_FILES['uploaded']['name']);$uploaded_name = $_FILES['uploaded']['name'];$uploaded_ext = substr($uploaded_name, strrpos($uploaded_name, '.') + 1);$uploaded_size = $_FILES['uploaded']['size'];if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_size < 100000)){if(!move_uploaded_file($_FILES['uploaded']['tmp_name'], $target_path)) {$html .= '<pre>';$html .= 'Your image was not uploaded.';$html .= '</pre>';      } else {$html .= '<pre>';$html .= $target_path . ' succesfully uploaded!';$html .= '</pre>';}}else{$html .= '<pre>';$html .= 'Your image was not uploaded.';$html .= '</pre>';}}?>

Code snippet:

$uploaded_name = $_FILES['uploaded']['name'];$uploaded_ext = substr($uploaded_name, strrpos($uploaded_name, '.') + 1); $uploaded_size = $_FILES['uploaded']['size'];if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_size

This code has many vulnerabilities, such as XSCH and XSS, but there is no such serious vulnerability as RCE, because the problem of null characters has been fixed since PHP 5.3.1. The problem here is that DVWA passes the name parameter uploaded by the user to the move_upload_file () function, so the php operation may be like this:

move_uploaded_file($_FILES['name']['tmp_name'],"/file.php\x00.jpg");

This document should create a file named file. php \ x00.jpg, but the file actually created is file. php.

In this way, the suffix name verification in the Code is bypassed, and it turns out that many other functions in the GD library also have this problem (such as getimagesize (), imagecreatefromjpeg ()... ), You can see this example.

If your machine's php version is 5.4.39, 5.5.x-5.5.23, or 5.6.x-5.6.7, you can check whether the file name contains the \ x00 character to solve the problem described in this article.

Security suggestions

If this vulnerability exists on your machine, we recommend that you rename the file name using a random string instead of using the value of the name parameter uploaded by the user.