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:3, Informative)
Instant patching is never going to happen. (Score:4, Informative)
The fundamental problem here is that a lot of security depends on single points of failure. A real security system relies on the "defense in depth" approach.
From the PDF: (Score:5, Informative)
1) Patch Obfuscation: basically an attempt to hide exactly what the patch fixes by padding out the patch with a lot of lines of nonsense. While this might prove effective, it would only be effective until an improved algorithm for discerning the true reason for the patch is found, and in the meantime, it would create its own set of problems, particularly if the level of obfuscation required balloons the size of the patch to an unmanageable degree.
2) Patch Encryption: basically distributing the patch in an encrypted format, waiting until it is reasonable to assume that everyone has the patch, and then transmitting a decryption key to decrypt and apply the patch more or less "simultaneously". Problems: this only pushes the problem back one level; meaning the same method of exploitation is just as possible, while this also creates an unacceptable time lag for patches to be applied, which hackers who write exploits the old-fashioned way can exploit to their considerable benefit.
3) Fast Patch Distribution: basically leveraging technologies like P2P to insure that patches are rolled out...well...fast. Problems again include off-line hoists, as well as hosts who have the misfortune of being on ISPs that take a dim view of P2P.
In summary, none of the methods outlined have much of a chance to combat this new threat.
Re:This article is dumb. (Score:3, Informative)
If you had, you'd know that this paper did not say that "hackers can analyze Windows Updates and figure out how to attack systems that aren't patched yet thereby". What it did say was that it is possible to write software that can analyze the update for you and churn out an exploit for the security issue identified thereby...in a matter of seconds.
Automatically deriving exploits by theorem proving (Score:5, Informative)
This is fascinating. As someone who's worked with automatic theorem proving and proof of correctness techniques, I'd never thought of using them in this way.
What they're doing works like a proof of correctness system in reverse. They difference executables before and after the patch (which in itself is impressive), then, having isolated the patch, analyze it automatically. Security patches usually consist of adding a test which constrains the valid inputs at some point. So they use a symbolic decision procedure, which is part of a theorem prover, to work back through the code and automatically derive a set of inputs that would be caught by the new test.
This is more than just an attack on Windows Update. It's true automated exploit generation.
This is potentially applicable to any security-critical code that changes over time. One could, for example, have something that watched check-ins to the Linux kernel tree and developed new exploits to current stable releases from them.
Re:Where's the WellDuh Tag (Score:3, Informative)
Not only can you reverse engineer the binary, but you have access to the source code and it's modifications. If you read bug trackers or dev mailing lists, you can even pick up security vulnerabilities before the patch is even released just by looking at bugs and diff files.
You can't put the toothpaste back in the tube, people. Arguing that that means you shouldn't brush your teeth is ridiculous.
Re:Doesn't matter (Score:2, Informative)
One real world example of essentially the same thing: FIRST Robotics [usfirst.org] wants to make sure that everyone has access to the game manual at the same time at the start of the build season without creating a massive load on their servers, and to make it available for those who don't have internet access where they watch the kickoff. They begin distributing an encrypted version of the manual a week in advance, then release the decryption key during the kickoff video.
It works fairly well, but this is a very special case where not releasing early is the primary concern. A cool idea, but I don't see it working (or helping) for updates, especially for small updates that may not be much larger than the key to begin with. It may be more effective for large updates (iPhone firmware updates, for example) where the download size can be prohibitive.