Is MS08-067 Wormable?

A couple of weeks ago Microsoft released an out-of-band security update in bulletin MS08-067. Looking at the type of vulnerability and the fact that the issue was already being exploited in the wild at the time, this was a good decision. If you have not already installed this security update, you should stop reading this right now and return after you have installed the update.

The problem fixed in MS08-067 is eerily reminiscent of the vulnerabilities that resulted in the Blaster and Sasser worms. Therefore, for obvious reasons, the question arises whether MS08-067 is wormable or not. Microsoft claimed in various outlets that it was wormable "on older systems." Michael Howard backs that up with some interesting analysis on the SDL blog. The Secure Windows Initiative (SWI) blog also discusses the issue and points to a number of mitigations designed to reduce the "wormability" on newer operating systems. By "older systems" Microsoft really means "not Vista and Server 2008." This leads to the question of why the vulnerability cannot be used to create a worm on Windows Vista and Server 2008, and whether the claim is correct or not.

The claim that MS08-067 cannot be used to create a worm on Vista and Server 2008 is based largely on two defenses used on those operating systems. The first is that the vulnerable end-point is not anonymously accessible on those operating systems. That's a pretty good defense out on the general Internet. However, on a corporate network it provides little defense. Anyone with user-level credentials on a host can exploit the vulnerability. Thus, if a single computer gets infected and then is brought inside the corporate network, it can infect any other computers on the corporate network by authenticating to them. It would take a little more coding to write an exploit that does that, but it is certainly not an impossibility.

The second defense is Address-Space Layout Randomization (ASLR). ASLR causes the addresses used for code in memory to change from execution to execution. Each time you execute a program it will be loaded into a portion of memory; but, under ASLR, that memory is offset at one of 256 possible memory locations. Many exploits rely on knowing where in memory certain structures are. Prior to ASLR those locations were deterministic within an Operating System, Serice Pack, and Patch Level combination. However, under ASLR, they are, as I mentioned, no longer deterministic. This makes exploitation much more difficult.

However, do these defenses, and specifically, ASLR, really make a vulnerability "not wormable?" I would argue that the answer is "we do not know" but that it is tending toward "no." The problem is that we really do not understand the spreading patterns of worms well enough to make a claim one way or the other. Let us take a neutral scientific approach to understanding this claim.

Worms rely on spreading from computer to computer. Each computer that is infected with the worm can infect countless additional computers. The only thing that moderates it is time. The spread, however, is exponential. The more infected computers there are, the more computers there are that can spread the infection. Eventually, some form of critical mass is reached at which point the spread turns uncontrollable. Unfortunately, we do not know where that inflection point is.

To see how this works, let us take a hypothetical worm, and let us assume that ASLR is not used. Let's say the infection takes 1/8th of a second per computer. In other words, if computer A is infected and targets the worm at computer B, 1/8th of a second later, computer B is ready to start infecting computer C. In one second, a single computer, computer A, can spread the infection, directly or indirectly, to 64 other computers. The total impact of the worm is t/r^2, where t is the time and r is the rate of spread measured in the time it takes to infect an additional computer. Using that formula, we can see that after 1 second 64 computers could be infected. After 2 seconds, 256 computers can be infected, and so on.

Now let's apply ASLR to this. Using ASLR, the memory address space is allocated over 256 possible addresses. In other words, under a very tight assumption the infection will fail in all but 1/256 cases. The assumption is that we cannot predict where the locations are, and that the randomization will actually cause the infection to succeed in only one case of 256. Let us just say this assumption holds because it lets us analyze a worst-case scenario for the worm. Under ASLR then, we can consider the rate of spread to be 1/256th that of the non-ASLR worm. In other words, rather than infecting the next computer in 1/8th of a second, computer A can only infect one new computer in 32 seconds. This, obviously, slows down the spread of the worm, but is it enough? The spread is still exponential. It just takes longer to spread. Consider this chart:

This chart maps the number of infected computers over a 24-minute period, assuming there is an infinite number of computers to infect, and ASLR is in use on all of them. It is clear from this graph that the spread is exponential. After 24 seconds, 2,025 computers are infected. By contrast, without ASLR, it would take less than 6 seconds to infect that many computers. The point, however, is that ASLR would not stop a worm, it would only slow it down. What we do not know is whether slowing down a worm is effectively enough to stop it. My inclination would be to say that it is probably not enough unless we can slow it down by many orders of magnitude.

In addition to ASLR, the affected service on Windows Vista and Server 2008 would only restart twice before staying down indefinitely. This is important because unsuccessful exploitation would almost certainly cause the service to crash. However, I do not consider that as a defense against worms, because more than likely, the user would at that point either restart the computer or just the service. Given that the restart behavior would only serve to further slow the spreading rate. It would not change the exponential nature of the spread. Again, we arrive at the same conclusion: none of the defenses make a vulnerability non-wormable. They merely slow the spread down.

This is important because there is a risk that people will avoid patching because a vulnerability is not wormable. Make no mistake, remotely exploitable vulnerabilities are still wormable, and within an hour, you could easily have your entire corporate network infected. As if that weren't bad enough, using a remotely exploitable vulnerability, someone with far worse intentions could take over your computers and use them as an entry point into your network. For that the criminal needs only one computer, not a whole network of them. Wormability, or lack thereof, is irrelevant against a targeted attack, which means that ASLR is essentially irrelevant against a targeted attack. in most cases the attacker needs a computer, not a particular computer. Being able to only gain a foot hold on one computer in 256 is likely to be enough because after the initial entry, the vulnerability plays no further part in the compromise of your network. In other words, do not consider ASLR to be a reason not to patch some particular vulnerability.

Now, do I think we will see a worm for MS08-067? No. Not in the traditional sense of Blaster. The time of worms, like Blaster, that are inherently non-destructive, has passed. At this point, criminals are not interested in simply writing worms that self-replicate. They are interested in one of the three big things: money, ideology, or national supremacy. While we may still see massive worms, they will be fundamentally different than the ones of old, and they will probably take a bit longer to write. The new breed will be more targeted, more silent, more deliberate, and more dangerous. Once the objectives change, so do the attack patterns.

In short, please do not use wormability, or lack thereof, as a decision factor in deciding whether to patch a vulnerability or not. Wormability is an irrelevant and potentially dangerously misleading metric.

Leave a Reply

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