firestuff/markdown/2006-02-09-php-perl-ruby-exploit.md

Take the PHP code:

<?php
$filename = ‘content/’.$_REQUEST[’filename’].’.html’;
include($filename);
?>

This is exploitable in an obvious way; “../” can be included in the filename, and it can be used to open any file ending in “.html” that’s readable by the web user. However, there’s a second, less obvious exploit path.

If magic_quotes_gpc is off, the following is possible:

test.php?filename=../../../../../../etc/passwd%00

PHP stores strings internally as binary-safe, but the include() requires a syscall, which expects a nil-terminated string. The result is that the syscall considers the string over at the \0, and opens /etc/passwd. PHP should really check to see if the binary-safe string contains nils before the syscall, and fail with an error if it does.

---

In PERL:

open IN,”foo\0bar”;

causes the syscall:

open(”foo”, O_RDONLY|O_LARGEFILE)

---

In Ruby:

File.open(”foo\0bar”,’r');

causes the syscall:

open(”foo”, O_RDONLY|O_LARGEFILE)

---

Python appears to be safe:

open(”foo\0bar”,”r”);

throws an error:

TypeError: file() argument 1 must be (encoded string without NULL bytes), not str