If you're running
Windows 10 v21H1 in your organization, all you need to do is install
0patch Agent on these computers and register it to an account with PRO
or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them.
These micropatches will be included in 0patch PRO and Enterprise
licenses along with all other micropatches we're issuing - which means
that users protecting their Windows 10 v21H1 with 0patch will also
receive our micropatches for "0day" vulnerabilities in
various products.
In order to have our micropatches applied, Windows 10 v21H1 will have to have December 2022 Windows Updates (the last official updates for this version) installed.
We welcome all interested organizations to contact sales@0patch.com
for information about pricing, deployment, or setting up a trial.
P.S.: We're getting close to Windows Server 2012 end of official support by Microsoft in October 2023. You guessed it, we're going to security-adopt this server as well, in case you're already getting nervous about that. This is a good time for you to start a free 0patch trial, so send an email to sales@0patch.com.
To learn more about 0patch, please visit our Help Center.
With November 2022 Windows Updates, Microsoft fixed a vulnerability in Internet Explorer's JScript9 engine that was found being exploited by North Korean government-backed actors known as APT37. The vulnerability is of a "type confusion" sort, which means that malicious JavaScript code can confuse the JavaScript engine into thinking that a certain object is of one type (in our case, Int32Array) while it's actually of another type (in our case, Object) - and that quickly leads to reading or writing memory addresses that were not supposed to be available to said code. From that point on, arbitrary code execution can be achieved.
Microsoft assigned this issue CVE-2022-41128 and fixed it by removing a code branch that was dependent on a call to function ShouldExpectConventionalArrayIndexValue; in the patched code, this function call is skipped so the code always continues down the same path.
Admittedly, we did not investigate what really went wrong with this vulnerable code and just logically replicated Microsoft's patch as we trust they know what they're doing. Our
micropatch thus only has one instruction that jumps over the now-excluded code:
code_start jmp PIT_0x21581 ; jump over the excluded code block code_end patchlet_end
The micropatch was written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909
Windows 10 v1809
Windows 10 v1803
Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank Benoît Sevens and Clément Lecigne of Google's Threat Analysis Group (TAG) for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
September 2022 Windows Updates brought a fix for a remotely exploitable vulnerability in the Enterprise App Management Service, discovered by security researcher Ceri Coburn of Pen Test Partners. On October 13, they published a blog post describing the vulnerability in detail, and a proof-of-concept.
The Enterprise App Management Service allows Windows admins to centrally perform various installation and application provisioning-related actions on multiple Windows computers in the network. Due to lax permissions, a non-admin attacker could perform the same actions, potentially leading to a malicious application being installed and launched on the target computer.
Microsoft's patch added code for checking whether the requestor has administrative privileges on the computer, and our patches do logically the same.
Our micropatches were written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909
Windows 10 v1809
Windows 10 v1803
Micropatches have already been distributed to all
affected online computers running 0patch Agent with PRO
or Enterprise license. To obtain the relevant micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank Ceri Coburn and Pen Test Partners for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
Update 12/13/2022: Microsoft patched this issue with December 2022 Windows Updates and assigned it CVE-2022-44698. Our patches for this issue were freely available 46 days before the original vendor patch, and now require Pro or Enterprise license.
Update 3/15/2023: The patch Microsoft created for CVE-2022-44698 in December turned out to be flawed and its bypass was found to be exploited in a Magniber ransomware campaign to trick users into launching a malicious MSI file without any security warnings. Microsoft assigned this bypass a separate CVE ID CVE-2023-24880 and patched it with March 2023 updates. Their patch is in the same function as our own patch from last October, and like our patch, makes sure the user is shown the typical Mark-of-the-Web warning for files with a malformed signature but while we decided to show users a typical Mark-of-the-Web security warning for files with a malformed signature, Microsoft decided to silently error out by doing exactly what we considered doing - but decided not to as it would confuse users (see below). As our original patch from October is not affected by this bypass (the user still gets a security warning), we don't need to create an additional patch for CVE-2023-24880. We thank Benoît Sevens of Google TAG for sharing their analysis with the community. As far as this bypass goes, our patches for it were available 137 days before the original vendor patch; 0patch users on end-of-support Windows systems were protected against this since last October.
Nine days ago we issued micropatches for a vulnerability that allows attackers to bypass the warning Windows normally present to users when they try to open a document or executable obtained from an untrusted source (Internet, email, USB key, network drive). That vulnerability, affecting all supported and many legacy Windows versions, still has no official patch from Microsoft so our (free!) patches are the only actual patches in existence as of this writing.
On the very same day we issued these micropatches, Will Dormann - who researched said vulnerability - replied to a tweet by another security researcher, Patrick Schläpfer. Patrick works at HP Wolf Security where they analyzed the Magniber Ransomware and wrote a detailed analysis of its working. Will asked Patrick about the ZIP files used in the malware campaign to see if they were exploiting the same vulnerability or employing some other trick to bypass the "Mark of the Web".
Patrick responded that malicious files extracted from the attacker's ZIP files did have the Mark of the Web but still executed without a security warning. Remember that on Windows 10 and Windows 11, opening any potentially harmful file triggers a SmartScreen inspection of said file, whereby SmartScreen determines if the file is clear to get launched or the user should be warned about it (see image below).
SmartScreen determined that this file could be harmful and warned the user. The user needs to click "More Info" and then press "Run" if they really want to open the file.
When deciding whether to trust the file or not, the Mark of the Web plays an important role: files with this mark are considered unconditionally untrusted as they originated from an untrusted source. So why did these malicious Magniber files not trigger the SmartScreen warning?
Patrick remarked that Authenticode signatures on extracted malicious files must have been causing this behavior because with signatures removed, the warning would (correctly) appear.
Will then noticed that these signatures were not valid at all and should not have been trusted by Windows. In fact, they were malformed such that Windows could not even properly parse them. This, for some peculiar reason, led to Windows trusting them - and letting malicious executables execute without a warning.
And so a new 0day - already exploited in the wild - was revealed.
This information was sufficient for us to start our patch development process. We reproduced the issue using a sample .JS file with various malformed signatures until we reached the flawed execution path that bypassed the SmartScreen warning. We then searched for the cause, and found... well... it's complicated.
The logic behind determining whether to show a security warning to the user, and whether to show the SmartScreen warning or the old "Open File - Security Warning" dialog, is complex and distributed among various executable modules. An application attempting to open a file on user's behalf partly inspects the file itself to decide whether to send it to further inspection by SmartScreen, and if so, sends a DCOM request to SmartScreen.exe, which is another process constantly running on Windows. SmartScreen.exe then does its own inspection and, if networking is available, asks Microsoft's servers for an opinion, displays the warning if needed, then delivers the final verdict back to the requesting process in form of an error code and the information on user's decision ("Run" or "Don't run").
What looked like the most serious flaw to us was the fact that when SmartScreen.exe returns an error, this would be considered identical to the user having pressed "Run." A strange decision, security-wise.
The malformed signature discovered by Patrick and Will caused SmartScreen.exe to throw an exception when the signature could not be parsed, resulting in SmartScreen returning an error. Which we now know means "Run."
Mystery solved. Now let's patch it.
To understand our patch, we need to take a closer look at function DoSafeOpenPromptForShellExec in shdocvw.dll as this is the function that performs the flawed logic. The image below shows the relevant part of its code: register edi is initialized to 0 and is reserved for holding the final decision on whether to run/open the file or not. The function sends a request to SmartScreen and waits for its response, then based on the error code returned takes the left or the right branch. The right branch, executed when there was no error, stores the user's decision to edi; the left branch, executed when SmartScreen returned an error, leaves edi on 0 - which explains why an error equals the user's decision to run/open the file.
The simplest way to fix this would be to simply initialize edi to a value that would mean "Don't run", whereby any error in SmartScreen would lead to the file not being run/opened. However, this approach might confuse users as such files would just silently not run/open without any feedback to the user.
[Update 3/15/2023: Microsoft's patch for CVE-2023-24880, however, does exactly this and silently errors out, leaving the user confused - but secure.]
We therefore decided on a different approach: in the same function, there is a code block that displays the old "Open File - Security Warning" dialog to the user, and in case of a SmartScreen error, we redirect execution to that block. This way, when SmartScreen errors out, the user is presented with the old security warning and can still select whether to run/open the file or not.
While our patch fixes the most obvious flaw, its utility depends on the application opening the file using function DoSafeOpenPromptForShellExec in shdocvw.dll and not some other mechanism. We're not aware of another such mechanism in Windows, but it could technically exist. Our tests with opening files directly from Windows Explorer, from ZIP files opened with Windows Explorer, and directly from most major web browsers and email clients were successful. Except with Google Chrome, which we've long ago decided not to patch because its sandboxing model is causing us problems with injection. And even if we did patch Chrome, there is another weird logic in shdocvw.dll that gets executed in Chrome due to sandboxing which for some reason prevents SmartScreen from returning an error while still not showing the warning. We did not investigate the latter any further.
We did, however, investigate a possibility of patching SmartScreen.exe, which could potentially cover all cases, but that would have to be a much more complex patch. In addition, the SmartScreen code can throw an exception in numerous places in addition to the one triggered by a malformed signature, and each of these could lead to the same warning bypass.
Needless to say, we're very interested in learning how Microsoft will fix this issue. Meanwhile though, our patch probably covers the majority of attack scenarios.
Our Micropatch In Action
You can see the effect of our micropatch in the following video. There are two executable files on the desktop: goodsig.exe and badsig.exe. Both are really just calc.exe and both have the Mark of the Web, but the former has a proper parsable signature while the latter has a malformed, unparsable signature that causes SmartScreen to error out.
Without our micropatch, double-clicking goodsig.exe correctly shows the SmartScreen warning because any executable with Mark of the Web should trigger the warning. Double-clicking badsig.exe, on the other hand, just launches the executable without any warning - demonstrating the vulnerability.
With 0patch enabled and our micropatch applied, double-clicking goodsig.exe behaves the same as before (which is still correct), but double-clicking badsig.exe now triggers the "Open File - Security Warning" dialog, warning the user and allowing them to back out via the "Cancel" button.
Micropatch Availability
Since
this is a "0day" vulnerability with no official vendor fix available,
we are providing our micropatches for free until such fix becomes
available.
Micropatches were written for:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows Server 2022
Windows Server 2019
Note that Windows 7 is not affected by this issue, neither are Windows Server 2008 and 2012.
These
micropatches have already been distributed to all
online 0patch Agents. If you're new to 0patch, create a free account
in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboot will be needed.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Patrick Schläpfer for sharing the details on their Magniber ransomware analysis and Will Dormann for their analysis of this vulnerability that allowed us to reproduce it and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
On September 24, 2022 we were made aware of a POC for a Print Spooler elevation of privilege vulnerability discovered by security researcher luckyu with NSFOCUS TIANYUAN LAB. It turned out to be another symbolic link issue that Print Spooler has quite a history of.
The POC sets up a new printer with a custom spool directory as a non-admin user. This directory is a symbolic link to another directory, which contains a .SHD file that is itself again a symbolic link to some existing file which a non-admin user lacks permissions to delete. Then, by using file locking and performing some operations on the printer, the Print Spooler process (running as Local System) is made to delete said .SHD file, which in fact deletes the file it points to. A non-admin can therefore delete any local file that Local System is able to delete. This can, surprisingly, lead to arbitrary code execution using a trick earlier discovered by another researcher Abdelhamid Naceri and described in this ZDI article.
Microsoft assigned CVE-2022-30206 to this issue and fixed it with July 2022 updates. Not for everyone, of course: we determined that older Windows versions that had stopped receiving updates by then were also affected, and therefore needed our patch.
Having decided to patch this issue, we analyzed it, found the root cause and determined that the best approach would be similar to what we've done with other symbolic link issues in Print Spooler before: add a check in localspl.dll before the DeleteFile call to see if a path to the .SHD file is a symbolic link - and skip the deletion in case it was. This would not break the typical use case without symbolic links, and we doubt that any legitimate use case would involve a .SHD file being a symbolic link.
Having written such micropatch, we started testing it and discovered something peculiar: the linked-to file still got deleted even if our patch properly bypassed the DeleteFile call. What was going on?
It turned out that while we have patched the issue at hand, there was another very similar issue elsewhere in the code that also led to deleting the .SHD file. Interestingly though, this issue was not present on a Windows 10 v1909 updated to its last updates in May 2022. This version of Windows 10 was the last security-adopted Windows version at the time and received Windows updates a bit longer than others - which meant that it must have received a patch for this "newly discovered" issue while others haven't.
To identify this second issue, we tested the POC with our patch on Windows 10 v1909 with different Windows updates starting with May 2022 (the last updates for v1909) and going back in time. This revealed that the issue was fixed with February 2022 updates.
Looking at all vulnerabilities fixed with February 2022 updates, only one fit the description: CVE-2022-21997. It was a "Windows Print Spooler Elevation of Privilege Vulnerability", with the Microsoft advisory stating that "an attacker would only be able to delete targeted files on a system." The issue was reported by Bo Wu, whom we tried to contact for confirmation but unfortunately so far failed to reach.
In any case, it would make no sense to only patch the originally intended CVE-2022-30206, so we also went on to patch this "bonus" issue CVE-2022-21997. We did that with an identical patch, just in another location in localspl.dll. With both patches in place, the POC and the technique it was using no longer worked.
These micropatches were written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909 (CVE-2022-30206 only)
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
Micropatches have already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain these micropatches and have them applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank luckyu for publishing their analysis with a
proof-of-concept that allowed us to reproduce both vulnerabilities and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
September 2022 Windows Updates brought a fix for an elevation of privilege vulnerability in Kerberos protocol, discovered by James Forshaw of Google Project Zero. James published a detailed analysis, and a POC was subsequently added to their Rubeus tool.
Microsoft assigned James' finding two separate CVE IDs, CVE-2022-33647 and CVE-2022-33679, but these really both have the same root cause, namely the fact that Kerberos supported two weak encryption types: RC4-MD4 (type -128) and RC4-HMAC-OLD (type -133).
James demonstrated that downgrading encryption to RC4-MD4 can allow an attacker to extract the Ticket Granting Ticket (TGT) key and use it for requesting a new TGT for the targeted user, which can be used for launching any code on the domain controller as said user.
Microsoft removed support for both weak encryption types from the Kerberos code. Our
micropatch, written only for Windows Server 2008 R2 (the only server that didn't get Microsoft's patch) is logically
equivalent to Microsoft's:
cmp ecx, 0xFFFFFF80 ; is encryption type RC4-MD4? je ERROR ; if so, error out cmp ecx, 0xFFFFFF7B ; is encryption type RC4-HMAC-OLD? jne SKIP ; if so, error out ERROR: mov rax, 0x0 ; rax 0 means "unsupported" retn
SKIP:
code_end patchlet_end
This video demonstrates the effect of our micropatch. With
0patch disabled, launching the POC against a vulnerable Windows 2008 R2 server provides a Ticket Granting Ticket for server's administrator, which then makes it possible to launch a remote terminal session to the server as that user. With 0patch enabled, RC4-MD4 is no longer accepted and the attack fails.
This
micropatch has already been distributed to all
online Windows Server 2008 R2 computers running 0patch Agent with PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank James Forshaw of Google Project Zero for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
Update 11/8/2022: This issue, nicknamed "ZippyReads", got an official fix with November 2022 Windows Updates which assigned it CVE-2022-41049. Our micropatches for it are therefore no longer free and require a PRO or Enterprise license. Details have also been published.
In May, security researcher Will Dormann found a vulnerability in Windows that allows an attacker to prevent Windows from setting the "Mark of the Web" flag on files extracted from a ZIP archive, even if the ZIP archive came from an untrusted source such as Internet, email, or a USB key.
Mark of the Web (MOTW) is an important security mechanism in Windows:
Windows will show a security warning before launching an executable file with MOTW;
Microsoft Office blocks macros on documents with MOTW (source).
Attackers therefore understandably prefer their malicious files not being marked with MOTW; this vulnerability allows them to create a ZIP archive such that extracted malicious files will not be marked.
Will has notified Microsoft about this issue in July, but an official fix has not been provided yet. Meanwhile, the vulnerability is apparently being exploited in the wild.
We're happy to report that we've just issued micropatches for this vulnerability, and are - according to our guidelines - providing it free of charge until Microsoft has issued their official fix.
We will not provide details on the vulnerability at this point.
Our Micropatch In Action
The video below shows our micropatch in action. With 0patch disabled (and the micropatch therefore not applied), an executable file in a ZIP archive that is marked with MOTW executes without a warning, because the file itself is not marked with MOTW upon extraction. With our micropatch in place, the extraction code is corrected and properly applies the MOTW to the extracted file - which results in the security warning being shown to the user.
Similarly, an attacker could deliver Word or Excel files in a downloaded ZIP that would not have their macros blocked due to the absence of the MOTW (depending on Office macro security settings), or would escape the inspection by Smart App Control.
Micropatch Availability
Since
this is a "0day" vulnerability with no official vendor fix available,
we are providing our micropatches for free until such fix becomes
available.
Micropatches were written for:
Windows 11 v21H2
Windows 10 v21H2
Windows 10 v21H1
Windows 10 v20H2
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 with or without ESU
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2 with or without ESU
These
micropatches have already been distributed to all
online 0patch Agents. If you're new to 0patch, create a free account
in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboot will be needed.
To learn more about 0patch, please visit our Help Center.
Extended Security Updates about to be terminated? Don't worry, we have your back.
by Mitja Kolsek, the 0patch Team
Is your organization still using Windows 7 or Windows Server 2008 R2? We understand: these are good stable Windows versions that just work, do not force you to perform unneeded upgrades that change your user interface, don't distract users with ads and news they never wanted to see, don't send tons of telemetry data to Microsoft and most of all, reliably support your work processes.
Perhaps you've kept using these Windows versions without any security updates when free updates were terminated in January 2020 (narrator: "That's a bit risky."). Or you may have purchased Extended Security Updates (ESU) to keep receiving official security fixes from Microsoft (narrator: "That's a bit expensive."). Or, you may have been using 0patch to keep running Windows 7 and Server 2008 R2 securely by receiving our security micropatches for the most-likely-to-be-exploited critical vulnerabilities.
If you chose the Extended Security Updates path, you have a big decision ahead of you, as these updates are about to be terminated soon: Windows 7 and Windows Server 2008 R2 (on-prem) will receive their last ESU update in January 2023.
After that, no new security patches for these two Windows versions will exist.
... is what could be said if it weren't for 0patch.
We have decided to keep providing security patches for Windows 7 and Windows Server 2008 R2 for critical vulnerabilities that are likely to get exploited, and will be happy to keep you secured for a fraction of what you had paid for ESU so far. And you won't have to restart your computer even once, because our patches are applied directly in the memory of running processes instead of changing your executable files!
If you're using ESU and want to continue with 0patch, just keep applying all remaining ESU updates, including the last one in January 2023. Then install 0patch Agent on all your Windows 7 and Server 2008 R2 computers, and register it to your 0patch account holding a suitable amount of licenses.
That's it. No really, that's it.
I mean, that's it if you want to "set and forget" 0patch, which many of our users actually do. Otherwise you can use 0patch Central to decide which of our micropatches shall be applied on which computers by organizing computers in groups and setting group-specific patching policies. (Enterprise licenses are needed for that.)
Of course it would be a good idea to test 0patch in your environment first instead of waiting until January. We'll be happy to set you up with a trial so you can see how 0patch works and how it co-exists with other components in your environment. Just email sales@0patch.com and you'll be quickly on your way.
Frequently Asked Questions
Q: How long do you plan to provide critical security patches for Windows Server 2008 R2 and Windows 7 after January 2023?
A: For at least two more years - until January 2025. Depending on the demand, we'll consider a further extension.
Q: How many vulnerabilities have you patched for Windows Server 2008 R2 and Windows 7 since January 2020?
A: Since January 2020 when we "security-adopted" Windows 7 and Windows Server 2008 R2, we have issued patches for 52 critical security issues on these systems that were at high risk of being exploited. Many of them were later actually confirmed to be exploited in the wild and even more of them became part of various exploit kits that even a low-budget attacker could easily use against unpatched systems.
Q: We haven't been using Extended Security Updates and have had no security patches since January 2020. Can we still use 0patch to get up to speed with critical security patches?
A: Of course. Just make sure you have January 2020 updates installed on your Windows 7 and Server 2008 R2 computers and start using 0patch; it will apply all micropatches that other users without Extended Security Updates have been receiving since 2020.
Q: We have been using Extended Security Updates but only for one or two years. Can we still use 0patch to get up to speed with critical security patches?
A: Absolutely. All micropatches for Windows 7 and Server 2008 R2 we have ever issued were ported written for fully updated computers (1) without ESU, (2) with only the first year of ESU, and (3) with only the second year of ESU. We'll keep doing this, and will - starting with February 2023 - also port new patches to fully updated computers (4) with the the third year of ESU, so anyone can join in and get all our patches.
Q: Are your micropatches actual code patches or "virtual patches"?
A: Our patches are actual code patches; we add a couple of CPU instructions to the original (vulnerable) executable code to remove the vulnerability. Such patches cannot be bypassed, which literally any other exploit protection mechanisms - including virtual patches - can be.
Q: What is the main difference between 0patch patches and original vendor patches?
A: These are the main differences:
Our patches are applied in memory only and don't modify executable files.
Due to the above, applying or un-applying our patches does not require you to even relaunch patched applications, much less restart the entire computer.
Our patches are really tiny, usually just a couple of CPU instructions; by modifying only the tiniest possible fraction of original code we also minimize the possibility of introducing new flaws in the code.
Q: Are you also going to security-adopt Windows Server 2012 when it reaches end of support next year?
A: Yes we are.
Q: We'd like to see a demo.
A: Send an email to sales@0patch.com and provide your company name and time zone so we can suggest a couple of dates for the demo.
Q: We'd like to set up a trial.
A: Create a free account in 0patch Central, then let us know at sales@0patch.com which email you used for that so we can issue a couple of trial licenses to your account.
Q: We have more questions about 0patch
A: Our Help Center has a lot of answers but if you can't find yours there, feel free to contact us at sales@0patch.com.
September 2022 Windows Updates brought a fix for a remote code execution vulnerability in Windows IKE Extension discovered by Yuki Chen with Cyber KunLun. Soon after that, researchers from 78ResearchLab published an analysis and POC for this vulnerability. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.
The vulnerability is in the code responsible for handling IKEv1 (Internet Key Exchange version 1) key exchange protocol, which is deprecated but still supported for legacy reasons. It is a memory corruption issue, with the POC causing the svchost.exe process hosting the IKEEXT service to crash by attempting to read data beyond an allocated buffer. The crash only occurs with page heap (a debugging accessory) enabled for the process, while in a typical production configuration, the vulnerability could potentially be used for arbitrary code execution (as confirmed by Microsoft's advisory).
Microsoft assigned this issue CVE-2022-34721 and fixed it by adding a check for the length of incoming data, and bypassing the processing of such data if the length is too small. Our micropatch is logically
equivalent to Microsoft's:
patchlet_start PATCHLET_ID 1 PATCHLET_TYPE 2 PATCHLET_OFFSET 0x2d131 N_ORIGINALBYTES 5 JUMPOVERBYTES 0 PIT ikeext!0xaafd8,ikeext!0x2d1c0,ikeext!0x2d14f ; 0xaafd8 -> IkeCopyIncomingData ; 0x2d1c0 -> first WfpMemFree block ; 0x2d14f -> jump to NtohHeader in same block as patch
code_start
mov r8d, 1Ch ; number of characters to copy; for memcpy in IkeCopyIncomingData lea rcx, [rbp-30h] ; new buffer; for memcpy in IkeCopyIncomingData mov rdx, r14 ; buffer to copy from; for memcpy in IkeCopyIncomingData call PIT_0xaafd8 ; call IkeCopyIncomingData mov rbx, rax ; save return from IkeCopyIncomingData test rax, rax ; check if return from IkeCopyIncomingData is non-zero jnz PIT_0x2d1c0 ; jump to WfpMemFree block if non-zero
lea rcx, [rbp-30h] ; buffer with copied data jmp PIT_0x2d14f ; jmp to NtohHeader in same block as patch
code_end patchlet_end
This video demonstrates the effect of our micropatch. With
0patch disabled, launching the POC against a vulnerable computer causes a svchost.exe process to crash due to memory access violation. With 0patch enabled, the vulnerability is no longer there, the malformed IKEv1 packet is blocked, and the service doesn't crash.
The micropatch was written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank Yuki Chen for finding this issue, and 78ResearchLab researchers for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
August 2022 Windows Updates brought a fix for a local privilege escalation in Windows Kerberos, discovered by Nick Landers (@monoxgas) of NetSPI. Nick and James Forshaw (@tiraniddo) presented this vulnerability at the BlackHat USA 2022 conference and subsequently published proof-of-concept scripts. This made it possible for us to create a patch for affected "security-adopted" Windows systems that no longer receive official fixes from Microsoft.
The vulnerability allows an attacker to bypass an integrity check for a security buffer of a PAC structure sent inside attacker's AP-REQ request. The flawed integrity check improperly inspects the security buffer type by comparing it to constant SECBUFFER_TOKEN while ignoring that its value can also include two bit flags in the upper byte. Nick's and James' proof-of-concept adds one such flag to the value, bypassing the integrity check, and can therefore arbitrarily modify the PAC structure - for instance, to claim the requestor is not the actual low-privileged user but a local administrator. According to Microsoft's advisory, "a domain user could use this vulnerability to elevate privileges to a domain admin."
Microsoft assigned this issue CVE-2022-35756
and fixed it by removing the execution branch that led to the bypass. Our micropatch is logically
equivalent to Microsoft's:
push eax ;save the original rax value mov eax, [ebp-0x14] ;get the flag location pointer +0x8 for the previous push bt dword[eax+0x28], 0x19 ;test the 0x19-th bit pop eax ;restore original rax value jb SKIP ;if bit is set, keep the old rcx value mov eax, 1 ;if bit is not set, mov 1 into rcx SKIP: ; the value of rax here will be stored to rcx and serve as an argument ; in a call to KerbCreateTokenFromTicketEx
code_end patchlet_end
The micropatch was written for the following Versions of Windows with all available Windows Updates installed:
Windows 10 v2004
Windows 10 v1909
Windows 10 v1903
Windows 10 v1809
Windows 10 v1803
Windows 7 without ESU, with year 1 of ESU and with year 2 of ESU
Windows Server 2008 R2 without ESU, with year 1 of ESU and with year 2 of ESU
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center. For a trial or demo please contact sales@0patch.com.
We'd like to thank Nick Landers (@monoxgas) and James Forshaw (@tiraniddo) for publishing their analysis with a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
August 2022 Windows Updates brought a fix for a memory corruption vulnerability in Microsoft Outlook, discovered by security researcher insu of 78ResearchLab. The vulnerability exploits a flaw in Outlook's processing of multiple Content-Type headers in a multipart/signed email, whereby a malicious email can lead to free'ing an unallocated memory address and crashing Outlook as such email is downloaded (even before one can view it). Once such email is in user's Inbox, Outlook crashes whenever the user clicks on it or it gets displayed in the Preview pane.
0patch has security-adopted Office 2010 in November 2020 when its support was officially terminated, but Microsoft kept providing security updates for it until April 2021. After that date, we analyzed every published vulnerability affecting still-supported versions of Office to see if Office 2010 was affected, and until now, have not confirmed any. This is the first case where we could reproduce a publicly detailed, potentially critical issue in an Office 2010 component.
Thankfully, the researcher published an analysis and a POC for this vulnerability. This made it possible for us to create a patch for Outlook 2010 that no longer receives official fixes from Microsoft.
Microsoft assigned this issue CVE-2022-35742
and fixed it by properly preserving the flag (bit) that denotes whether a Content-Type buffer needs to be free'd or not. Our micropatch is logically equivalent to Microsoft's:
mov r15, 0 ; default r15 for setz command call PIT_0x272ac ; rewrite original code for patch placement mov ebp, eax ; rewrite original code for patch placement test eax, eax ; rewrite original code for patch placement js PIT_0x27db9 ; rewrite original code for patch placement
mov eax, [rdi+100h] ; get flag from memory and al, 2 ; check flag state cmp al, 2 ; check flag state setz r15b ; set r15 accordingly to flag jmp PIT_0x27d7d ; jump to block where memory is copied
mov [rdi+12Ch], eax ; rewrite original code for patch placement mov rax, [rbx+0F8h] ; read value from memory test byte[rax+10h], 4 ; check if read memory+10h contains 4 jnz PIT_0x27db9 ; if memory+10h contains 4 then check flags ; else jump to function return block
test r15d, r15d ; check if flag is set jz AND_BLOCK ; if set jump to AND_BLOCK
or dword[rdi+100h], 2 ; if flag not set then set it jmp PIT_0x27db9 ; jump to function return block
AND_BLOCK: and dword[rdi+100h], 0FFFFFFFDh ; reset flag ; continue normal execution code_end patchlet_end
This video demonstrates the effect of our micropatch. With
0patch disabled, downloading the malicious email in Outlook 2010 crashes Outlook, and restarting Outlook leads to the same result, effectively disabling user's email; with 0patch enabled, the malicious email gets downloaded and while it can't be displayed due to malformed content, it sits there doing no harm.
The micropatch was written for 32-bit and 64-bit versions of Outlook 2010, fully updated with its latest free updates from April 2021.
This
micropatch has already been distributed to all
online 0patch Agents with a PRO
or Enterprise license. To obtain the micropatch and have it
applied on your
computers along with our other micropatches,
create an account in 0patch Central, install 0patch Agent and register it to your account with a PRO or Enterprise subscription. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.
To learn more about 0patch, please visit our Help Center.
We'd like to thank insu of 78ResearchLab for publishing their analysis and providing a
proof-of-concept that allowed us to reproduce the vulnerability and
create a micropatch. We also
encourage security researchers to privately share their analyses with us
for micropatching.
