Files
firestuff/2006-02-09-php-perl-ruby-exploit.html

60 lines
1.7 KiB
HTML
Raw Permalink Normal View History

2019-04-21 17:15:52 +00:00
<!--# set var="title" value="PHP/PERL/Ruby exploit" -->
2019-04-25 02:45:09 +00:00
<!--# set var="date" value="2006-02-09" -->
2019-04-21 17:15:52 +00:00
<!--# include file="include/top.html" -->
<p>Take the <strong>PHP</strong> code:</p>
<pre><code>&lt;?php
$filename = content/.$_REQUEST[filename]..html;
include($filename);
?&gt;
</code></pre>
<p>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” thats readable by the web user. However, theres a second, less obvious exploit path.</p>
<p>If magic_quotes_gpc is off, the following is possible:</p>
<pre><code>test.php?filename=../../../../../../etc/passwd%00
</code></pre>
<p>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.</p>
<hr />
<p>In <strong>PERL</strong>:</p>
<pre><code>open IN,”foo\0bar”;
</code></pre>
<p>causes the syscall:</p>
<pre><code>open(”foo”, O_RDONLY|O_LARGEFILE)
</code></pre>
<hr />
<p>In <strong>Ruby</strong>:</p>
<pre><code>File.open(”foo\0bar”,r');
</code></pre>
<p>causes the syscall:</p>
<pre><code>open(”foo”, O_RDONLY|O_LARGEFILE)
</code></pre>
<hr />
<p><strong>Python</strong> appears to be safe:</p>
<pre><code>open(”foo\0bar”,”r”);
</code></pre>
<p>throws an error:</p>
<pre><code>TypeError: file() argument 1 must be (encoded string without NULL bytes), not str
</code></pre>
<!--# include file="include/bottom.html" -->