Looks like this issue was fixed in PHP 5.3 https://bugs.php.net/bug.php?id=39863
As PHP uses the underlying C functions for filesystem related operations, it may handle null bytes in a quite unexpected way. As null bytes denote the end of a string in C, strings containing them won't be considered entirely but rather only until a null byte occurs. The following example shows a vulnerable code that demonstrates this problem:
Example #1 Script vulnerable to null bytes
<?php
$file = $_GET['file']; // "../../etc/passwd\0"
if (file_exists('/home/wwwrun/'.$file.'.php')) {
// file_exists will return true as the file /home/wwwrun/../../etc/passwd exists
include '/home/wwwrun/'.$file.'.php';
// the file /etc/passwd will be included
}
?>
Therefore, any tainted string that is used in a filesystem operation should always be validated properly. Here is a better version of the previous example:
Example #2 Correctly validating the input
<?php
$file = $_GET['file'];
// Whitelisting possible values
switch ($file) {
case 'main':
case 'foo':
case 'bar':
include '/home/wwwrun/include/'.$file.'.php';
break;
default:
include '/home/wwwrun/include/main.php';
}
?>
Looks like this issue was fixed in PHP 5.3 https://bugs.php.net/bug.php?id=39863
This issue has been fixed for file_exists(): https://bugs.php.net/bug.php?id=39863
It still exists for include|require(_once) as of this writing.
clean input of null bytes:
<?php
$clean = str_replace(chr(0), '', $input);
?>
Since problems with null bytes do not stretch to regular string functions, this should be enough to ensure no GET parameter contains them any more:
<?php
function getVar($name)
{
$value = isset($_GET[$name]) ? $_GET[$name] : null;
if (is_string($value)) {
$value = str_replace("\0", '', $value);
}
}
?>
Modifying this to work with other superglobals should not be a problem, so I will leave it up to you.