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

[Jeremiah Grossman <jeremiah@xxxxxxxxxxxxxxx>]

Sorry for my latent reply, I was traveling when the article  
published. I had read "Blind Buffer Overflows In ISAPI Extensions" in  
the past and was intrigued by the research. Good stuff. The article  
focused on proof-of-concept examples how blind buffer overflows COULD  
be achieved in specific situations. However, it did not go into the  
probably of such attacks actually succeeding. Nor did it need to  
because that was not its intended purpose.

What the author does say in the first paragraph...

"It is the author's belief that these attacks do happen and will most  
likely increase the more software products are secured against easily  
exploitable flaws and as attackers shift focus to exploiting  
proprietary solutions."

I took to mean buffer overflow attacks in web application happen, but  
the implication is rarely. And as easier to web app sec flaws are  
resolved (possibly meaning XSS and SQL Injection), we'll see attacks  
moving towards this area. So myself and the author are probably not  
in disagreement.

Also, Andrew van der Stock earlier in the thread informed us that  
buffer overflows will be cast out of the new Top-10. A good step in  
the right direction.

Either way your right, I should have referenced the work, it was an  
oversight on my part. For those interested in the topic, this is well  
worth a read.

Regards,

Jeremiah-






On Mar 15, 2006, at 11:40 PM, <ol@xxxxxxxxx> <ol@xxxxxxxxx> wrote:

> > The article you posted is a good read, however it does not  
> > entirely debunk
> the core message of Jeremiah's article.
>
> But it did show that "slim" & "custom" in the same article is a very
> black/white view which should have more shades of grey.
>
> > With these caveats in mind - is this really a blind buffer  
> > overflow if it
> is a requirement that denied bytes are displayed back to the attacker?
>
> But that would be in cases where there is user input validation,  
> you may be
> able to deduce the denied bytes through normal application  
> operation without
> them being displayed back the user. The fact the author includes  
> one caveat
> doesn't invalidate the research... it' like saying if all applications
> included user input validation SQL injection wouldn't exist. While  
> maybe
> true it's highly unrealistic that "all" would.
>
> > "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."
>
> Yes but this sounds a little more practical than "slim", it proves  
> the point
> that custom applications which suffer bufferoverflows can be exploited
> blindly without code access (my original point)..
>
> > This brings up another point from Jeremiah's article - the  
> > likelihood of a
> buffer overflow is less then the other attacks he mentioned (SQL  
> Injection,
> etc...)
>
> I don't believe I disagreed with this.. of course, but that's like  
> comparing
> apples and oranges. One could argue that's for a number of reasons  
> not least
> that the languages which a majority of web applications are written  
> in are
> typically less (if at all) susceptible to bufferoverflow conditions  
> which
> are exploitable in native code.
>
> My original point was never say never (and slim way too strong),  
> and while
> complex and not as easy as "' OR 1=1--" the following is true:
>  - Buffer overflows can and will be found in custom web  
> applications when
> written in appropriate languages (via fuzzing or what ever  
> techniques you
> prefer)
>  - In at least one instance (ISAPI is the one to hand) these  
> overflows in
> "custom" code could be exploited blindly without access to the  
> server or
> source
>
> I felt if the article was being fair and honest it should of  
> referenced
> Isaac's work... In short I don't believe overflows in custom web  
> apps has
> been myth busted...


---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/