Rootkits and Software Exploits

Software exploitation is an important subject relating to rootkits. (How software can break and be exploited is not covered in this book. If you're interested in software exploitation, we recommend the book Exploiting Software.^[20])

^[20] G. Hoglund and G. McGraw, Exploiting Software.

Although a rootkit is not an exploit, it may be employed as part of an exploit tool (for example, in a virus or spyware).

The threat of rootkits is made strong by the fact that software exploits are in great supply. For example, a reasonable conjecture is that at any given time, there are more than a hundred known working exploitable holes in the latest version of Microsoft Windows.^[21] For the most part, these exploitable holes are known by Microsoft and are being slowly managed through a quality-assurance and bug-tracking system.^[22] Eventually, these bugs are fixed and silently patched.^[23]

^[21] We cannot offer proof for this conjecture, but it is a reasonable assumption derived from knowledge about the problem.

^[22] Most software vendors use similar methods to track and repair bugs in their products.

^[23] "Silently patched" means the bug is fixed via a software update, but the software vendor never informs the public or any customers that the bug ever existed. For all intents, the bug is treated as "secret" and nobody talks about it. This is standard practice for many large software vendors, in fact.

Some exploitable software bugs are found by independent researchers and never reported to the software vendor. They are deadly because nobody knows about them accept the attacker. This means there is little to no defense against them (no patch is available).

Many exploits that have been publicly known for more than a year are still being widely exploited today. Even if there is a patch available, most system administrators don't apply the patches in a timely fashion. This is especially dangerous since even if no exploit program exists when a security flaw is discovered, an exploit program is typically published within a few days after release of a public advisory or a software patch.

Although Microsoft takes software bugs seriously, integrating changes by any large operating system vendor can take an inordinate amount of time.

When a researcher reports a new bug to Microsoft, she is usually asked not to release public information about the exploit until a patch can be released. Bug fixing is expensive and takes a great deal of time. Some bugs aren't fixed until several months after they are reported.

One could argue that keeping bugs secret encourages Microsoft to take too long to release security fixes. As long as the public doesn't know about a bug, there is little incentive to quickly release a patch. To address this tendency, the security company eEye has devised a clever method to make public the fact that a serious vulnerability has been found, but without releasing the details.

Figure 1-2, which comes from eEye's Web site,^[24] shows a typical advisory. It details when the bug was reported to a vendor, and by how many days the vendor patch is "overdue," based on the judgment that a timely response would be release of a patch within 60 days. As we have seen in the real world, large software vendors take longer than 60 days. Historically, it seems the only time a patch is released within days is when a real Internet worm is released that uses the exploit.

^[24] www.eEye.com

Figure 1-2. Method used by eEye to "pre-release" a security advisory.

Type-Safe Languages

Programming languages that are type-safe are more secure from certain exploits, such as buffer overflows.

Without type safety, program data is just a big ocean of bits. The program can grab any arbitrary handful of bits and interpret it in limitless ways regardless of the original purpose of the data. For example, if the string "GARY" were placed into memory, it could later be used not as text, but as a 32-bit integer, 0x47415259 (or, in decimal, 1,195,463,257 a rather large number indeed!). When data supplied by an external user can be misinterpreted, software exploits can be employed.

Conversely, programs written in a type-safe language (like Java or C#^[25]) would never convert "GARY" to a number; the string would always be treated as text and nothing else.

^[25] C# (pronounced "see sharp") is not the same language as "C" ("see") or C++ ("see plus plus").

Why Exploits Are Still a Problem

The need for software security has been known for a long time, yet software exploits continue to be a problem. The root of the problem lies within the software itself. Bluntly stated, most software is not secure. Companies like Microsoft are making huge strides in designing better security for the future, but current operating-system code is written in C or C++, computer languages that by their very nature introduce severe security holes. These languages give rise to a problem known as buffer-overflow exploits. The buffer-overflow bug is the most significant weakness in software today. It has been the enabler for thousands of software exploits. And, it's a bug an accident that can be fixed.^[26]

^[26] Although buffer-overflow bugs are not confined to C and C++ code, the C and C++ programming languages make it difficult to ensure safe coding practices. The languages are not type-safe (discussed later in this chapter), use built-in functions that can overflow buffers, and are difficult to debug.

Buffer-overflow exploits will eventually go away, but not in the near future. Although a disciplined programmer can write code that does not have buffer-overflow bugs (this is regardless of language; even a program written by hand in Assembly can be secure), most programmers are not that diligent. The current trend is to enforce safe coding practices and follow this up with automated code-scanning tools to catch mistakes. Microsoft uses a set of internal tools for this purpose.^[27]

^[27] For example, PREfix and PREfast were developed and deployed by Jon Pincus, Microsoft Research. See http://research.microsoft.com/users/jpincus/

Automated code-scanning tools can catch some bugs, but not all of them. Most computer programs are very complex, and it can be difficult to test them thoroughly in an automated fashion. Some programs may have too many states to possibly evaluate.^[28] In fact, it is possible for a computer program to have more potential states than there are particles in the universe.^[29] Given this potential complexity, it can be very hard to make any determination about the security of a computer program.

^[28] A "state" is like an internal configuration within the software. Every time the software does something, the state will change. Thus, most software has a huge number of potential states.

^[29] To understand this, consider the theoretical bounds for the number of permutations of a string of binary bits. For example, imagine a 160MB software application that uses 16MB (10% of its total size) of memory to store state. That program could, in theory, have up to 2^16,777,216 different operational states, which is far, far larger than the number of particles in the universe (variously estimated at around 10^80). [Thanks to Aaron Bornstein for this clarifying example.]

The adoption of type-safe languages (such as Java and C#) would nearly eliminate the risk of buffer overflows. Although a type-safe language is not guaranteed to be secure, it significantly reduces the risks of buffer overflows, sign-conversion bugs, and integer overflows (see sidebar on page 15). Unfortunately, these languages cannot match the performance of C or C++, and most of Microsoft Windows even the latest and greatest version still runs old C and C++ code. Developers of embedded systems have begun to adopt type-safe languages, but even this uptake is slow and the millions of legacy systems out there will not be replaced any time soon. What this means is that old-fashioned software exploits will be around for awhile.