Stack Buffer Overflows – Old Exploits Never Die

Tell the world!

Buffer overflows remain one of the most highly exploitable vulnerabilities on the Internet. Just last month (Feb 2016), researchers from Red Hat and Google discovered a bug in the GNU C Library a.k.a.  Glibc that made machines running the glibc package vulnerable to stack-based buffer overflow exploits.

The glibc package is found in several Linux distributions, including those running on servers as well as some routers and other network devices, so the potential scope of impact is quite extensive. Fortunately, a bug fix has already been released and hopefully the majority of the affected machines should have been patched by now. Nevertheless, it doesn’t change the fact that buffer overflows continue to be a threat to information security.

What is a stack-based buffer overflow?

There are different types of overflows, including stack, heap, arithmetic, and format overflows. But what we’re concerned with in this particular case is the stack buffer overflow.

A stack buffer overflow occurs when the stack, a part of memory that’s in charge of keeping tabs of a thread’s current function, its calling function (the one that called it), as well as other calling functions before it, is filled with more bytes than it’s capable of supporting.

When this happens, some of the data can be overwritten. If the overwritten data includes function return addresses, the processor will lose track of the calling function it’s supposed to return to and, in turn, the legitimate instructions it’s supposed to execute.

What’s worse is if the items that were injected to cause the overflow contains pre-designed return addresses, malicious code may be called into play instead of those legitimate instructions.

Overflows have long been used as attack vectors for carrying out cyber attacks, including the spread of worms. Some of the most infamous worms in Internet history were able to spread through exploited overflows:

  • Morris worm (1988) – affected 10% of computers connected to the Internet at that time
  • Code Red (2001) – infected 359,000 computers in less than 14 hours
  • Nimda (2001) – infected 160,000 computers at its peak
  • SQL Slammer/Sapphire (2003) – Infected 90% of vulnerable hosts in 10 minutes

*source – “The Executive Guide to Information Security – Threats, Challenges, and Solutions” by Mark Egan and Tim Mather (2005)

Why buffer overflows exist

Actually, not all applications are vulnerable to buffer overflows. Only software written in programming languages with poor memory management capabilities are. So is that good news? Not totally. These memory management-deficient languages include C and its successors (e.g. C++ and Objective C). While these languages are quite old, many applications and libraries have been written through them. Simply put, they’re ubiquitous.

It only takes an unwitting developer (using any of these languages) to employ certain system calls and library functions for a buffer overflow vulnerability to emerge. The now deprecated gets() function, which had no way of preventing an oversized input from the keyboard from being stuffed into a limited-sized buffer, is one common textbook example.

In the case of that glibc bug we recently talked about, the affected function is the getaddrinfo() library function. Any program carrying out a domain-name lookup using the getaddrinfo() function could be exploited by attackers through oversized responses from malicious domain names, DNS servers, or man-in-the-middle attacks.

Some ways of preventing stack buffer overflows

There are a couple of ways to prevent buffer overflows. One is to use applications written in languages like Java, .NET, Python, JavaScript, and Perl. Some security-conscious developers employ tools that analyze source code to detect possible overflow errors (although you would have no way of knowing if the application you’re using ever underwent that kind of process).

Other developers employ specialized compilers that force the application to crash if a potential buffer overflow is detected. Other solutions include the use of security features like NX (No Execute), ASLR (Address Space Layout Randomization), and deep-packet inspection. We won’t go into the details now, Perhaps we can talk about these in future blog posts.

In the meantime, if you’re concerned about the glibc DNS vulnerability, feel free to contact us today.

 

Tell the world!

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*