[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  
find them.

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  
another matter)

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  
dramatically reduced

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.

9. Profit!

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  
> example
> of the types of vulnerabilities that might exist in .Net  
> environments).
> Most enterprise solutions will have places where BO can be created,  
> and
> 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  
> manager)
> can be as dangerous as unmanaged code
> Dinis Cruz
> Owasp .Net Project
> www.owasp.net
> 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  
>> only
>> 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,  
>> buffer
>> 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.
>> thanks,
>> Andrew
>> On 16/03/2006, at 1:23 AM, Ory Segal wrote:
>>> Hi,
>>> 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  
>>> application.
>>> Anyone else?
>>> -Ory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060317/5ad233fa/attachment.p7s>

More information about the websecurity mailing list