POST http://192.168.1.4/t/xoops-2.0.14/htdocs/install/index.php HTTP/1.1
lang=../../../../../../../../etc/passwd%00&op=start&submit=Next
NOTE: This attack will not work if MAGIC QUOTES are enabled. MAGIC
QUOTES escapes null characters to . This feature is often forgotten about.

magic quotes is deprecated and will be going completely away with php 6. Advising people to use it is setting them up for trouble.

per the manual:http://www.php.net/manual/en/security.magicquotes.php

Warning

This feature has been DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

As well it’s inconsistent and doesn’t always work. They are removing it because they’ve realized you can’t create defensive coding with a language option that only works half the time. It simply doesn’t work. A far better solution to the include problem is to compare the input variable and switch on it:

$var=$_GET['language'];
switch($var)
{
  case “english”:
    $include=’english.php’;
    break;
  case “spanish”:
    $include=’spanish.php’;
    break;
  default:
    $include=’genericerror.php’;
    //or even ‘english.php’
}

You could also set up an associative array of include directories and do an array reference using $var as the index to locate a path or something. If the value at that index is empty (unexpected/malicious input) use the safety include. Using input directly, no matter how it’s filtered, to build a path is very very bad form. Always has been. I’ve lost track (I’m sure you have too 8) of the number of vulnerabilities caused by this type of stupidity. As well, you can use a whitelist filter on your input to remove things like null. eg:

$inputvar=$_GET['inputvar'];
$inputvar=preg_replace(”/^[\w\.\@]/”,”",$inputvar);
(remove all but a-z,A-Z,0-9, . and @)

Trying to filter all the bad stuff out is a losing proposition, much better to *only allow the good stuff*. It’s future proof.

Great article!!!

-Viz

hadaka, I could probably do a seperate presentation on that topic. See Awesome AnDrEw’s comment.

mike, cool stuff man. Keep up the good work.

urldecode() isn’t the only way to bypass filtering. I used base64_decode() here to bypass magic_quotes_gpc to hit some nifty SQL injection. The SQL payload I used is a bit different from the norm. http://milw0rm.com/exploits/4733

Also EVERY file function in php suffers from a null byte issue because they are all calling the same C file handling function, go ahead look at the stack trace in GDB. To be honest as a C programmer I’m horrified some functions will read past the null byte.

Peace

Always good to have more documented vulnerabilities (and their solutions) to keep newly built applications on top of them.

Hugo: The Webserver will change %25 to %, and then urldecode() will change %27 to “‘”.

Lets try this out:

$a = $_GET['t'];

    echo $a; // before urldecode
    $b = urldecode($a);
    echo $b; // after urldecode

We get from t=%25 | t=%:
    $a = %
    $b = % // no change

Thanks for the observation Hugo.

While we are on the subject of urldecode(). urldecode() is also vulnerable to NULL byte injection. So there is certainly potential for other vulnerabilities such as File Include bugs (%2500).