Friday, January 22, 2016

Bridging the "Security Update Gap" With 0patch

Vulnerability Patches Can be Really Small and Easy to Apply

Yesterday we tweeted a proof-of-concept actual micropatch for the "Winshock" vulnerability (CVE-2014-6321, MS14-066) in Windows schannel.dll. The patch fixes a buffer overflow vulnerability that allowed attackers to execute arbitrary code on any SSL-enabled IIS server. (Thanks to Mike Czumak, BeyondTrust and Malware Tech for their awesome analyses, especially Mike for also sharing his method for triggering the bug.)

Our "0patch" for Winshock consists of just 11 machine instructions (28 bytes), which is a fairly typical size for a 0patch judging from over 300 0patches we've written so far. To put these 28 bytes in perspective, you should know that the official Microsoft's update that fixed the same vulnerability (although it might also have changed some other bits here and there) was 243 KB, which makes our 0patch roughly 8,800 times smaller than the official fix.

You have to understand that vendor updates - be it Microsoft's, Adobe's, Oracle's - simply replace entire executable files, even if just a single sanity check has been added to them to fix a vulnerability. This has several unpleasant side-effects:

  1. In order to replace an executable file that is currently in use by one or more running processes (which is often the case, including with the above-mentioned vulnerability), these processes need to be terminated, which leads to something we all hate: restarting the computer.
  2. In the unlikely but possible event that the vendor update should cause functional problems, reverting the change (i.e., uninstalling the update) again requires a computer restart. In contrast to installing updates, which can be managed centrally for an entire enterprise, uninstalling requires manual handling of each affected computer - which is especially difficult with laptops traveling around the world.
  3. Large updates are impossible for administrators (or basically anyone) to thoroughly review before installing. What are the changes they introduce, do they also "silently" modify some functionality? 

As a result, enterprise administrators schedule extensive and lengthy testing of vendor updates before installing them in production. It is common to have vendor updates installed in an enterprise several months after they have been released. Think about it: attackers start reverse-engineering vendor updates the same day these get released, and often have reliable exploits in just a few days. Defenders, on the other hand, are struggling with testing these updates and remain vulnerable to exploits extracted from official vendor updates. By the time defenders have finally installed vendor updates from two months ago, they're already vulnerable to the exploits from last month's updates. The game seems to be eternally rigged in favor of attacker.

Now this problem is getting a solution. 0patch can help defenders bridge this "security update gap" by 0patches protecting them from newly extracted exploits while the official updates are being tested. Since creating a 0patch from an official update is a similar process to creating an exploit from the same update, defenders finally have a chance to compete with attackers - and even outrun them.

And why would administrators dare to apply 0patches to production without rigorous testing? Here's why:

  1. 0patches are designed to be applied to running processes. This means that the above-mentioned Winshock 0patch gets applied to a running IIS server without having to even restart a service, much less the entire computer.
  2. 0patches are designed to be removed from running processes just as easily - no restarts. This allows admins to instantly revert to pre-0patched state (i.e., instantly un-applying the Winshock 0patch from a server).
  3. Both applying and removing 0patches can be done remotely, from a central location.
  4. 0patches are so small that anyone with some knowledge of machine programming can review them. This means that administrators know exactly what changes they're introducing by applying 0patches.

Making the "security update gap" a thing of the past is one of our most important goals. Until we get there, no matter what security technology corporate and government networks are using, breaking into them will remain a child's play.

Subscribe at and become part of the solution.



  1. Will micro patch sourcecode be made available at all times ?

    I consider it essential to the reputation and trustworthiness of 0patch.

    1. Yes, it is our intention to have the source code for every micropatch published as soon as a micropatch is issued. We agree that this is essential to the reputation and trustworthiness of 0patch.