Friday, April 25, 2008

Should Microsoft encrypt/obfuscate patches?

Securityfocus has this story about a group of researchers that have found a way to semi-automate the creation of exploits.
... Microsoft has not taken adequate steps to make such attempts more difficult, Brumley said. The researchers suggested possible avenues that Microsoft could pursue to increase the likelihood that customers received patches before attackers could reverse engineer them, including obfuscating the code, encrypting the patches and waiting to distribute the key simultaneously, and using peer-to-peer distribution to push out patches faster.

The researchers recommend the above for Microsoft. However, each method may create more problems than it solves. Let us consider them, one by one:
1)Obfuscate the code - Obfuscating the patching code doesn't help at all. One could simply snapshot the system before and after applying a patch and get the diffs. Obfuscating the application code (the application that is being patched) if done manually will make it prone to more bugs and hence more exploits. Automated obfuscation will not introduce any extra bug/exploits but it could make the application run slower.

2)Encrypt the patches and withhold the key - Well, the key will have to be distributed eventually. The window of opportunity for automated exploit generators will be smaller assuming the key can be distributed faster than the patch. However, the window of opportunity for zero-day exploits will be bigger. Also, the exploit generation can be done by using as input IDS/IPS signature updates instead of the patch. So should you encrypt those as well and withhold the key?

3)Using peer to peer distribution of patches - This could work...but why is it better than using other content delivery methods?

No comments: