[WEB SECURITY] Re: Jeremiah Grossman writes about buffer overflow myths
Andrew van der Stock
vanderaj at greebo.net
Thu Mar 16 21:53:04 EST 2006
I must be in an enviable position - my application reviews are rarely
black box, I have all the source for the most part, and usually
proceed for at least two weeks. My longest review lasted more than
three months which is both luxury and pain rolled into one.
I look for buffer overflows, things like calling JNI and native in
J2EE, unmanaged code in .NET, p/Invoke and RCWs, serviced components
(COM+), and of course look for fixed size buffers (heap / stack
overflows), arrays (for integer overflows - note J2EE has no overflow
protection), and unsafe functions in C / C++, as well as trust
boundary issues, such as looking at COM interfaces if I don't have
access to the ActiveX / COM objects in .NET / ASP reviews.
However, unless I'm dealing with C/C++ code, I don't spend a
disproportionate amount of time looking for them as generally it's
hard in the frameworks I generally review (90+% J2EE) to do buffer
overflows. I spend a day or two at most looking for them and rarely
Items which must be true to trigger a buffer overflow
1. The system must possess at least one buffer overflow. Pretty good
chance of that - most code is buggy to some degree.
2. The user exposed code must be able to send hostile user data to
the buffer overflow(s). If you call a component which is vulnerable
but send no user data to it, the attack tree finishes here.
3. The user must be able to submit enough / right sort of data to
trigger the buffer overflow and not get caught out by validation or
protocol limits (ie, if you need to send in a 16 kb buffer in a HTTP
header, it's not going to work for the most part as it violates
protocol handlers, and should be dropped. Whether it is or not is
4. The user must do it surrupticiously enough that their practice
runs are not noticed. If you take out the middleware server or
integration layer once every few minutes, it should raise eyebrows
even in the most anti-security establishments
5. The user must be skilled enough to be able to send in the right
payload. Most script kiddies do not have this skill. It's my
experience that we in the security community are so much better at
creating payloads than pretty much everyone else. Not to say that it
will not happen, just the pool of potential attackers has been
6. The system being affected must have a path back to the attacker if
it's not going to be just a denial of service attack. Most
organizations, even the littlest I deal with, generally do not allow
new outbound communications to the Internet, and do not allow direct
communication to middle tiers from the Internet, so you're stuck with
inbound port 80 / 443 and potentially DNS. It is somewhat unlikely
the attacker would have control of the affected system even if
successful at sending in a useful payload, such as nc or similar
7. The buffer overflow must be running in a sufficiently powerful
system account to make the attack useful. If you're running as
LOCALSYSTEM or root, excellent. If you're running as guest or a low
privilege account, it may take some effort to gain sufficient
privileges to do anything useful at all
8. The buffer overflow will lead you to cause actual financial loss
for the organization or actual financial gain for the attacker, or
provides a valuable end point to stage further attacks from within.
If the system is a custom system, it is my personal view that it's
not worth the attacker's time to go down this path, particularly if
they're motivated to perform unauthorized transactions for profit or
fraud, particularly when XSS and other injection attacks are more
frequent, so much simpler, harder to detect and can actually go
unnoticed even on well-managed sites. Buffer overflows are unlikely
to result in access to a valuable system, work for long if it does,
and it would not go unnoticed even by organizations who do not
actively monitor their sites.
If the system is like a very popular component, such as in .NET
Framework or a popular database connector in J2EE, the attacker has
less barriers to hurdle over, but in general, that's not a web app
sec attack, it's a traditional buffer overflow attack, like Code
Red / Nimda or similar.
Buffer overflow education and detection is vital for the devs of
J2EE, .NET, Perl, Ruby and PHP, and of course CGI developers. But if
I have only 10 things I can get the business or a web app developer
to fix, buffer overflows are simply not one of them.
On 17/03/2006, at 10:44 AM, Dinis Cruz wrote:
> Humm Andrew, I don't agree that Buffer Overflows are over-hyped.
> For example what guarantees you have that the .Net Framework doesn't
> contain several buffer overflows?
> Take for example the ones I found in ILDASM and ILASM (in .Net
> 1.1) , or
> the 'unmanaged to managed' data conversion error I found in asp.net's
> IIS pipeline (which was not exploitable (I think) but is a good
> of the types of vulnerabilities that might exist in .Net
> Most enterprise solutions will have places where BO can be created,
> probably the main reason we are not seeing more cases are:
> a) most audits are done without access to the source code (or when
> such access is provided, not enough time to really find BOs)
> b) on non mass deployed apps, the vulnerabilities discovered by
> security consultants are not publicly disclosed (so you never know)
> Remember that Full Trust .Net code (or Java without a security
> can be as dangerous as unmanaged code
> Dinis Cruz
> Owasp .Net Project
> Andrew van der Stock wrote:
>> I have back in January, but it has been a long time between drinks. I
>> found no buffer overflows in the reviews I conducted in 2005, and
>> IIRC one in 2004. I did maybe 20-30 app reviews a year prior to 2005,
>> and in 2005 I started doing massive reviews of major systems, looking
>> at very large code bases.
>> What surprised me was how incredibly resistant the developer from my
>> January review was about fixing them, even though they are completely
>> preventable. Only when we showed how trivial it was to exploit them
>> did they fix only the demo overflows we crafted. This is yet another
>> reason why I think languages like C++ and C have had their day,
>> particularly in relation to enterprise class apps.
>> Compared to say validation, authorization and injection issues,
>> overflows are completely over-hyped. When I finish Guide 2.1, my next
>> target is to revitalize the Top 10, and buffer overflows are out.
>> On 16/03/2006, at 1:23 AM, Ory Segal wrote:
>>> Another interesting thing to note, which I totally agree with is:
>>> Quote: "While technically possible, the truth is that they are just
>>> not seen in the real world. Our experience at WhiteHat Security,
>>> having assessed hundreds of Web sites and identified thousands of
>>> vulnerabilities, shows that statistically, buffer overflows appear
>>> near the bottom of the list of total discovered issues."
>>> I've been around for quite a while, and I can't remember the last
>>> time I have seen a Buffer Overflow in a custom-built web
>>> Anyone else?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2234 bytes
Desc: not available
More information about the websecurity