Windows Update Can Hurt Security 220
An anonymous reader writes "Researchers at Carnegie Mellon University have shown that given a buggy program with an unknown vulnerability, and a patch, it is possible automatically to create an exploit for unpatched systems. They demonstrate this by showing automatic patch-based exploit generation for several Windows vulnerabilities and patches can be achieved within a few minutes of when a patch is first released. From the article: 'One important security implication is that current patch distribution schemes which stagger patch distribution over long time periods, such as Windows Update... can detract from overall security, and should be redesigned.' The full paper is available as PDF, and will appear at the IEEE Security and Privacy Symposium in May."
Re:Doesn't matter (Score:2, Interesting)
However, would such a scheme be compatible with free software? Under the GPL, would a Linux distributor be permitted to send out encrypted binary patches and only reveal the decryption key later?
No fix feasible (Score:5, Interesting)
Unfortunately, no fix is feasible. The basic problem is twofold:
- If you tell someone how to fix a problem, you tell them what the problem was.
- It's not possible to push updates to all affected systems simultaneously.
That the first is true should be obvious if you think about it for a minute. As for the second, that comes from the fact that the affected systems are owned by different entities with different requirements and different environments. A fix for a problem affects more than just the fixed software, especially when the fix is in the operating system on which other business-critical software runs. Any fix has to be checked for compatibility with that entity's specific environment, this checking can't start until after the entity has gotten the fix, and everybody's going to take a different amount of time to check and get clearance to deploy.The only "fix" would be a mandatory push to all systems at one time, and that won't be accepted by the people who own the systems unless Microsoft or someone else accepts complete 100% liability for all costs associated with any failure. And I just don't see that happening.
This article is dumb. (Score:4, Interesting)
Essentially, these people wrote a paper which says that hackers can analyze Windows Updates and figure out how to attack systems that aren't patched yet thereby. It goes into theory and proofs of that. Thanks, everyone else knew this about Windows Update years ago, probably for about as long as there's been a Windows Update.
It then proposes some solutions which are all, on the whole, worse than the status quo for various reasons. For example, forcing all Windows machines, whether they're turned on or connected to the internet or not, to patch at the very same instant is not realistic.
They should've called this thing: "Windows Update has problems. Magic can fix them."
Which just shifts the problem. (Score:5, Interesting)
Which shifts the problem from distributing the update to distributing the key.
Of course this does have another advantage: Distributing the encrypted update also distributes notification that there WILL be a key, and can tell the users when. Then it becomes a race to get the key and apply the patch before the bad guys can get the key, generate, and deploy an exploit.
And the downside: The bad guys also know the patch is coming, and when. So they can use their existing botnet(s) to grab a key as soon as possible, then DDOS the key distribution mechanism while they generate and deploy the exploit. This makes things WORSE: A much larger fraction of the machines are vulnerable when the exploit deploys.
Still worse: If the bad guys crack the encryption, or manage to break in and grab the key early, they get to automatically generate and deploy an exploit while NOBODY has the fix. Oops!
Ditto even if they don't crack the patch - but the patches exposes that a vulnerability exists and perhaps what module has it, and they find and exploit the vulnerability before the key deploys.
= = = =
In a battle between weapons and armor, weapons eventually win.
It's impressive (Score:4, Interesting)
For instance, when they come up with the exploit for WMF reader vulnerability, they're not making you a new WMF file (as I understand, anyway).
One thing that interested me is the model they invented. The binary differencing was off-the-shelf stuff from eEye. But their model of the x86 machine (cpu, instruction side effects, registers, and memory) is new, and that seems like something that could have been written previously.. I'm surprised they needed to do this. They also define a space of functions that examine the model to determine if badness has happened, for each specific kindof badness they're interested in, i.e. return address changes during execution of call.
They also appear to require execution traces of P (or P') to run under a machine monitor; I don't think from the instructions in P they work backwards from P/P' difference lines and construct initial conditions of the machine state. Even if that _is_ what they were doing, they only model the salient portions of the binary, not the outside system.
Even so, what they're doing here is fantastic. The things they're not doing (automatically creating files that trigger the exploit) are all possible offshoots from this paper, if one were to have sufficient computing power and time to create models of the salient portions of the system. For each different data flow into the instruction/memory space, the model would need to describe the line of demarcation. In the case of the WMF/PNG vulnerabilities, that line is on the other side of readfile or mmap or whatever. (i.e. the bytes that trigger the exploit come from the disk). Building a file on disk in a certain way to cause a sequence of x86 instructions to produce the desired memory is a hard problem in and of itself, although I perhaps possible with the tools and techniques they've already got.
The same would be true of the ASP.NET vulnerability. I beleive they can work backwards from exploit to the in-memory representation of a URL request. At that point, knowing that URLs come from the outside hostile internet, through IIS, etc etc etc, is vuln-specific domain expertise. However, a library of injection points (file on dist, URL request from network, packet from network, etc) could be built around the analysis model. The analysis engine works backwards until it says "here is the memory precondition that leads to an exploit, now i rely on an injection plugin to acheive that memory state."
No hash can be guaranteed secure forever (Score:4, Interesting)
And CRC was never designed to be in the least secure against that sort of thing in the first place. It's a good error checker, but it's not secure.
Yes, there are newer hashes that don't currently have any known vulnerability. But none of which you can be confident that they'll still have no vulnerability in half a decade's time. And if Microsoft were to build what you're suggesting into Windows, a vulnerability beign discovered in whatever hash they used would be a death-knell. How could Microsoft possibly fix it? Distribute a patch to change the hash -- over the compromised patch distribution network?
Such a system would be impossible to secure (Score:2, Interesting)
Except that MD5 has been cracked. That is to say, there are known methods of creating a file with a high probability of having the same MD5 as some original file.
Yes, there are newer hashes that don't currently have any known vulnerability. But none of which you can be confident that they'll still have no vulnerability in half a decade's time.
And if Microsoft do what you've suggested and build such a system into Windows, what would happen if a vulnerability is discovered in the hash they used? How could Microsoft possibly fix it? Distribute a patch to change the hash used -- over the compromised patch distribution network...?
Re:Doesn't matter (Score:3, Interesting)
There are plenty of ways to do encryption, ultimately you'd need some form of DRM to make it work. Because at some point, it'd need to be decrypted into memory on the client's machine, and without DRM, there is nothing to stop a 3rd party app from retrieving it from memory.
Obfuscation however could work pretty well, because if they patched not just the exploit, but shuffled everything around in the process, they couldn't just do a diff to find out what they changed, as everything would of changed.
They'd need to create a tool to unobfuscate the differences, and highlight what has been patched.
The problem being it becomes an arms race in the same way DRM is an arms race. Microsoft would have to keep inventing new obfuscating logarithms, and the crackers would have to keep working out how the current logarithm obfuscates.
Not to mention, the potential for obfuscation to introduce bugs could be very problematic.
Re:Which just shifts the problem. (Score:2, Interesting)
To prevent unpatched (non-internet-connected) systems from being a danger; 'WGA notification' and 'Windows activation' should be expanded to 'Patch notification' and 'Patch activation'. Failure to activate the patch in X days will result in special restrictions imposed on network connectivity.
I.E. All operations disabled except for patch download. Meaning you can reconnect to the internet, but you must download and activate the patch, before Windows will re-enable surfing.
The key distribution mechanism can be designed to be resilient. Use 128-bit keys -- just large enough to make cracking hard. Due to the small size of the keys, this should be very easy. Give every patch a unique ID and put something like a SHA256 hash of the legitimate key in the header (so any system seeing the key can easily pick it up and inexpensively see if it is the legitimate key, and which version of the patchset it unlocks)
MS could utilize an ad-hoc peer to peer network. Windows systems will share the key. Once a machine knows the key it will transmit to some of its buddies in the form of a datagram.
The key should actually decrypt a file that contains the _real_ encryption key for the relevant patch, as well as the keys to all prior-released patches. That way the latest 'key' is all you ever need, when applying many updates later on (for example, to a newly installed system).
Utilize local-subnet broadcast or a special IPv6 multicast address for each specific patch. When a windows box is waiting for the key, it will join that multicast group. When a windows box on a LAN finally gets the latest patchset key, it will send the key out as a small packet to that multicast address.
Utilize default-domain records.. I.E. ISPs can publish the key using a DNS TXT record ._windows.defaultdomain IN TXT "key here"