Today I would like to post about a recent bug I have found in PHP, CVE-2015-2348.
This bug is fairly severe. (considering the amount of developers & packages affected).
This bug is fairly severe. (considering the amount of developers & packages affected).
I have to admit checking the file extension and saying a file is safe can still cause many
other security issues. However, checking for this exact vulnerability in your code is pretty
unrealistic, considering it can pass the Content-Type, Extension, Mime type, size checks...
etc won't save you from this.
other security issues. However, checking for this exact vulnerability in your code is pretty
unrealistic, considering it can pass the Content-Type, Extension, Mime type, size checks...
etc won't save you from this.
The issue occurs in the very popular move_uploaded_files php function that is used to handle
user uploaded files. This function checks to ensure that the file designated by
filename is a valid upload file (meaning that it was uploaded via PHP's HTTP POST upload
mechanism). If the file is valid, it will be moved to the filename given by destination.
user uploaded files. This function checks to ensure that the file designated by
filename is a valid upload file (meaning that it was uploaded via PHP's HTTP POST upload
mechanism). If the file is valid, it will be moved to the filename given by destination.
Example:
move_uploaded_file ( string $filename , string $destination )
The problem with it is that there is a way to insert null-bytes (fixed multiple times before,
i.e: CVE-2006-7243). Using null-bytes an attacker can convince an upload box to ignore
extension checks and that the file is fairly safe and valid and upload malicious files that
can cause RCE. using the character \x00
i.e: CVE-2006-7243). Using null-bytes an attacker can convince an upload box to ignore
extension checks and that the file is fairly safe and valid and upload malicious files that
can cause RCE. using the character \x00
I am going to take DVWA for an example here. DVWA's highest level is meant to be unbroken
for number of issues. the high upload box is meant to teach developers the safe way of handling
a safe upload. Lets just exploit that.
Here is the code snippet from https://github.com/RandomStorm/DVWA/blob/master/
vulnerabilities/upload/source/high.php:
for number of issues. the high upload box is meant to teach developers the safe way of handling
a safe upload. Lets just exploit that.
Here is the code snippet from https://github.com/RandomStorm/DVWA/blob/master/
vulnerabilities/upload/source/high.php:
$uploaded_name = $_FILES['uploaded']['name'];
$uploaded_ext = substr($uploaded_name, strrpos($uploaded_name, '.') + 1);
$uploaded_size = $_FILES['uploaded']['size'];
$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)) {
$uploaded_ext == "JPEG") && ($uploaded_size < 100000)){
if(!move_uploaded_file($_FILES['uploaded']['tmp_name'], $target_path)) {
$html .= '';
$html .= 'Your image was not uploaded.';
$html .= ''; }
else {
$html .= $target_path . ' succesfully uploaded!';
.
.
This is yes vulnerable to number of exploits (like XSCH, XSS and more), but not RCE.
Because since PHP 5.3.1 Null bytes are deprecated. The problem with DVWA is that its passing user provided name to the move_uploaded_file() - Expected behavior for PHP to create:
Because since PHP 5.3.1 Null bytes are deprecated. The problem with DVWA is that its passing user provided name to the move_uploaded_file() - Expected behavior for PHP to create:
move_uploaded_file($_FILES['name']['tmp_name'],"/file.php\x00.jpg")
That file should have created the file "file.php\x00.jpg"
Reality is it creates: file.php
This clearly bypasses the extension check. It has been proven many times the GD libraries
can also be defeated ( getimagesize(), imagecreatefromjpeg()... ),
read this by @secgeek for example.
can also be defeated ( getimagesize(), imagecreatefromjpeg()... ),
read this by @secgeek for example.
Now even if you have had done multiple checks for this, it will be highly unlikely you blacklisted
the char \x00 so most upload forms running PHP before 5.4.39, 5.5.x before 5.5.23, and 5.6.x
before 5.6.7 are vulnerable for this particular attack.
the char \x00 so most upload forms running PHP before 5.4.39, 5.5.x before 5.5.23, and 5.6.x
before 5.6.7 are vulnerable for this particular attack.
Closing:
If you are on a vulnerable server, update!
