Contrary to popular belief,
Conversely, the Open Web Application Security Projectii (OWASP) has stated that buffer overflows are one of the Top 10iii most critical Web application security flaws. And, it is true that buffer overflows are a primary vehicle used to propagate the most notorious viruses and worms in operating systems from Microsoft Windows to Linux. So if both observations are true, then where's the disconnect?
The disconnect comes from a common misunderstanding of where, when, and how buffer overflows are exploited. A buffer overflow is a software condition in which an application attempts to store more data in a memory buffer than has been allocated. The overflow will overwrite adjacent memory, which could cause the application to crash. Cleverly designed buffer overflow exploits are able to take advantage of this situation by overwriting specific pieces of memory to execute arbitrary system commands and take over computers. The nature and origin of buffer overflows has been covered exhaustively in numerous articles and white papersiv, v. And, we've all seen the result of well-executed buffer overflow exploits on corporate networks.
Normally, buffer overflow vulnerabilities are found through source code analysis or by reverse engineering application binaries. Depending on the instance, a person could spend hours, weeks or even months stringing together memory addresses in order to create functional exploit code. For hackers to uncover these issues, they really need to get their hands on the running application. The hacker can then repeatedly exploit the buffer overflow, capture the crashed application state (via SoftIce or Gnu Debugger) and trace the buffer through memory. That is why buffer overflows usually appear within compiled commercial and open-source software, rather than in custom Web application code.
Custom Web applications are exactly that: custom software that an organization develops for itself and hosts on its Web servers. We're not talking about commercial Web software components from IBM, Microsoft or SAP. That means the public, including hackers, is unlikely to have access to the application source code or essential elements for testing. As a result, the way buffer overflow vulnerabilities are identified and possibly exploited in custom Web applications is a completely different process. With the exception of a source code review, testing a Web application for buffer overflowvi vulnerabilities must be performed remotely over the network.
Penetration testers, as well as hackers, do not have access to source code, application binaries or memory dumps. Testing is blind. A typical test will input several thousand characters into a URL query string parameter (See Example 1). and wait for the Web server to respond with a "500" error response code (See Example 2). A 500 code may be an indication that an application has crashed server-side due to a buffer overflow, but that is extremely unlikely.
It is more often the case that a device in the connection chain, including Web application firewalls, http proxies, load balancers, Web servers, application servers or others, caught the abnormal test and returned an identical 500 error message. That is why blind buffer overflow tests are prone to heavy false-positive rates. The fact is, anything could have caused a 500 error, but only rarely is it a Web application buffer overflow.
However, if a buffer overflow did exist, it would likely be in common off-the-shelf components used to build the Web site, such as Microsoft IIS, Apache, Oracle, MySQL, SiteMinder and thousands of others.
To further understand why buffer overflow exploits do not normally occur in custom Web applications, consider this hypothetical, and rare, situation: A hacker wants to perform a buffer overflow exploit and nothing is restricting user-supplied input to a custom Web application. What needs to take place for the attack to succeed?
In the simplest of circumstances, the hacker would have to find a vulnerable Web application and parameter, discover the size of the buffer, properly overwrite the stack pointer and load in well-written shell codev. And, all of that must be done while completely blind to any application or CPU architecture specifics. Call me jealous, but you'd have to be one of those Hollywood movie hackersviii to pull that off. It would be like swishing a basketball blindfolded while standing outside in the stadium parking lot. Perhaps that is why the Web Application Security Consortium has yet to identify a single media reported incidentix where a Web site was hacked due to a buffer overflow within a custom Web application.
There is another critical aspect to consider when evaluating the risks of buffer overflows in custom Web applications. Popular Web application programming languagesx, such as Java, are immune to buffer overflows by their very nature. These languages perform their own memory handling, and unless there is some problem with the interpreter (rare), you're safe. So if someone alerts you to a buffer overflow in your Web application, you have every reason to be skeptical, especially if you are using one of these languages.
Let me be careful here to say that I'm not suggesting we have carte blanche to leave our code riddled with memory handling issues. In fact, if you're using a C/C++/C# language or variant, and you do happen to be vulnerable, then maybe there is some risk worth investigating.
So the real source of the disconnect between real-world findings and the OWASP top 10 is risk evaluation. We agree that if someone managed to exploit a buffer overflow in a Web application, then it would result in a critical situation. However, businesses need to prioritize their risk based on the likelihood of occurrence and focus on those vulnerabilities/issues most likely to be found and exploited by hackers. The question is, what exactly are they?
My advice: To get the most bang for your security buck, take care of your cross-site scripting (XSS) and SQL injection vulnerabilities, authentication/authorization loopholes, and business logic flaws. Those are the vulnerabilities worth going after first because they significantly reduce risk. To defend against those threats, assess early and assess often to protect sensitive data and stay out of the headlines.
About the author: Jeremiah Grossman is founder and CTO of WhiteHat Security Inc. He is also co-founder of the Web Application Security Consortium and a member of SearchAppSecurity.com's Expert's Panel. He can answer questions you may have about application security activities, such as threat modeling and how to build security into the software development life cycle.
i Wikipedia - Buffer overflow
ii The Open Web Application Security Project (OWASP) is dedicated to finding and fighting the causes of insecure software.
iii The OWASP Top Ten represents a broad consensus about what the most critical Web application security flaws are.
iv The Tao of Windows Buffer Overflow
v Smashing The Stack For Fun And Profit
vi Web Security Threat Classification - Buffer Overflow
vii Wikipedia – Shellcode
viii Hackers – The movie
ix Real World Web Hacking URL's
A compiled list of news sources, specific to real-world Websites, describing an actual Web application security hack.
x Cold Fusion, Java, Perl, PHP, Python, Ruby on Rails, and Visual Basic are popular Web programming languages that perform their own memory handling
This was first published in March 2006