Why are programs written in C and C++ so frequently vulnerable to overflow attacks?

Question

When I look at the exploits from the past few years related to implementations, I see that quite a lot of them are from C or C++, and a lot of them are overflow attacks.

• Heartbleed was a buffer overflow in OpenSSL;
• Recently, a bug in glibc was found that allowed buffer overflows during DNS resolving;

that's just the ones I can think off right now, but I doubt that these were the only ones that A) are for software written in C or C++ and B) are based on a buffer overflow.

Especially concerning the glibc bug, I read a comment that states that if this happened in JavaScript instead of in C, there wouldn't have been an issue. Even if the code was just compiled to Javascript, it wouldn't have been an issue.

Why are C and C++ so vulnerable to overflow attacks?

Answer 1

C and C++, contrary to most other languages, traditionally do not check for overflows. If the source code says to put 120 bytes in an 85-byte buffer, the CPU will happily do so. This is related to the fact that while C and C++ have a notion of array, this notion is compile-time only. At execution time, there are only pointers, so there is no runtime method to check for an array access with regards to the conceptual length of that array.

By contrast, most other languages have a notion of array that survives at runtime, so that all array accesses can be systematically checked by the runtime system. This does not eliminate overflows: if the source code asks for something nonsensical as writing 120 bytes in an array of length 85, it still makes no sense. However, this automatically triggers an internal error condition (often an "exception", e.g. an ArrayIndexOutOfBoundException in Java) that interrupts normal execution and does not let the code proceed. This disrupts execution, and often implies a cessation of the complete processing (the thread dies), but it normally prevents exploitation beyond a simple denial-of-service.

Basically, buffer overflow exploits requires the code to make the overflow (reading or writing past the boundaries of the accessed buffer) and to keep on doing things beyond that overflow. Most modern languages, contrary to C and C++ (and a few others such as Forth or Assembly), don't allow the overflow to really occur and instead shoot the offender. From a security point of view this is much better.

Answer 2

Note that there is some amount of circular reasoning involved: Security issues are frequently linked to C and C++. But how much of that is due to inherent weaknesses of these languages, and how much of it is because those are simply the languages most of the computer infrastructure is written in?

---

C is intended to be "one step up from assembler". There is no bounds checking other than what you yourself implemented, to squeeze the last clock cycle out of your system.

C++ does offer various improvements over C, the most relevant to security being its container classes (e.g. <vector> and <string>), and since C++11, smart pointers, which allow you to handle data without having to manually handle memory as well. However, due to being an evolution of C instead of a completely new language, it still also provides the manual memory management mechanics of C, so if you insist on shooting yourself in the foot, C++ does nothing to keep you from it.

---

So why are things like SSL, bind, or OS kernels still written in these languages?

Because these languages can modify memory directly, which makes them uniquely suited for a certain type of high-performance, low-level application (like encryption, DNS table lookups, hardware drivers... or Java VMs, for that matter ;-) ).

So, if a security-relevant software is breached, the chance of it being written in C or C++ is high, simply because most security-relevant software is written in C or C++, usually for historic and / or performance reasons. And if it's written in C/C++, the primary attack vector is the buffer overrun.

If it were a different language, it would be a different attack vector, but I am sure there would be security breaches just as well.

---

Exploiting C/C++ software is easier than exploiting, say, Java software. The same way that exploiting a Windows system is easier than exploiting a Linux system: The former is ubiquitous, well understood (i.e. well-known attack vectors, how to find and how to exploit them), and a lot of people are looking for exploits where the reward / effort ratio is high.

That does not mean the latter is inherently safe (safer, perhaps, but not safe). It means that -- being the harder target with lower benefits -- the Bad Boys aren't wasting as much time on it, yet.

Answer 3

Actually, "heartbleed" was not really a buffer overflow. To make things more "efficient", they put many smaller buffers into one big buffer. The big buffer contained data from various clients. The bug read bytes that it wasn't supposed to read, but it didn't actually read data outside that big buffer. A language that checked for buffer overflows wouldn't have prevented this, because someone went out of their way or prevent any such checks from finding the problem.

Answer 4

First, as others have mentioned, C/C++ is sometimes characterized as a glorified macro assembler: it is meant to be "close to the iron", as a language for system-level programming.

So for instance, the language allows me to declare an array of zero length as a placeholder when, in fact, it may represent a variable-length section in a data packet or the beginning of a variable-length region in memory that is used to communicate with a piece of hardware.

Unfortunately it also means that C/C++ is dangerous in the wrong hands; if a programmer declares an array of 10 elements and then writes to element 101, the compiler will happily compile it, the code will happily execute, trashing whatever happens to be at that memory location (code, data, stack, who knows.)

Second, C/C++ is idiosyncratic. A good example is strings, which are basically character arrays. But each string constant carries an extra, invisible terminating character. This has been the cause of countless errors as (especially, but not exclusively) novice programmers often fail to allocate that extra byte needed for the terminating null.

Third, C/C++ is actually quite old. The language came into being at a time when external attacks on a software system were basically non-existent. Users were expected to be trusted and cooperative, not hostile, as their goal was to make the program work, not to crash it.

Which is why the standard C/C++ library contains many functions that are inherently unsafe. Take strcpy(), for instance. It will happily copy anything up until a terminating null character. If it doesn't find a terminating null character, it will keep on copying till hell freezes over, or more likely, until it overwrites something vital and the program crashes. This wasn't a problem in the good old days, when, a user was not expected to enter into a field reserved for, say, a ZIP code, 16000 garbage characters followed by a specially constructed set of bytes that were meant to be executed after the stack was trashed and the processor resumed execution at the wrong address.

Just to be sure, C/C++ is not the only idiosyncratic language out there. Other systems have different idiosyncratic behavior, but it can be just as bad. Take back-end programming languages like PHP, and how easy it is to write code that allows for SQL injection.

In the end, if we give programmers the powerful tools they need to do their job, but without adequate training and awareness of the security environment, Bad Things will happen no matter which programming language is used.

Answer 5

I will probably touch on some things some of the other answers have already stated.. but.. I find the question itself to be erroneous and "vulnerable".

As asked, the question is assuming a lot without understanding the underlying issues. C/C++ are not "more vulnerable" than other languages. Rather, they place as much of the power of computing devices, and the responsibility of using that power, directly in the hands of the programmer. So, the reality of the situation is, many programmers write code that is vulnerable to exploitation, and since C/C++ do not go to great lengths to protect the programmer from themselves like some languages do, their code is more vulnerable. This is not a C/C++ issue, as programs written in assembly language would have the same problems, for example.

The reason why such low-level programming can be so vulnerable is because doing things like array/buffer bounds checking can become computationally expensive, and is very often unnecessary when programming defensively. Imagine, for example, that you are writing code for some major search engine, which has to process trillions of database records in the blink of an eye, so the end user won't get bored or frustrated while "Page loading..." is displayed. You do not want your code to keep checking array/buffer boundaries every single time through the loop; While it may take nanoseconds to do such a check, which is trivial if you're only processing ten records, it can add up to many seconds or minutes when you're looping through billions or trillions of records.

So instead, you "trust" that the data source (for example, the "web bot" that scans websites and puts the data in to the database) has already checked the data. This should not be an unreasonable assumption; For a typical program, you want to check the data upon input, so the code that processes the data can operate at maximum speed. Many code libraries also take this approach. Some even document that they expect the programmer to have already checked the data before calling the library functions to act upon the data.

Unfortunately, however, many programmers do not program defensively, and just assume that the data must be valid and within safe boundaries/parameters. And this is what gets exploited by attackers.

Some programming languages are designed such that they try to protect the programmer from such poor programming practices by automatically inserting additional checks in to the generated program, which the programmer did not explicitly write in to their code. Again, this is fine when you're only going to loop through the code a few hundred times or less. But when you're going through billions or trillions of iterations, it adds up to long delays in data processing, which may become unacceptable. So it's a trade-off when choosing which language to use for a particular piece of code, and how often and where you check for potentially dangerous/exploitable conditions within the data.

Answer 6

Basically programmers are lazy people (including myself). They do things like using gets() instead of fgets() and defining i/o buffers on the stack and not looking out enough for ways memory could get overwritten unintentionally (well unintentionally for the programmer, intentionally for the hacker :).

Answer 7

There is a large amount of existing C code that does unchecked writing to buffers. Some of this is in libraries. This code is exploitably unsafe if any external state can change the length written, and only very unsafe otherwise.

There is a larger amount of existing C code that does bounded writing to buffers. If the user of said code does a math error and lets more be written than it should, this is as exploitable as the above. There is no compile-time guarantee that the math is done right.

There is also a large amount of existing C code that does reads based off offsets in memory. If the offset is not checked as being valid, this can leak information.

C++ code is often used as a high level language for interop with C, so many C conceits are followed, and bugs from communicating with C APIs are common.

C++ programming styles that prevent such overruns exist, but it only takes 1 mistake to allow them to happen.

In addition, the problem of dangling pointers, where memory resources are recycled and the pointer now points at memory with a different lifetime/structure than it did originally, permits some kinds of exploits and information leaks.

These kind of errors -- "fencepost" errors, "dangling pointer" errors -- are so common, and so hard to eliminate completely, that many languages where developed with systems designed explicitly to prevent them from happening.

Not surprisingly, in languages designed to eliminate these errors, these errors do not occur nearly as often. They still sometimes occur: either the engine running the language has the problem, or a manual situation is set up that matches the environment of the C/C++ case (reusing objects in a pool, using common a large common buffer subdivided by consumer, etc). But because those uses are rarer, the problem happens less often.

Every dynamic allocation, every buffer use, in C/C++ runs these risks. And being perfect is not attainable.

Answer 8

Most commonly used languages (Java and Ruby, for instance) compile to code that runs in a VM. The VM is designed to segregate machine code, data and usually stack. This means that regular language operations can't change the code or redirect the flow of control (sometimes there are special APIs that can do this, e.g for debugging).

C and C++ are usually compiled directly into the native machine language of the CPU - this gives performance and flexibility benefits, but means that erroneous code can overwrite program memory or stack and thus execute instructions not in the original program.

This typically occurs when a buffer is (maybe deliberately) overrun in C++. In Java or Ruby, by contrast, a buffer overrun will immediately cause an exception and can't (excepting VM bugs) overwrite code or change control flow.