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.

omg Microsoft releases protocol specs lol

http://msdn2.microsoft.com/en-us/library/cc216513.aspx

I've been reverse engineering undocumented features of Microsoft protocols since before most of today's hackers were born, so this is a pretty big deal for me.

One thing that should be made clear, however, is that these are NOT the full specifications. Inevitably, there are bugs in Microsoft's code that don't follow the spec. Either they produce packets that the specs say shouldn't be produced, or read packets in a way other than how they are supposed to be read. I predict that within the next year or two a Slashdot posting complaining about this. People will be complaining about how Linux stacks aren't completely compatible, and they will blame Microsoft for having a conspiracy hiding the complete technical details. The reality, of course, is that Microsoft doesn't know the complete technical details, since they aren't yet aware of the bugs in their own code.

This likewise means that we'll see vuln reports as implementors of open-source stacks find that Microsoft's stacks crash. Conversely, Linux implementors are likely to create their own bugs that hackers can exploit. Parsing protocols is inherently dangerous. Thus, the release of these specs will encourage hacking of both Microsoft and open-source stacks.

There is no Cable Cut Conspiracy

Large parts of the Middle East has been cut off from the Internet due to a series of (five) cuts in undersea cables. There have been an explosion of conspiracy theories trying to explain this.

This highlights the human psychology of computer security: people are apt to see patterns where none exist. Outages in undersea cables are a common occurrence. They usually go unreported. However, once a major outage is reported, minor outages that would normally be ignored now become reported as well.

This is like "cancer clusters". Statistically, we know that cancer cases are not evenly distributed over the population, but will often cluster together. This is especially true if you get to draw a boundary around an area in order to highlight a cluster. It's like the birthday paradox: if you randomly choose boundaries, then you are unlikely to find a cluster more than three times the national average, but if you can carefully draw a boundary with the intention of including as many incidents as possible, then you can reach as high as ten times the national average. This means, for example, that we can find places where children's leukemia will be several times the national average for no particular reason other than statistical distribution. However, humans will insist upon a special reason, such as power-lines or chemicals. An underlying cause (like a chemical spill) will cause a cluster, but a cluster is rarely evidence of an underlying cause.

The five cable cuts in a row are likewise not evidence of wrongdoing. This is in the realm of normal statistics. This is not as unusual as it looks; it is not by itself evidence of wrongdoing. If there were wrongdoing, such as blowing up a cable with C4, then those repairing the cable are likely to report that the break looks unusual. They have reported nothing unusual about these breaks.

We can see this pattern in other subjects. A good example is global warming. Climate change is normal, and unusual weather events are normal. Even scientists who believe strongly in global warming know that such weather events have nothing to do with their theory. Yet, the popular media always draws the conclusion, and scientists are powerless to debunk this. You just can't stop people from tying the two together. I could make the claim that since global warming is supposed to cause more/stronger storms, and most cable cuts (such as the recent ones near Egypt) are caused by ship anchors dragging along the sea bottom during storms, and therefore this cut was therefore caused by global warming. That would be fallacious reasoning, but I'm sure most people would believe it.

If there is a conspiracy, chances are good that people wouldn't be able to figure it out. UFOlogists have long suspected that strange lights in the sky are from space aliens, and that the government is trying to cover up. However, we have since discovered that many of those lights were secret spy planes under development that the government was trying to cover up. There was indeed a conspiracy, just the wrong one.

One of the conspiracy theories is that the NSA (who owns their own nuclear sub) caused the faults in the cables in order to distract people while they install secret spy equipment. If the NSA is involved, then this specific conspiracy is unlikely to be true. Cable tapping is far more complicated than people imagine, and they are unlikely to cut multiple cables at once if they want to be secret about it.

If I were to come up with a conspiracy theory involving the NSA, I would suggest something different. I'd imagine that they had a high-value target that they desperately need to eavesdrop on, but cannot for some reason. Therefore, they would blow up the problematic cables to force the traffic to go across different cables that they can eavesdrop on. The cuts in Egypt caused a lot of Middle Easy traffic to be sent the long way around the world - through the United States.

Here is a better conspiracy: it was caused by former cyber-czar Richard Clarke. He wrote a fictional cyberthriller ("Breaking Point") that began with Russian terrorists blowing up transatlantic cables. I'm thinking that he got a subprime loan that is about to be foreclosed upon, so he cut a few undersea cables in order to drum up new sales for his book. Why did he choose mideast cables instead of the Atlantic cables his book describes? Easy: he didn't want to prevent Europeans from ordering his book on Amazon.com. I submit to you that this conspiracy theory makes as much sense as any other, and that the government needs to locate Clarke quickly and interrogate him on the matter.

As a separate topic, we should note yet again that the Internet is more vulnerable to physical attacks than cyberattacks. When asked "How would you take down the Internet?", the most common response from cybersecurity experts has long been "well placed C4".

UPDATE 2008-02-06: This article at Wired further explains the non-conspiracy. It points out that there is a cable cut somewhere in the world every 3 days, and that an analysis of the cuts show no wrong doing.