Unsafe at any speed

UPDATE: you can download a beta for this tool from: http://portal.erratasec.com/lg/LookingGlass.exe
You can subscribe to http://portal.erratasec.com/mailman/listinfo/talksec for more information.

Vista sets a new standard of security with its SDL, ASLR, and NX. Unfortunately, nobody else is living up to that standard. While Vista itself may be secure, all the add-on software that typically comes with the system is not secure.

A good example of this is Apple. Their QuickTime application (part of iTunes) is installed on a lot of Windows computers, if not most. Yet, there is a new vulnerability discovered in QuickTime every couple months because the code is inherently insecure. The vulnerabilities allow attackers to break into Vista machines because Apple doesn’t take advantage of Vista’s security features.

It doesn’t have to be that way. One of the most important Vista security features is “address space randomization” or “ASLR”. ASLR prevents hacker code from running because the code is unable to find stuff in memory. QuickTime disabled this feature, so I its layout is not randomized. Exploits for QuickTime vulnerabilities work because they know precisely where important bits are located. If QuickTime enabled ASLR, then most exploits for its vulnerabilities would not work.

We have tested this. You can tweak the executable and enable ASLR. After doing this, we found this introduced no bugs into QuickTime, and that it successfully prevent QuickTime vulnerabilities from being exploited.

Turning on the ASLR flag in all products will undoubtedly cause (or expose) a few bugs, but most software will run just fine. There is no reason for software companies to continue to ignore this issue. Among the companies/products currently ignoring these features are: Mozilla’s Firefox, Google’s toolbar, Apple’s iTunes, Adobe’s PDF reader, Roxio’s media creation tools, and Divx’s player. Actually, we haven’t found any company that turns on ASLR consistently.

When you order a computer from a major vendor, it comes with Broadcom drivers for network, RealTek drivers for sound, nVidia drivers for video, Intel drivers for the motherboard, and so on. None of these are secure, and some of these are surprisingly reachable from the outside world. None of the major anti-virus vendors enable features like ASLR, either.

A similar feature to ASLR is the “NX” bit. This feature was added a few years ago to standard processors. Computer memory is split between code and data. A common hacker technique injected code into the data area, where it would run. The NX or “execute disable” bit tells the processor not to execute code in the data area. This makes exploitation of vulnerabilities much harder.

In much the same way that most software does not use the ASLR feature, most software does not use the NX feature as well.

More than half of the most important hacker vulnerabilities have exploited dangerous code. Back in the 1970s, standard code building blocks were developed. Over time, we came to realize that the design of these building blocks were inherently dangerous. The situation is similar to how over time we realized that cars were dangerous without seatbelts, padded dashboards, and emergency brakes. We now have newer version of these building blocks. Features such as “sprintf” and “strcpy” have been replaced with safe versions known as “sprintf_s” and “strcpy_s”.

Microsoft removed the dangerous code from Windows and replaced it the safe versions. Other vendors have not followed Microsoft’s lead, and still build their code with the dangerous code.

We have written a scanner for all the software on your system looking for these deficiencies. The major things we look for are whether ASLR is enabled, whether NX (no execute for stack/heap) is enabled, and whether “unsafe” functions are used (where “unsafe” are the functions banned by Microsoft’s SDL). An example of the output is shown below:


In the screenshot, we scanned the Microsoft Office subdirectory on a Vista machine. We find that while a lot of code supports ASLR, a lot of code doesn’t. We likewise see that only some code supports the NX bit. We also see that Microsoft Office still uses dangerous functions like “strcpy”. As it turns out, most of Microsoft Office is secure, but that code supporting legacy features (such as older file formats) is where it’s insecure.

Here is another example scanning the Adobe Acrobat directory:

Here is an example scanning Firefox:

We aren’t claiming the software found in scans is vulnerable, what we are claiming is that it’s unsafe. These features are important, and its time that the entire software industry starts paying attention to them.

One flaw in the program is that it doesn’t distinguish between different levels of unsafeness. The “unsafe” functions are those banned by Microsoft in their SDL. In truth, not all these functions are all that dangerous. Whereas functions like “sprintf” should be considered toxic to coders, the alternative “snprintf” is only slightly imperfect, compared to the safe version “sprintf_s”. We should probably have two columns, one listing the “toxically unsafe” functions and another listing “slightly unsafe” functions.