52 lines
1.4 KiB
Markdown
52 lines
1.4 KiB
Markdown
|
<!--# set var="title" value="PHP/PERL/Ruby exploit" -->
|
|||
|
|
<!--# set var="date" value="February 9, 2006" -->
|
|||
|
|
|
|||
|
|
<!--# include file="include/top.html" -->
|
|||
|
|
|
|||
|
|
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
|
|||
|
|
|
|||
|
|
<!--# include file="include/bottom.html" -->
|