[WEB SECURITY] Re: Jeremiah Grossman writes about buffer overflow myths
jeremiah at whitehatsec.com
Thu Mar 16 13:04:39 EST 2006
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
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
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.
On Mar 15, 2006, at 11:40 PM, <ol at uncon.org> <ol at uncon.org> 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
> 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
> 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
> I don't believe I disagreed with this.. of course, but that's like
> 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
> 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
> - 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
> I felt if the article was being fair and honest it should of
> Isaac's work... In short I don't believe overflows in custom web
> apps has
> been myth busted...
The Web Security Mailing List
The Web Security Mailing List Archives
More information about the websecurity