Thanks for sharing this. I suspected that "not being sure if you have the exactly right source code" could be a real world reason to patch a binary, and now I know.

ryanburk, thanks a lot for your comment. We at 0patch are big fans of MS Patch Tuesday from it's very beginning. It was a huge improvement for appsec for more than decade and it still is. But as active pentesters with more than 15 years of experiences we just noticed that our enterprise customers can not apply patches timely and usually their (also critical) systems remain unpatched for several months. It looks they cannot cope with the amount of update changes and testing so they rather decide not patch. That was even worse than not to have a patch from official vendor.

There is one important technical difference between small pre-PatchTuesday patches and micropatches: pre-PatchTuesday patches were installed binaries (actually complete new version of the product) that are here to stay forever – or at least until patch uninstall or product upgrade. Imagine how hard is patch uninstall on CEO's patch-corrupted system on a business travel, for instance. Micropatches only live in memory, they die with the process. They don’t change file system and installed product, just redirect maliciously used instruction (just instruction, not the whole function) to correct path, if possible. It’s just couple instructions any admin could review by himself and switch of, if there is a problem. I wish I could say that for today’s patching procedures. For us it is the idea worth trying. We just have to simplify updating process for users (and software vendors, too).

p.s.: we are aware Microsoft gave up the idea of hot patching some years ago, but as I know they were not changing just couple of instructions. Please correct me if I’m wrong.

It sounds like you should include this brief 'how it works when applied/how this affects your machine' explaination of your tech even in this super-technical deep-dive blog post.

You're absolutely right - we have this information scattered around blog posts and other material but it should be laid out in one place and in not-too-techy language. Thanks for pointing it out.

Hi, Stanka from 0patch here. If you want to enable or disable (aka "patch" or "unpatch" the application) you don't need do restart the application. Not even if your app is running and you've just install 0patch agent. This is how it is designed to work in user space. When the official MS patch is installed (hopefully with the fix) this particular 0patch won't apply anymore.

As we try to make 0patch agent robust and reliable we don't support kernel mode at this moment - we will make this step slow and with great caution.

Can you please clarify whether or not this specific patch is user mode or kernel mode? @johntb86 mentioned GDI is split and this is the user mode part.

Our micropatch (7 of them, really, for 4 different Windows OS versions) for CVE-2017-0038 is user-mode. As are currently all our micropatches. Processes using gdi32.dll do not need to be relaunched to have it applied.