Re: [WEB SECURITY] Re: Jeremiah Grossman writes about buffer overflow myths

["Ryan Barnett" <rcbarnett@xxxxxxxxx>]

------=_Part_1169_17011890.1142430138513
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The article you posted is a good read, however it does not entirely debunk
the core message of Jeremiah's article.  The SecurityFocus article wanted t=
o
show that it would still be possible to execute a blind buffer overflow
against ISAPI extensions.

If we are not looking at the article examples in a lab view, but rather a
real world view, then the Vulnerabilty Requirements section becomes
important -

"There are very few necessary requirements of the vulnerability for
exploitation to be successful. If any type of filtering is being done on ou=
r
input, output from the extension would be required to display which bytes
are denied or modified.

The second and third requirements are that a register must point to our
payload and have enough room for single or multi-stage shell code."
With these caveats in mind - is this really a blind buffer overflow if it i=
s
a requirement that denied byts are displayed back to the attacker?

Additionally, the author summed it up with this statement -

"One can now see that even when an attacker does not have access to the
binary, source or platform information, exploitation may *in some specific
scenarios* allow for remote code execution."

This brings up another point from Jeremiah's article - the likelyhood of a
buffer overlow is less then the other attacks he mentioned (SQL Injection,
etc...)

-Ryan


On 3/15/06, ol@uncon.org <ol@uncon.org> wrote:
>
> > Did you read the article or did you just base your response on the 2
> sample
> > sentences sent in the email?  The article quite clearly outlined the
> fact
> > that it was focusing on "custom" applications and not widely available
> (to
> > everyone, including attackers) software.
>
> Yes I did. Did you read the article I posted? It clearly describes how it
> is
> possible and thus likely hood is greatly increased on custom applications
> (using ISAPI as a particular example I grant you).
>
>
>
>
>


--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

------=_Part_1169_17011890.1142430138513
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>The article you posted is a good read, however it does not entirely de=
bunk the core message of Jeremiah's article.&nbsp; The SecurityFocus articl=
e wanted to show that it would still be possible to execute a blind buffer =
overflow against ISAPI extensions.
</div>
<div>&nbsp;</div>
<div>If we are not looking at the article examples in a lab view, but rathe=
r a real world view, then the Vulnerabilty Requirements section becomes imp=
ortant -</div>
<div>&nbsp;</div>
<div>&quot;There are very few necessary requirements of the vulnerability f=
or exploitation to be successful. If any type of filtering is being done on=
 our input, output from the extension would be required to display which by=
tes are denied or modified.=20
</div>
<p class=3D"text">The second and third requirements are that a register mus=
t point to our payload and have enough room for single or multi-stage shell=
 code.&quot;</p>
<div>With these caveats in mind - is this really a blind buffer overflow if=
 it is a requirement that denied byts are displayed back to the attacker?</=
div>
<div>&nbsp;</div>
<div>Additionally, the author summed it up with this statement -</div>
<div>&nbsp;</div>
<div>&quot;One can now see that even when an attacker does not have access =
to the binary, source or platform information, exploitation may <strong>in =
some specific scenarios</strong> allow for remote code execution.&quot;
</div>
<div>&nbsp;</div>
<div>This brings up another point from Jeremiah's article - the likelyhood =
of a buffer overlow is less then the other attacks he mentioned (SQL Inject=
ion, etc...)</div>
<div>&nbsp;</div>
<div>-Ryan<br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 3/15/06, <b class=3D"gmail_sendername">=
<a href=3D"mailto:ol@uncon.org";>ol@uncon.org</a></b> &lt;<a href=3D"mailto:=
ol@uncon.org">ol@uncon.org</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt; Did you read the article or=
 did you just base your response on the 2<br>sample<br>&gt; sentences sent =
in the email?&nbsp;&nbsp;The article quite clearly outlined the fact
<br>&gt; that it was focusing on &quot;custom&quot; applications and not wi=
dely available (to<br>&gt; everyone, including attackers) software.<br><br>=
Yes I did. Did you read the article I posted? It clearly describes how it i=
s
<br>possible and thus likely hood is greatly increased on custom applicatio=
ns<br>(using ISAPI as a particular example I grant you).<br><br><br><br><br=
></blockquote></div><br><br clear=3D"all"><br>-- <br>Ryan C. Barnett<br>Web=
 Application Security Consortium (WASC) Member
<br>CIS Apache Benchmark Project Lead<br>SANS Instructor: Securing Apache<b=
r>GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>Author: Preventing Web Attacks with=
 Apache=20

------=_Part_1169_17011890.1142430138513--