🔒
There are new articles available, click to refresh the page.
Before yesterday0patch Blog

2021 New Year's Resolution: "We Will Spend Less Time and Money on Security Patches"

15 December 2020 at 09:21

 


It's been over a year since we had announced our "security adoption" of Windows 7 and Windows Server 2008 R2 after they would reach end of support in January 2020. Starting with February 2020, the first Patch Tuesday without free security updates, we began actively collecting details on high-risk vulnerabilities affecting these Windows versions and issuing micropatches for them.

Until now, we've issued micropatches for 24 such vulnerabilities in Windows 7 and Server 2008 R2, including some 0days (i.e., vulnerabilities for which there was no official patch from Microsoft yet, such as this one) and our most popular server micropatch for the Zerologon vulnerability. Additional micropatches will surely be issued by the end of our first 12 months of keeping Windows 7 and Server 2008 R2 secure.

Many organizations that kept Windows 7 and Server 2008 R2 in their networks after January 2020 have purchased Extended Security Updates ("ESU"), which Microsoft pledged to provide for three additional years - with their price doubling in the second year, and again in the third year. For Windows 7, ESU was priced somewhere between $25 and $50 per computer for the first year, and for Server 2008 R2 at about 75% of the on-premises license cost for the first year (ouch!).

With 0patch PRO license costing about $26 (€22.95+tax) per computer per year, ESU may have seemed the better option on Windows 7 computers for organizations that wrestled a good deal from Microsoft - after all, they would get to continue doing what they did before, updating these computers every Patch Tuesday and remaining compliant while avoiding a Windows upgrade.

On servers, where 0patch PRO license costs exactly the same as on workstations, the price list was decidedly in favor of 0patch, but it's understandable that everyone is extra careful about servers and what they install on them. Consequently, many prospects we talked to ended up "going with ESU for now and keeping our eyes on 0patch until the renewal is up in 2021."

Meanwhile, Windows 7 and Server 2008 R2 are hardly going extinct. According to NetMarketShare, 24% of web traffic originating from Windows computers still comes from Windows 7 machines (33% a year ago). And both the workstation and the server are an integral part of many an expensive and/or ubiquitous medical, financial and manufacturing device - which will do their jobs quite well for years to come if only they can be kept secure.


Save Time and Money on Patches in 2021

 

Any organization still using Windows 7 or Server 2008 R2 and wishing to keep them secured is welcome to try out 0patch and see how easy, painless and inexpensive security micropatching is for fixing the vulnerabilities that really matter.

Save time with 0patch by:

  • not keeping users idle while updates are installed or uninstalled
    (micropatches get applied in-memory while users are working),
  • not rebooting all computers at least once every month
    (micropatches don't even require a restart of patched processes, much less entire computers),
  • not worrying about what the huge monthly update will break
    (micropatches change just a couple of instructions, reducing the risk of breakage to absolute minimum),
  • closing attackers' window of opportunity quickly, even automatically
    (due to low risk of breakage, micropatches can be applied instantly - but don't worry, you can also un-apply them just as instantly if you think they're causing problems).

Save money with 0patch by:

  • mainly, by simply paying much less for 0patch than for alternative sources of security patches for Windows 7 and Server 2008 R2
    (remember, 0patch PRO costs €22.95+tax per computer per year, both for workstations and servers),
  • getting Enterprise features for free by ordering before January 14, 2021
    (Enterprise features like central management, groups, group-based patching policies etc. are a free add-on to 0patch PRO in the first 12 months of our "security adoption" period).

 

Finally, if your organization happens to still be using Office 2010 and is reluctant to replace it once it stops receiving official security updates, we have more good news: Office 2010 security micropatches are included in 0patch PRO.

 

Frequently Asked Questions

 

Q: We don't have Extended Security Updates. If we start using 0patch on our Windows 7 and Server 2008 R2 computers now, will we receive all micropatches that have been issued since these systems went out of support?

A: Absolutely, 0patch PRO licenses gives you access to all patches we've issued so far and all patches we'll issue during the subscription term. Just make sure to have these computers updated with January 2020 rollup updates (the last free updates).

Q: We've purchased Extended Security Updates for 2020 but are now considering switching to 0patch. Can we keep the installed ESU updates on our computers and take it from there?

A: Yes. You should apply all ESU updates you will receive until the end of your ESU subscription, as our micropatches will be ported to the exact executable versions on so-updated machines.

Q: We'd like to try out 0patch before making a decision. How do we do that?

A: Create an account in 0patch Central and let us know at [email protected] which email address you used so we can upgrade your account to Enterprise and issue you a couple of trial licenses to work with.

Q: Where can we learn more about your security micropatches for Windows 7 and Server 2008 R2?

A: Our Help Center articles provide a lot of additional information, but you can also send an email to [email protected] with any questions that remained unanswered.


Stay safe!

@mkolsek
@0patch








 

 

 

 



0day in Windows 7 and Server 2008 R2 Gets a Micropatch

25 November 2020 at 16:15

 

by Mitja Kolsek, the 0patch Team
 
[Update 1/22/2021: This vulnerability did not get patched by December 2020 or January 2021 Extended Security Updates, so we ported our micropatch to these updates.]
 
"Lol, who's even using Windows 7 anymore?"
"According to NetMarketShare, almost one in four Windows users."
 

On November 12, 2020, security researcher Clément Labro published a detailed analysis of a local privilege escalation vulnerability affecting Windows 7 and Windows Server 2008 R2 for which no official fix exists yet (at the time of this writing). Although these Windows platforms have reached end of support in January this year but Extended Security Updates (ESU) are still available for them until January 2023 - so even fully ESU-updated machines are currently affected by this issue.

As an alternative to ESU, we at 0patch have "security adopted" Windows 7 and Windows Server 2008 R2 and are providing critical security patches for these platforms. Consequently, vulnerabilities like this one get our attention - and, usually, micropatches.


The Vulnerability

Clément wrote a very useful permissions-checking tool for Windows that find various misconfigurations in Windows that could allow a local attacker to elevate their privileges. On a typical Windows 7 and Server 2008 R2 machine, the tool found that all local users have write permissions on two registry keys:

  • HKLM\SYSTEM\CurrentControlSet\Services\Dnscache
  • HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper

These didn't immediately seem exploitable, but Clément did the legwork and found the Windows Performance Monitoring mechanism can be made to read from these keys - and eventually load the DLL provided by the local attacker. To most everyone's surprise, not as the local user, but as Local System.

In short, a local non-admin user on the computer just creates a Performance subkey in one of the above keys, populates it with some values, and triggers performance monitoring, which leads to a Local System WmiPrvSE.exe process loading attacker's DLL and executing code from it.

 

The Micropatch 

Now this is clearly a case of incorrect permissions on the above registry keys, and the solution should be obvious - correcting these permissions. However, we don't want our micropatches to make any global changes to the system, so we decided to address this in the code.

We analyzed where the Performance registry key is being read in Windows libraries and found that to be in advapi32.dll, function OpenExtensibleObjects, as a result of a call to RegKeyOpen* function with one of the performance-related predefined keys, in our case HKEY_PERFORMANCE_DATA.

Function OpenExtensibleObjects iterates through all services in the registry looking for Performance keys, and we decided to patch it so that it would ignore this key in both affected services - making it look as if the Performance key wasn't there even if it was.

This obviously breaks performance monitoring for the affected services but that's a trade-off we believe is beneficial to our users. In case performance monitoring is needed for these services, the micropatch can always be temporarily disabled (again, no restart of the service, much less of the computer, is needed for that).


Source code of the micropatch

The video below shows how the attack works on a Windows 7 computer exploiting bad permissions on the Dnscache registry key. An identical attack could be mounted using the RpcEptMapper key.

 


This micropatch is immediately available to all 0patch users, including those with a FREE plan. It is targeted at:
 
  1. Windows 7 and Server 2008 R2 computers without ESU, updated to January 2020, and 
  2. Windows 7 and Server 2008 R2 computers with ESU, updated to November 2020, 
  3. [Updated 1/22/2021] Windows 7 and Server 2008 R2 computers with ESU, updated to December 2020 or January 2021
 
According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it (presumably only as part of Extended Security Updates). By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), create an account in 0patch Central, install 0patch Agent and register it to your account. 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  Clément Labro for sharing their analysis and POC, which allowed us to create this micropatch for Windows users. We also encourage security researchers to privately share their analyses with us for micropatching, and further increase the positive impact of their work.
 
Most of the analysis was done by our young micropatching expert Ziga Sumenjak.
 
And finally, just one "frequently" asked question:
 
Q: "Can't I simply manually tighten permissions on affected registry keys to remove the risk instead of using 0patch?"
 
A: "Yes you can (or you can use this batch script to create Performance keys with tightened permissions). We don't know, however, if that might break some functionality under some conditions. It's quite likely that Microsoft didn't set such permissions by accident."

 

 







0patch Keeps Office 2010 Secured After End-Of-Support

5 November 2020 at 14:40

by Mitja Kolsek, the 0patch Team


[Update Jan 13, 2020: Microsoft issued further updates for Office 2010 in January 2021. We have updated this article accordingly.]

[Update Dec 15, 2020: Microsoft issued further updates for Office 2010 in December. We have updated this article accordingly.]

[Update Nov 14, 2020: In contrast to announced end of updates for Office 2010 in October, Microsoft issued additional updates for Office 2010 in November. We have updated this article accordingly.]

Remember how we "security adopted" Windows 7 and Server 2008 R2 when they've reached end-of-support in January 2020? Since then, we've issued micropatches for 21 high-risk vulnerabilities in these systems, the most popular undoubtedly being our micropatch for Zerologon (CVE-2020-1472), a vulnerability affecting virtually all Windows domains and being currently widely exploited by ransomware gangs.

With Office 2010 having reached end-of-support last month, and many organizations expressing interest in keeping it (secure), we've decided to "security adopt" Office 2010 as well. This service is already generally available at the time of this writing.

How does this work? Similarly to what we do for Windows 7 and Windows Server 2008 R2, we collect vulnerability information for Office 2010 from a variety of sources: partners, security community, public sources, and also by testing if newly discovered vulnerabilities affecting still-supported Office versions might also affect Office 2010. When we come across a vulnerability that in our assessment presents a high risk and have sufficient data to reproduce it, we create a micropatch for it that works on fully updated Office 2010. Just as for Windows 7 and Server 2008 R2, Office 2010 has to be updated with latest available official updates, i.e., January 2021 updates.

Security micropatches for Office 2010 are included in 0patch PRO subscription currently priced at 22.95 EUR + tax/computer/year (volume discount available) that already provides access to all our micropatches. Enterprise features such as central management, groups, group-based patching policies, and notifications are available for organizations managing large numbers of Office 2010 installations they want to keep secured with minimal effort.

Organizations running at least 100 Office 2010 installations on supported Windows OS versions (therefore not needing all our PRO micropatches), have an option to subscribe to just Office 2010 security micropatches for a significantly discounted price.

So what do you have to do to protect your Office 2010 installations with 0patch? You need to make sure all Office 2010 updates are installed, create a 0patch account in 0patch Central, install 0patch Agent and register it to your account, then purchase a PRO subscription for a suitable number of licenses or ask [email protected] for a free trial.

We will initially provide security patches for Office 2010 for 12 months, and then extend this period if faced with sufficient demand.

 

Frequently Asked Questions

 

Q: What do I have to do to receive Office 2010 micropatches?

A: To receive our post-End-of-Support Office 2010 micropatches, you have to:

  1. Have your Office 2010 installation updated with all available updates up to including January 2021 (the latest official updates).
  2. Install 0patch Agent on each computer running Office 2010 you want to protect with 0patch, and register these agents with your 0patch account. (Use silent installation with auto-registration for larger deployments.)
  3. Have a suitable number of 0patch PRO or 0patch Enterprise licenses in your 0patch account.
  4. Allow your 0patch-protected computers to connect to 0patch server (host dist.0patch.com, port 443) for periodic syncing in order for them to receive new micropatches and in order for you to remotely manage them (included in the Enterprise license)


Q: Do you provide patches for all known vulnerabilities affecting Office 2010?

A: We collect vulnerability information for Office 2010 from a variety of sources: partners, security community, public sources, and also by testing if newly discovered vulnerabilities affecting still-supported Office versions might also affect Office 2010. When we come across a vulnerability that in our assessment presents a high risk and have sufficient data to reproduce it, create a micropatch for it that works on fully updated Office 2010.

Consequently, an Office 2010 vulnerability may become known but it may pose too low a risk to warrant micropatching. Also, we may not have sufficient data about the vulnerability to be able to reproduce it and therefore create a micropatch. Should this happen, we will certainly utilize our connections with researchers and partners to obtain such data.

As a reference, we've been providing security micropatches for Windows 7 and Windows Server 2008 R2 since January 2020 and issued micropatches for 21 high-risk vulnerabilities in the first 9 months of the service.

Q: How long do you plan to provide Office 2010 Micropatches?

A: Initially we plan to provide Office 2010 security patches for 12 months, i.e., until October 2021. Depending on the interest from our users, we may decide to extend our support term for another 12 months.

Q: Are Office 2010 security patches part of 0patch PRO and Enterprise, or a separate subscription?

A: Office 2010 security patches are part of 0patch PRO and 0patch Enterprise; there are currently no other plans available. (See also this article.)

Q: Are post-EOS Office 2010 micropatches also available to home/personal users?

A: Yes, our post-EOS (post-End-of-Support) Office 2010 patches are available to all users with 0patch PRO or 0patch Enterprise license. So whether you're a home user with just one or a couple of computers, a small business with dozens of computers, or a large organization with a Windows fleet of tens of thousands, you're getting these micropatches if you purchase a 0patch PRO license.

We may occasionally decide to provide some of these micropatches to 0patch FREE users as well, for instance to help slow down a global worm outbreak.

Q: Can I use Office 2010 micropatches on still-supported Windows versions such as Windows 10?

A: Of course. 0patch Agent works on all supported Windows versions, and if you have Office 2010 installed there (and fulfill all requirements), our micropatches will get applied to it. (See also this article.)

Q: I only need Office 2010 security patches but not all other patches included in 0patch PRO subscription. Are any discounts available?

A: We understand that some organizations may need security micropatches for Office 2010 installed on still-supported Windows versions such as Windows 10, and not need any other micropatches we're issuing. If your organization needs to protect at least 100 Office 2010 installations, we welcome you to contact [email protected] for information about available discounts.

Q: Should we deploy 0patch now or wait until a serious Office 2010 vulnerability appears?

A: It is likely that sooner or later, a critical vulnerability will be found affecting Office 2010 and requiring rapid response from users and organizations in absence of an official fix from Microsoft.

If you're a home user or a small business where deploying a new product is a simple and quick process, feel free to wait and deploy 0patch when needed. (Knowing that you'd be missing out on our micropatches for other applications and 0days.)

However, for any sizeable organization we recommend doing a pilot/trial as soon as possible to make sure you've properly tested 0patch and ironed out any technical issues before the critical micropatch is needed across your network. To set up a pilot or a trial please contact [email protected].


For any additional questions regarding this service, please consult Frequently Asked Questions About Office 2010 Micropatches or, failing to find your answers there, contact [email protected].

 

Cheers!

@mkolsek
@0patch



Micropatch for Zerologon, the "perfect" Windows vulnerability (CVE-2020-1472)

17 September 2020 at 17:01

 


 

by Mitja Kolsek, the 0patch Team
 
 
The Zerologon vulnerability allows an attacker with network access to a Windows Domain Controller to quickly and reliably take complete control of the Windows domain. As such, it is a perfect vulnerability for any attacker and a nightmare for defenders. It was discovered by Tom Tervoort, a security researcher at Secura and privately reported to Microsoft, which issued a patch for supported Windows versions as part of August 2020 updates and assigned it CVE-2020-1472.

Secura has subsequently released a detailed technical paper and a proof-of-concept tool that anyone could use to test whether their domain controllers were vulnerable or not. The paper revealed the underlying cryptographic flaw in Netlogon remote protocol, a legacy protocol that is still supported on all Windows servers to allow old Windows machines to work in a domain environment. The flaw is described in detail in the above-mentioned paper, but the jist of it is that the attacker has a 1:256 chance that if sending a "challenge" of all zeroes, and all subsequent values in the protocol also containing only zeroes, the request will reset server's password to an empty password. Making a sufficient number of attempts, say 2000 as in the proof-of-concept tool, will succeed with extremely high probability, which we can safely approximate to 100%.


Microsoft's Fix

While most of the security community is interested in the vulnerability and its exploitation, we at 0patch care more about the fix. Critical Windows vulnerabilities are most often of memory corruption flavor, and thus generally easy to fix, but when a cryptographic flaw comes by, there's a possibility that the fix will introduce a lot of new complex code. (Spoiler: not in this case.)

Since Netlogon remote protocol still holds together many production environments with old Windows computers, we knew that Microsoft's fix couldn't include any significant design changes unless it was also ported to long-unsupported Windows versions such as Server 2003, Server 2008 and Windows NT; breaking these systems on a global scale would, with only moderate dramatization, take us back to the dark ages.

Fortunately, Microsoft is highly disciplined when it comes to documentation: the Netlogon remote protocol page shows that the protocol specification was last changed in August 2020 - a good sign for us. Furthermore, they provide a handy "diff" document for every version so it's easy to find changes. The August 2020 diff document contains the following relevant changes:


  1. Page 102: A new setting VulnerableChannelAllowList was introduced: "A setting expressed in Security Descriptor Definition Language (SDDL) ([MS-DTYP] section 2.5.1) of Netlogon client allowed to not use secure bindings, see section 3.1.4.6. (VulnerableChannelAllowList is not supported in Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008.)"

  2. Page 104: A step was added to the session-key negotiation process: "If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps. (Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008 allow the call to succeed.)"

  3. Page 110: Two steps were added to the session-key establishment process: "4. If secure bind is not used, the server MUST deny the request unless client is in the VulnerableChannelAllowList setting. (Windows NT 4.0, Windows 2000, Windows Server 2003, and Windows Server 2008 allow the call to succeed.)" and "6. If none of the first 5 bytes of the ClientStoredCredential computation result (step 1, section 3.1.4.5) is unique, the server MUST fail session-key negotiation without further processing of the following steps. (Windows NT, Windows 2000, Windows Server 2003, and Windows Server 2008 allow the call to succeed. )"

 

The relevant change for Zerologon is obviously this: "If none of the first 5 bytes of the client challenge is unique, the server MUST fail session-key negotiation without further processing of the following steps." However, what exactly does "if none of the first 5 bytes of the client challenge is unique" mean? The reader is challenged to make a mental image of what this phrase means, as anyone implementing the protocol would have to - and then read on to see how that mental image compares to Microsoft's code.

Diffing of netlogon.dll between July 2020 and August 2020 versions on Windows Server 2012 shows that function NetrServerAuthenticate3 was extended with a call to a previously non-existent function NlIsChallengeCredentialPairVulnerable and a subsequent branch to terminate the protocol in case the latter returns a non-zero value (implying that the challenge-credential pair was vulnerable).

 

Function NetrServerAuthenticate3 got a new security check in August 2020

Now let's look at the new function, NlIsChallengeCredentialPairVulnerable. The client-provided challenge is stored in a buffer pointed to by rcx. First, some global variable is checked: if it is 1, the function returns 0 ("not vulnerable"). We don't know what this global variable is and we found no write references to it, only three places where it is being read. We suspect it might be an #ifdef'ed global variable that is hard-coded depending on the target Windows version so that even if Microsoft rebuilds netlogon.dll for, e.g., Windows Server 2003, this security check will not work - which would be consistent with the current Netlogon remote protocol specifications.

Then, rcx is checked to be non-null (kind of important, we don't want to cause access violation reading from it), and rdx is also checked to be non-null. We don't know what rdx points to and decided not to go there as rdx's value is not used at all (the register is overwritten with 1 shortly thereafter).

Now to the meat of the function: the first byte of the challenge is stored into r9d, then the next four bytes are compared to it in a loop. If any of these four bytes is different from the first byte, the function returns 0 ("not vulnerable"). Otherwise, it returns 1 ("vulnerable"). This covers the case from the proof-of-concept tool, where the challenge is all zeroes, but it also covers challenges starting with 11111, 22222, 33333, etc., which would also be deemed malicious by this logic. We assume Microsoft asked one of its crypto experts how to fix this and they at least thought it possible (if not outright feasible) that challenges consisting of equal non-zero bytes could also be used for an attack, perhaps a less trivial one. [Update 9/18/2020] If we were any good at reading, we would notice this part in Secura's report: "When an IV consists of only zeroes, there will be one integer 0 ≤ X ≤ 255 for which it holds that a plaintext that starts with n bytes with value X will have a ciphertext that starts with n bytes with value 0. X depends on the encryption key and is randomly distributed." This explains the logic of Microsoft's patch, and all-zero challenge is just the simplest challenge to exploit. 

 

NlIsChallengeCredentialPairVulnerable checks if the first five challenge bytes are equal.

And why check only the first 5 bytes? We assume it's either because (a) Microsoft calculated that even if a legitimate random challenge could occasionally begin with 5 equal bytes, this would only break approximately 1 in 4 billion requests, or (b) their challenge-generating code in the client makes sure that the first five bytes are not the same (which would only break 1 in 4 billion requests from non-supported Windows computers).

Now, how does this implementation match your mental image of  "if none of the first 5 bytes of the client challenge is unique"? We think something like "if all of the first 5 bytes of the client challenge are identical" would more accurately describe it, and hereby call on Microsoft to reword this sentence in a future version of the protocol.

 

Our Micropatch

The micropatch we wrote is logically identical to Microsoft's fix. We injected it in function NetrServerAuthenticate3 in roughly the same place where Microsoft added the call to NlIsChallengeCredentialPairVulnerable, but since the latter doesn't exist in old versions of netlogon.dll,  we had to implement its logic in our patch.


The source code of our Zerologon micropatch for Windows Server 2008 R2

 

The video below shows how 0patch blocks a "Zerologon" attack. The Zerologon test tool is launched against a fully patched Windows Server 2008 R2 without Extended Security Updates (i.e., patched up to January 2020) while 0patch Agent is disabled. As expected, the test tool discovers that the server is vulnerable. After enabling 0patch Agent, which applies an in-memory micropatch for CVE-2020-1472 to lsass.exe without having to reboot the system, the Zerologon test tool no longer succeeds.
 

 
 
 
 
This micropatch is immediately available to all 0patch users with a PRO license, and is primarily targeted at Windows Server 2008 R2 users without Extended Security Updates (updated with January 2020 updates!). By the time you're reading this it has already been distributed to all online 0patch Agents with a PRO license and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account, then purchase a PRO license or contact [email protected] for a free trial. 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 Tom Tervoort from Secura for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching and further increase the positive impact of their work.
 
Most of the analysis was done by our young micropatching experts Blaz Satler and Ziga Sumenjak.
 
 

Frequently Asked Questions

 
Q: Does applying this micropatch require a computer restart?
A: No, both installation of 0patch Agent and application of the patch (to process lsass.exe) are done without restarting the computer, or restarting any process on the computer.

Q: Do we need this micropatch on a server that is not a domain controller?
A: No. Only domain controllers are vulnerable, both according to Microsoft's advisory and our own testing.

Q: How do we know this micropatch actually works on our server?
A: The best way to test is to use a non-destructive test such as the proof-of-concept tool from Secura. You should be able to replicate what is shown in the video above.
 
Q: Is Windows Server 2008 (non-R2) or Windows Server 2003 (any flavor) or Small Business Server 2008 also affected by this vulnerability?
A: To the best of our knowledge, these servers are not vulnerable to Zerologon.
 
Q: Does your micropatch work on Small Business Server 2011?
A: We're not specifically testing with SBS2011, but users are telling us that our micropatch applies to this Server 2008 R2-based Windows version. 
 
Q: We have a Windows Server 2008 R2 but your micropatch doesn't seem to be getting applied as the vulnerability test still succeeds. What is wrong?
A: The most common cause for this problem is the server not fully updated with January 2020 updates.

Q: We have a still-supported Windows server but can't apply the official update for reasons which leaves us vulnerable to Zerologon. Can you help us?
A: Please contact [email protected] and we'll port the micropatch to your specific version
 
Q: Is there anything else we need to know?
A: If your organization still has Windows Server 2008 R2 machines, you might also have some Windows 7 systems that aren't getting security patches anymore, so you should know that we're providing critical post-end-of-support security micropatches for both Windows Server 2008 R2 and Windows 7. Here is the list of micropatches we've issued so far as part of this service.
 
 

 

 





 

 

 

 

 

Micropatch is Available for Windows Task Scheduler Security Feature Bypass (CVE-2020-1113)

11 August 2020 at 15:55





by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1113, a Windows Task Scheduler Security Feature Bypass.

This vulnerability was patched by Microsoft with May 2020 Updates, but Windows 7 and Server 2008 users without Extended Security Updates remained vulnerable.

Security researcher Sylvain Heiniger (@sploutchy) of @compasssecurity analyzed this vulnerability and subsequently published a POC, from which we could reproduce the issue and create a micropatch. 
 
The vulnerability lies in Task Scheduler accepting RPC requests that can be relayed. An attacker can piggyback on such requests by having some logged-on user send an SMB request to their computer, and then act as man-in-the-middle.
 
Microsoft's patch makes sure the authentication level of the RPC request received by Task Scheduler is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, which prevents such piggybacking. Our micropatch does effectively the same, with just six CPU instructions on 32-bit Windows, and two CPU instructions on 64-bit Windows:



MODULE_PATH "..\Affected_Modules\schedsvc.dll_6.1.7601.24470_64bit\schedsvc.dll"
PATCH_ID 459
PATCH_FORMAT_VER 2
VULN_ID 6220
PLATFORM win64

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2

PATCHLET_OFFSET 0x37a1
N_ORIGINALBYTES 5
JUMPOVERBYTES 0
PIT schedsvc.dll!0x3b449

code_start

    ;This patch is inserted right after the RpcServerInqCallAttributesW call.
    ;The call fills the RPC_CALL_ATTRIBUTES_V2_W structure with data, and at
    ; address rsp+78h we can find
    ;the RPC_CALL_ATTRIBUTES_V2_W.AuthenticationLevel value, which describes
    ;the level of RPC authentication
    ;used. The range of this variable is form 0x0 to 0x6, where 0x6 is
    ;authentication with integrity (signature)

    cmp dword[rsp+78h], 6     ;Check if the RPC_CALL_ATTRIBUTES_V2_W.AuthenticationLevel
                              ; value is equal to 6
    jb PIT_0x3b449            ;If the value is less than 6, jump to the
                              ;"access denied error" block

code_end
patchlet_end



And a video of the micropatch in action:




We'd like to thank Sylvain Heiniger (@sploutchy) for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. 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.

New 0patch Agent is Released - Version 20.06.18.10800

4 August 2020 at 12:57



Dear 0patch users,

We have just released a new 0patch Agent. We don't do that very often, for two reasons: (1) we like the software we're using to be stable, to favor reliability over novelty, and to not introduce unnecessary changes - so that's what we try to do for you; and (2) building and thoroughly testing a piece of software that needs to work reliably on multiple platforms is pretty expensive. Because of the latter, we've micropatched two functional bugs in our previous Agent version (see here and here) instead of hastily issuing a new one. Micropatching is vastly superior to the traditional rebuild-test-distribute model when fixing simple bugs (which most security bugs and many functional ones are) as it incurs minimal risk of breaking something outside the patched bits, requires only narrowly-focused testing, and allows for inexpensive and unobtrusive deployment (and revocation, if needed). 

Nevertheless, bugs and feature requests have piled up, and our server is evolving too, prompting the agent to learn a couple of new tricks.

What's new in the new 0patch Agent? If you like details, please refer to release notes, but otherwise the main changes are:

  • Annoying popups in 0patch FREE are now gone and replaced by a summary popup that will tell you how many patches you're missing out on that would be relevant on your computer.
  • Log is now displayed much faster in 0patch Console.
  • Pop-ups are no longer shown when any application is in full screen mode.
  • The above-mentioned functional bugs that we've previously micropatched have now been patched in the code, so there is no need to apply a micropatch to every process anymore.
  • Failed syncs immediately after system startup (which many of you have noticed, and thankfully reported) have been fixed.

May we remind you that the agent is still very small, just over 4MB on the file system.

We recommend you update your agent to this new version at your earliest convenience. The update process will not require a computer restart.


Locally Managed 0patchAgents

If you're using 0patch locally on your computer, 0patch Agent has already started notifying you about a new version. To update the agent, launch 0patch Console and in the "AGENT VERSION" box, click on "GET LATEST VERSION" and let the update process complete. Note that the console will disappear in the process, and will get re-launched when the new agent version is installed.


Remotely Managed 0patch Agents

If you're managing 0patch Agents in your organization remotely through 0patch Central, your group settings will determine whether/which agents will get updated automatically and which will require a manual action on your part. To make sure all agents are updated, you can open the All Computers group, select all computers, and under ACTIONS, select "Update agent to new version."


Thank you for using 0patch! As always, we'll appreciate your feedback, bug reports, feature requests and musical recommendations at [email protected].

The 0patch Team



Micropatch Available for "SIGRed", the Wormable Remote Code Execution in Windows DNS Server (CVE-2020-1350)

17 July 2020 at 22:29



by Mitja Kolsek, the 0patch Team


This month's Patch Tuesday included a fix for CVE-2020-1350, a critical memory corruption vulnerability in Windows DNS Server affecting all Windows Server versions from long-unsupported Server 2003 to the latest Server 2019.

After Microsoft's initial announcement and security advisory, the CheckPoint research team published a detailed article about the issue, describing the attack vector and providing enough information for other security researchers to trigger the vulnerability. Just one day later, the first real proof-of-concept was published, developed by Max Van Amerongen (@maxpl0it) from F-Secure Labs, and later several other researchers have shown their own tools triggering the vulnerability.

We can safely assume that offensive teams worldwide are currently trying to develop a reliable arbitrary code execution exploit as they know that Windows Updates take anywhere from long to eternity before getting applied to most Windows Servers out there. Their job will not be trivial, with various exploit mitigations in place on modern Windows servers, but counting on them to fail would be a risky strategy. In addition, many companies are still using Windows Server 2008 machines with no security updates past January this year.

Numerous 0patch customers have one or more Windows 2008 Servers and we wanted to take care of them as quickly as possible. With a working proof-of-concept at hand we could easily create a micropatch for this issue. Let's look at Microsoft's patch first:

 


The image above shows the difference between vulnerable function SigWireRead (left) and its patched counterpart (right). This function was one of only three functions in dns.exe modified by the July update, and the other two were not relevant for the issue at hand.

Microsoft's patch (gray code blocks) introduced three integer overflow/underflow checks, for one subtraction and two addition operations. When faced with Max's proof-of-concept, it is the third check (the lowest gray code block) that detects the overflow and redirects execution towards function's exit instead of processing the DNS packet further - which would lead to memory corruption. 

Our micropatch does logically the same, with one difference - when integer overflow/underflow is detected, it also displays and logs an exploit attempt, allowing admins to know that their server was targeted by an exploit:



MODULE_PATH "..\Affected_Modules\dns.exe_6.1.7601.24437_64bit\dns.exe"
PATCH_ID 456
PATCH_FORMAT_VER 2
VULN_ID 6390
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x4EC89
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT dns.exe!0x4EC68
   
    code_start
        push rdi ; push to ensure normal code flow after patch
        push rax ; push to ensure normal code flow after patch
       
        ;First check
        sub rdi, rax
        cmp rdi, 0xFFFF
        ja ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
       
        ;Second check
        movzx eax, byte[rsp+30h+2*8] ; added 2*8 to the original offset to compensate for the 2 pushes at the beginning
        add ax, 0x14
        cmp ax, 0x12
        jb ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
       
        ;Third check
        lea ecx, [rax+rdi]
        cmp cx, ax
        jb ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
        jmp End ; the TCP packet is valid, continue with original code
    ExploitBlocked:
        pop rax ; restore rax to its previous value
        pop rdi ; restore rdi to its previous value
        call PIT_ExploitBlocked ; Exploit Blocked pop up
        jmp PIT_0x4EC68 ; Exit function, TCP packet not valid
    End:
        pop rax ; restore rax to its previous value
        pop rdi ; restore rdi to its previous value
    code_end
   
patchlet_end




We released our micropatch early afternoon CET today and it got applied to all online computers with 0patch PRO worldwide within 60 minutes without restarting the computer or DNS service.


This is how it looks like when a DNS server is attacked without and with 0patch:





The first instance of our micropatch is targeted at Windows Server 2008 R2 without Extended Security Updates, and we plan to port it to Windows Server 2003 next for our users who are for various reasons still using this unsupported server. [Update 7/20/2020: Micropatch is now ported to 32-bit and 64-bit Windows Server 2003.]

Although free official updates exist for all supported Windows servers, admins may not be able to apply them immediately or restart the computer; for such cases, requests for porting our micropatch to specific versions of dns.exe running on affected computers can be sent to [email protected].

If you have 0patch Agent with PRO license installed on your Windows Server 2008 R2 or Server 2003 computer, our micropatch is already downloaded and applied to your DNS server. Otherwise, to obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, purchase a PRO license or request a trial at [email protected], install 0patch Agent and register it to your account.

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 Max Van Amerongen (@maxpl0it) from F-Secure Labs for publishing their analysis and POC, and for providing additional assistance in triggering the vulnerability and simplifying our test case, thereby allowing us to create this micropatch for Windows users without official security updates.

Micropatch is Available for Memory Corruption in DHCP Message Processing (CVE-2020-0662)

16 July 2020 at 13:45



by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-0662, a remote memory corruption vulnerability in DHCP message processing.

This vulnerability was patched by Microsoft with February 2020 Updates, but Windows 7 and Server 2008 users without Extended Security Updates remained vulnerable.

Security researcher Spencer McIntyre (@zeroSteiner) analyzed this vulnerability and published a POC, from which we could reproduce the issue and create a micropatch.

The vulnerability lies in accepting a hardware address in a DHCP packet that is longer than 20h bytes, resulting in out-of-bounds read or write, depending on the Windows version. Our micropatch is logically identical to Microsoft's: it adds a check for the HW address length:



MODULE_PATH "..\Affected_Modules\ipnathlp.dll"
PATCH_ID 454
PATCH_FORMAT_VER 2
VULN_ID 5909
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x1AB45
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT ipnathlp.dll!0x1AB94   
   
    ; Added check for Hardware address length, must be <= 20
   
    code_start
        mov al, [rsi+0xE6] ; [rsi+0xE6] = value of hardware address length
        cmp al, 0x20 ; compare hardware address length with 0x20
        jbe RestoreCodeFlow ; jump if hradware address length is <= 20
        call PIT_ExploitBlocked ; exploit blocked shown if hardware address length is > 20
        call GetText ; get address for Error text
        db 'DhcpProcessMessage: ignoring message since HWAdderLength is greater than MAX_HARDWARE_ADDRESS_LENGTH',0 ; Error message
    GetText:
        pop rdx ; set rdx to error code address like MS org patch
        jmp PIT_0x1AB94 ; jump to ensure same code flow like MS patch
    RestoreCodeFlow:
    code_end
   
patchlet_end



We'd like to thank Spencer McIntyre (@zeroSteiner) for sharing their analysis and POC, and for additional assistance in reproducing the bug, which allowed us to create this micropatch for Windows users without official security updates.

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. 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.

Remote Code Execution Vulnerability in Zoom Client for Windows (0day)

9 July 2020 at 15:03
by Mitja Kolsek, the 0patch Team





[Update 7/13/2020: Zoom only took one (!) day to issue a new version of Client for Windows that fixes this vulnerability, which is remarkable. We have reviewed their fix and can confirm that it efficiently resolves the vulnerability. With an official vendor fix available to all users, we made our micropatches for this issue PRO-only according to our guidelines. Meanwhile, after issuing micropatches for this issue targeted at Zoom Client for Windows versions 5.0.3 to 5.1.2, we noticed a lot of our users being on all of these versions despite Zoom's highly persistent update mechanism. We had expected most users to be on version 5.1.2., but this indicates many users may still be on even older Zoom Client versions. We therefore ported our micropatch to the remaining supported versions of Zoom Client: 5.0.0., 5.0.1, and 5.0.2. We're now covering all vulnerable supported clients.]

Earlier this week a security researcher shared a remote code execution "0day" vulnerability in Zoom Client for Windows with our team. The vulnerability allows a remote attacker to execute arbitrary code on victim's computer where Zoom Client for Windows (any currently supported version) is installed by getting the user to perform some typical action such as opening a document file. No security warning is shown to the user in the course of attack.

The researcher (who wants to keep their identity private) stated that they did not report the vulnerability to Zoom either directly or through a broker, but would not object to us reporting it to Zoom.

Analysis


We analyzed the issue and determined it to be only exploitable on Windows 7 and older Windows systems. While Microsoft's official support for Windows 7 has ended this January, there are still millions of home and corporate users out there prolonging its life with Microsoft's Extended Security Updates or with 0patch.

We then documented the issue along with several attack scenarios, and reported it to Zoom earlier today along with a working proof of concept and recommendations for fixing. Should a bug bounty be awarded by Zoom, it shall be waived in favor of a charity of researcher's choice.

Micropatch


On the micropatching side, we were able to quickly create a micropatch that removes the vulnerability in four different places in the code. The micropatch was then ported from the latest version of Zoom Client for Windows (5.1.2) to previous five versions back to 5.0.3 released on May 17, 2020. Zoom Client features a fairly persistent auto-update functionality that is likely to keep home users updated unless they really don't want to be. However, enterprise admins often like to keep control of updates and may stay a couple of versions behind, especially if no security bugs were fixed in the latest versions (which is currently the case).

Our micropatches have already been released and distributed to all online 0patch Agents; Zoom users with 0patch installed are therefore no longer affected by this issue.

According to our guidelines, we're providing these micropatches to everyone for free until Zoom has fixed the issue or made a decision not to fix it. To minimize the risk of exploitation on systems without 0patch, we're not publishing details on this vulnerability until Zoom has fixed the issue, or made a decision not to fix it, or until such details have become public knowledge in any way.

To obtain the free micropatch for this issue and have it applied on your computer(s), create a free account in 0patch Central, install 0patch Agent and register it to your account. 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.

Exploit without and with the micropatch


This video demonstrates how an actual attack could look like, and how 0patch blocks the attack. When 0patch is disabled (or absent), user's clicking on the "Start Video" button triggers the vulnerability and leads to a "HACKED" dialog being shown (of course anything else could be executed instead). With 0patch enabled, the vulnerability is removed from the running Zoom.exe process and clicking on the "Start Video" button does not result in execution of malicious code.

Note that in order to prevent revealing too much information, some prior user activity inside Zoom Client user interface is not shown in the video.




Frequently Asked Questions


Q: Am I affected by this vulnerability if I'm using Windows 10 or Windows 8?
A: No, this vulnerability is only exploitable on Windows 7 and earlier Windows versions. It is likely also exploitable on Windows Server 2008 R2 and earlier though we didn't test that; either way, our micropatch will protect you wherever you're using Zoom Client.

Q: Am I affected by this vulnerability if I'm using Windows 7 fully updated with Extended Security Updates?
A: Yes.

Q: Are other Zoom products affected by this vulnerability too?
A:We did not test any other Zoom products, however only those running on Windows could potentially be affected by this vulnerability.

Q: Is your micropatch for this vulnerability completely free?
A: Yes. If you already have 0patch Agent installed and registered, everything will happen automatically. If not, you only need to create a free account in 0patch Central, install 0patch Agent and register it to your account, then all FREE micropatches will be automatically downloaded to your computer and applied as needed. Once Zoom has fixed this issue, this micropatch will no longer be free and will only be available to 0patch PRO license holders.

Q: If I use 0patch to fix this vulnerability, what will happen when Zoom issues an updated version of Zoom Client for Windows?
A: 0patch is designed such that when a vulnerable executable module is replaced by a new version, any micropatches that were made for that vulnerable module automatically stop applying (because the cryptographic hash of the module changes). When Zoom issues an updated Client for Windows and you install it on your computer, our micropatch will become obsolete. In case this updated Zoom Client does not fix this vulnerability, we'll port the micropatch and make it available for free as quickly as possible.

Q: How do I know that the micropatch was actually applied to my Zoom Client?
A: First launch Zoom, then open 0patch Console and view the log. You should be able to find log entries like "Patch ... applied in application Zoom.exe"

Q: I installed 0patch Agent to fix this vulnerability but it is showing a large amount of popups notifying me about missing patches regardless of popup settings in 0patch Console. What can I do to make this stop?
A: We're aware that popups in the FREE plan have become pretty disturbing due to the increased amount of patches, and are fixing that in the next agent version scheduled to be out next week. If you can't wait, feel free to download the current 0patch Agent release candidate and install it on top of your already installed 0patch Agent. When this release candidate is installed, 0patch Console will show that a “New agent is available”. Please ignore that – the server simply tells the agent that the version it is running is not the current official version. The message will stop appearing when the new agent is officially released.

[Below FAQ added on 7/13/2020]

Q: Why did you drop a 0day without giving the vendor the usual 90 days to fix the issue?
A: We have to be perfectly clear here: we did not "drop a 0day". We took extra care not to reveal any technical details. "Dropping a 0day" implies publishing details that allow anyone skilled to reproduce the bug and create an exploit. In over two decades of existence, our company has never "dropped a 0day", moreover we have never published details of unpatched vulnerabilities we had reported to various vendors even if they took extremely long to fix them (while it is standard practice to publish after 90 days). We took the time to write up a detailed report we sent to Zoom, and we took care of our users by providing them with a micropatch. This is what every antivirus/antimalware company does for their users, e.g., by immediately providing signatures for 0days.

Q: Now that Zoom has issued a new version of Client for Windows that fixes this issue, will you publish vulnerability details and proof-of-concept?
A: Our data shows that on the day we issued our micropatches, many 0patch users have been using all supported versions of Zoom Client for Windows instead of the latest one despite of its highly persistent auto-update mechanism. Taking our user base as a statistical sample of the global Zoom user base, this implies a significant amount of Zoom Clients will likely remain vulnerable even though a fixed version is now available. To prevent putting Zoom users who don't also use 0patch at risk, we will not publish any additional details at this time.

Q: Does this vulnerability show that Windows 7 is an insecure operating system?
A: While it may sound so, it really does not. This vulnerability is not a fault of Windows 7 in any way, but just happens to be exploitable there. It is not blocked by some security feature or exploit mitigation on Windows 8 and Windows 10 which isn't there on Windows 7, but by sheer coincidence.

Q: Isn't Windows 7 insecure anyway because Microsoft stopped supporting it?
A: Not really - Microsoft is still providing all critical and important security updates for Windows 7 until January 2023; from security perspective, Windows 7 is therefore effectively just as supported as Windows 10 as long as you're using Microsoft's Extended Security Updates, or, alternatively and less expensively, 0patch.

Community Outreach


We'd like to thank the security researcher who shared the vulnerability with us so we could provide quick protection for our existing users and everyone else affected. We're very pleased to see an increase of such collaboration within security community and call upon all security researchers to help us protect users and share vulnerability information with us, whether or not they have also shared it with the original vendor. We'll do our best to turn your reports into patches as quickly as possible. Thank you all!




Micropatch is Available for Windows LNK Remote Code Execution Vulnerability (CVE-2020-1299)

26 June 2020 at 12:18



by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1299, another "Stuxnet-like" critical LNK remote code execution issue that can get code executed on user's computer just by viewing a folder with Windows Explorer.

This vulnerability was patched by Microsoft with June 2020 Updates, but Windows 7 and Server 2008 users without Extended Security Updates remained vulnerable.

Security researcher Lê Hữu Quang Linh (@linhlhq) found this vulnerability, published a detailed analysis and shared a POC with us so we could reproduce the issue and create a micropatch.

We narrowed the root cause down to the order in which method CKnownFoldersFolder::_ClearCachedObjects (1) deletes a DSA object using a call to DSA_DestroyCallback and (2) NULLs a pointer to said object. In vulnerable code, it does it in this order; in patched code, vice versa, as seen on the image below.


Unpatched (left) and patched (right) function CKnownFoldersFolder::_ClearCachedObjects


Microsoft's patch also moved a CoTaskMemFree call to another code block but we determined that to have no relevant consequence. Therefore, our micropatch only needed one single instruction to NULL the pointer to the DSA object before the call to DSA_DestroyCallback.



MODULE_PATH "..\Affected_Modules\shell32.dll_6.1.7601.24468_64bit\shell32.dll"
PATCH_ID 443
PATCH_FORMAT_VER 2
VULN_ID 6281
PLATFORM win64

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2

PATCHLET_OFFSET 0x76C8C
N_ORIGINALBYTES 5
JUMPOVERBYTES 0

code_start

    and qword[rbx+0xb8], 0 ; put 0 at rbx+0xb8, which contains a circular pointer to the same
                          
; structure and is going to be deleted twice.
                           ; When the function tries to recursively delete this structure, it follows
                           ; this pointer and causes a double free
code_end
patchlet_end




Here's a video of our micropatch in action:






We'd like to thank security researcher Lê Hữu Quang Linh (@linhlhq) for a detailed analysis and for sharing their POC with us, which allowed us to quickly reproduce the issue and produce this micropatch for Windows users without official security updates..

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. 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.

Micropatch is Available for MS Windows OLE Remote Code Execution Vulnerability (CVE-2020-1281)

16 June 2020 at 15:43

by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1281, an integer overflow vulnerability in Windows OLE marshaling that could allow a remote attacker to execute arbitrary code on user's computer.

This vulnerability was patched by Microsoft with June 2020 Updates, but Windows 7 and Server 2008 R2 users without Extended Security Updates remained vulnerable.

Security researcher Yuki Chen found the vulnerability, wrote an in-depth analysis, analyzed Microsoft's patch and provided a POC for triggering the vulnerability.

The vulnerability is in the way new object size is being calculated when an object is enlarged (e.g., in string concatenation). This new size is then used for allocating memory for the resulting "enlarged" object.

The vulnerable code doesn't account for really large numbers where adding would exceed the capacity of 32-bit numbers. In such cases, an integer overflow occurs, a too-small memory block is allocated, and subsequent copying to this new block overwrites memory outside of it.

Microsoft's patch modified several functions related to calculating the object size. We decided to only patch the one that is proven to be exploitable at this point (BSTR_UserSize). Upon detecting an overflow, our patch reports "Exploit Blocked" and terminates the process:



MODULE_PATH "..\Affected_Modules\oleaut32.dll_6.1.7601.24537_64bit\oleaut32.dll"
PATCH_ID 441
PATCH_FORMAT_VER 2
VULN_ID 6279
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x5fcf
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT oleaut32.dll!0x10edc,Kernel32.dll!TerminateProcess,Kernel32.dll!GetCurrentProcess
    
    ; This patchlet is located in BSTR_UserSize and replaces the main branch of code right up to the retn
    ; On entry we have:
    ; - rax points to the content of the BSTR object (the first character of the string)
    ; - rdx is the size to be added to the string
    ; - ecx is rdx+3 (just computed using "lea ecx, [rdx+3])
    ; The patch performs the same operations the original code does, but for each of them,
    ; it checks for a numeric overflow and if so, pops ExploitBlocked and triggers an exception like the official patch
        
    code_start
    
        and ecx, 0xFFFFFFFC ; we pushed this instruction out, so replacing it here
        cmp ecx, edx        ; check if adding 3 and aligning resulted in an overflow
        jb OVERFLOW         ; overflow detected
        
        test eax, eax       ; same as in original code
        jz BSTR_IS_NULL
        mov eax, dword [rax-4] ; same as in original code
        jmp END1
    BSTR_IS_NULL:
        xor eax, eax ; same as in original code
    END1:
    
        add eax, 1 ; original code has "inc eax", but that doesn't set the carry flag
        jc OVERFLOW ; overflow would set the carry flag
        and eax, 0xFFFFFFFE
        
        add eax, ecx
        jc OVERFLOW ; overflow would set the carry flag
        
        add eax, 0x0C
        jc OVERFLOW ; overflow would set the carry flag
        
        retn ; return from the function
        
    OVERFLOW:
        call PIT_ExploitBlocked
        call PIT_GetCurrentProcess
        mov rcx, rax
        mov rdx, 0x1337
        call PIT_TerminateProcess
    
    code_end
    
patchlet_end



Here's a video of our micropatch in action:






We'd like to thank Yuki Chen for an excellent analysis and POC for this issue, which allowed us to create a micropatch for Windows users without security updates.

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account at 0patch Central, install 0patch Agent and register it to your account. 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.

Micropatch Available for User-Mode Power Service Memory Corruption (CVE-2020-1015)

27 May 2020 at 09:26



by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1015, a memory corruption vulnerability in User-Mode Power Service that could allow a local attacker to execute arbitrary code as Local System.

This vulnerability was patched by Microsoft with April 2020 Updates, but Windows 7 and Server 2008 R2 users without Extended Security Updates remained vulnerable.

Security researcher 0xeb_bp analyzed the official patch, wrote an in-depth analysis, determined the root cause of the vulnerability, and published a tool that crashes the Power Service.
The vulnerability provides a "race condition" in requests for a legacy RPC function because the code processing these requests was not properly enclosed in critical sections. Multiple concurrent requests can corrupt memory and result in arbitrary code execution in the service.
Microsoft's patch effectively enclosed most of the legacy RPC function (UmpoRpcLegacyEventRegisterNotication) into a critical section. Our micropatch does logically the same with two patchlets, 5 instructions in each.


MODULE_PATH "..\Affected_Modules\umpo.dll_6.1.7601.24525_64bit\umpo.dll"
PATCH_ID 438
PATCH_FORMAT_VER 2
VULN_ID 6152
PLATFORM win64

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x1a7c
N_ORIGINALBYTES 5
PIT kernel32.dll!EnterCriticalSection,kernel32.dll!GetModuleHandleA
; The critical section object is stored at umpo.dll+0x25aa0

code_start

    call STRING1
    db 'umpo.dll',0
STRING1:
    pop rcx ; rcx points to 'umpo.dll' string
    call PIT_GetModuleHandleA
    lea rcx, [rax + 0x25aa0]
    call PIT_EnterCriticalSection
  
code_end
patchlet_end

patchlet_start
PATCHLET_ID 2
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x1b33
N_ORIGINALBYTES 5
PIT kernel32.dll!LeaveCriticalSection,kernel32.dll!GetModuleHandleA
; The critical section object is stored at umpo.dll+0x25aa0

code_start

    call STRING2
    db 'umpo.dll',0
STRING2:
    pop rcx ; rcx points to 'umpo.dll' string
    call PIT_GetModuleHandleA
    lea rcx, [rax + 0x25aa0]
    call PIT_LeaveCriticalSection
  
code_end
patchlet_end


We'd like to thank @0xeb_bp for an excellent analysis and POC for this issue, which allowed us to create a micropatch for Windows users without security updates.

This micropatch is immediately available to all 0patch users with a PRO license. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account at 0patch Central, install 0patch Agent and register it to your account. 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.
  
 









Micropatching PrintDemon Vulnerability (CVE-2020-1048)

20 May 2020 at 15:19

by Mitja Kolsek, the 0patch Team


Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-1048, a privilege elevation vulnerability allowing a local non-admin attacker to create an arbitrary file in an arbitrary location.

This vulnerability was patched by Microsoft with May 2020 Updates, but Windows 7 and Server 2008 R2 users without Extended Security Updates remained vulnerable.

Last week, security researchers Yarden Shafir and Alex Ionescu published a detailed analysis of the vulnerability they dubbed "PrintDemon", including a proof-of-concept for Windows 8 and later Windows versions.

PrintDemon allows a low-privileged user to create a printer port pointing to a file, and then print to that port. If the user has insufficient permissions for writing to said file, Print Spooler service will do that as Local System upon computer restart.

Microsoft's patch added a couple of checks in the code for creating a printer port:
  1. custom port (one without '/' or '\') is allowed,
  2. named pipe port and file port is allowed if user has read/write permissions on it. 

Our micropatch does logically the same:



Here's a video of our micropatch in action:






Thanks to Yarden Shafir and Alex Ionescu for an excellent writeup and POC for this issue, which allowed us to create a micropatch for Windows users without security updates.

Micropatching Unknown 0days in Windows Type 1 Font Parsing

26 March 2020 at 22:58
We can't fix what we don't know, but we can block exploitation in a highly convenient way

by Mitja Kolsek, the 0patch Team







Three days ago, Microsoft published a security advisory alerting about two vulnerabilities in Windows font parsing, which were noticed as being exploited in "limited targeted Windows 7 based attacks." These vulnerabilities currently don't have an official vendor fix.

As we've done before in a similar situation, we decided to provide our users with a micropatch to protect themselves against these vulnerabilities in a "0patch fashion", i.e., completely automatically and without disturbing users even in the slightest.

Our micropatch is currently available for fully updated Windows 7 64-bit and Windows Server 2008 R2 without Extended Security Updates (ESU), which means with January 2020 Windows Updates installed. This provides protection for our users who continue using these Windows versions but were unable or unwilling to obtain ESU, and are now, somewhat ironically, the only Windows users with a patch for these vulnerabilities.

Of course our next step will be to port the micropatch to other affected Windows versions including Windows 7 and Windows Server 2008 R2 with ESU, Windows 8.1 and Windows Server 2012, both 32-bit and 64-bit. We will likely not port the micropatch to Windows 10 and newer Servers as the risk from these vulnerabilities is much lower there.

[Update 4/3/3020: We ported this micropatch to Windows 7 and Windows Server 2008 R2 with Extended Security Updates applied.]


What Does Microsoft's Advisory Tell Us?



Microsoft's advisory provides scarce details, for obvious reasons, but here's what we think is important:

  1. Both vulnerabilities are in font parsing, which provides powerful attack vectors such as just viewing font files in Windows Explorer, or opening a malicious document. We initially thought that Internet Explorer could be an attack vector too while visiting a malicious web site that would provide its own malformed font to the browser. However, we were unable to find any confirmation that Adobe Type 1 PostScript fonts could be provided by a web site at all, and therefore consider Internet Explorer unlikely to be an attack vector. Other major browsers like Firefox or Chrome are certainly not attack vectors for these vulnerabilities. In addition, Microsoft's advisory states that Outlook preview is not an attack vector.
     
  2.  On Windows systems before Windows 10 v1709 and their server counterparts, font parsing is performed in the kernel, which provides immediate code execution with highest privileges, potentially even from a sandboxed document-viewing application. On Windows 10 v1709 and later, and their server counterparts, font parsing was moved to a sandboxed user-space process fontdrvhost.exe. On these systems, a remote code execution issue in font parsing will get attacker's code executed in an AppContainer sandbox, which requires another vulnerability to escape it.
     
  3. Vulnerabilities are in ATMFD.DLL, a kernel font driver responsible for processing Adobe Type 1 PostScript and OpenType fonts. Based on this comparison by Didier Stevens, fontdrvhost.exe likely has the same code for processing Adobe Type 1 PostScript and OpenType fonts as ATMFD.DLL, which explains why newer Windows 10 systems that do not have ATMFD.DLL at all, are also affected. (Note that Microsoft subsequently updated the severity of Windows 10 client and server products from Critical to Important, with which we agree.)
     
  4. Microsoft's advisory provides three mitigation approaches that, in varying degrees, prevent exploitation of these vulnerabilities. We list them here in some detail and provide pros and cons for each.

Microsoft's Recommended Mitigations


  1. Disable the Preview Pane, the Details Pane and thumbnails in Windows Explorer. When displaying a folder with any font files, Windows Explorer automatically parses all displayed font files to be able to show sample font characters in font files' thumbnails. In addition, if any font file is selected, a small thumbnail shown in the Details Pane and sample text shown in the Preview Pane also employ automatic parsing of font file's content (see image below). This is probably the most worrying attack vector, as all the attacker has to do is get the victim to view a folder with malicious font files. This can be a shared folder in victim's network, a USB drive, or a ZIP file delivered via any channel and extracted to local computer be the victim. Or it could be a shared folder on the Internet, but more on that in the next bullet.
     

    Pros: Simple to implement for individual users on their own computers; Relatively simple to deploy network-wide via GPO or any other central deployment via registry changes; No reboot needed.

    Cons:
    Other attack vectors remain open, such as malicious documents, or opening a malicious font file in Font Viewer; Users who are used to seeing thumbnails, preview, and/or file details in Windows Explorer may suffer productivity impact; In a network deployment, it's hard to prevent users from re-enabling these Explorer features and re-opening the attack vector.

     
  2. Disable the WebClient service. The WebClient service is installed and running by default on all Windows workstations (but not servers), and works like this: when you try to open a network share anywhere in or outside your network (e.g., on the Internet), and it can't be accessed via SMB protocol, WebClient attempts to access the shared folder using WebDAV, an HTTP-based protocol - and therefore goes through all corporate and home firewalls that allow web browsing from users' computers. This provides a powerful attack vector for these vulnerabilities as all the attacker would have to do is get the victim to click a link to a network share hosted on attacker's computer somewhere on the Internet, and Windows Explorer would (after some delay) display font files in it. The link could be hosted on attacker's web site, or sent to the victim via email. (Note that only Internet Explorer and Edge would actually open the link from a web page in Windows Explorer.) If you don't need this feature, Microsoft recommends disabling the WebClient service.

    Pros:
    Simple to implement for individual users on their own computers; Relatively simple to deploy network-wide via GPO or other central deployment via registry changes; No reboot needed.

    Cons:
    Other attack vectors remain open, such as malicious documents, or opening a malicious font file in Font Viewer.

     
  3. Rename ATMFD.DLL. This is the most effective mitigation, because it eliminates the vulnerable code. On older Windows systems, this code is in the kernel driver called ATMFD.DLL, while on newer ones it's in a sandboxed user-space process called fontdrvhost.exe. It makes sense that Microsoft recommended renaming the former but not the latter, as remote code execution vulnerabilities in the kernel are critical, while running malicious code inside an AppContainer is far from "game over". Note that on Windows 8.1 and earlier, it is also possible to disable ATMFD via registry as described in the advisory, with the same end result as renaming ATMFD.DLL.

    Pros: Reliably blocks all remote and local attacks using these vulnerabilities.

    Cons: A non-trivial procedure for individual users; Prevents
    Adobe Type 1 PostScript fonts and OpenType fonts from working in applications employing the Windows-integrated support for Adobe Type 1 PostScript and OpenType; Requires a reboot.



Windows Explorer on Windows 7 showing a font file's glyphs in the thumbnail and in both Preview and Details Panes. All three require sending the font to the kernel and having it rendered there.










 
Obviously we can't patch these vulnerabilities because we don't know what they are, but we can infer from Microsoft's advisory that blocking Adobe Type 1 PostScript fonts from reaching the vulnerable kernel parsing code would block attacks.

So we decided to find the common execution point that various Windows applications such as Windows Explorer, Font Viewer, and applications using Windows-integrated font support are using to pass a font to Windows, then place a bouncer there that would keep Adobe Type 1 PostScript fonts out.

Windows are offering font-related functions under the Windows graphics device interface (GDI), most notably the AddFontResourceA function and its extended and wide character siblings. Looking into their implementations, we found they all end up calling an undocumented GdiAddFontResourceW function, which in turn calls NtGdiAddFontResourceW. The latter makes a system call to transfer execution to the kernel, whereby register rcx points to the font path string provided by the application.

Note that the font path string contains one or more paths to font files (delimited with a '|' character), and that Adobe Type 1 PostScript fonts are identified by three file extensions: .mmm, .pfb, and .pfm. All Adobe Type 1 PostScript fonts require a .pfm file and a .pfb file, and multi-master files require an additional .mmm file.

Our plan was then simple: we would inject our patch right before the syscall instruction in function NtGdiAddFontResourceW, where it would look for any occurrences of ".pfm" or ".mmm" in the font path string - and bypass the syscall if any were found. In order to make this comparison case-insensitive (we wouldn't want attackers to bypass our patch with a font file named malicious.PfM, would we?), we would first change the entire font path string to upper case, and then search for ".PFM" or ".MMM". While this simple check would also block non-Type-1-PostScript font files containing ".PFM" or ".MMM" elsewhere in their filenames (e.g., OpenType.MMMregular.otf which I've just made up for illustration), we decided to rather keep the patch code small and not account for such unlikely cases.


The Micropatch



This is the micropatch we created for 64-bit Windows 7 without ESU:




MODULE_PATH "..\Affected_Modules\gdi32.dll_6.1.7601.24540_64bit\gdi32.dll"
PATCH_ID 420
PATCH_FORMAT_VER 2
VULN_ID 6050
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x00009c00  ; Beginning of function NtGdiAddFontResourceW
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
  
    code_start
        ; font path string (wide char) is in rcx
        ; example: "\??\C:\Analysis\ADV200006\SOSUE___.pfm|\??\C:\Analysis\ADV200006\SOSUE___.PFB"
        ; we make sure to restore rcx after we're done
        ; we can pollute rax because the original code doesn't use its value after our patch

        ; first upper-case the whole string

        push rcx
    LOOP1:
        cmp word [rcx], 0
        je END1
        cmp byte [rcx], 'a' ; if below 'a', no need to upper-case
        jb SKIP1
        cmp byte [rcx], 'z' ; if above 'z', no need to upper-case
        ja SKIP1
        sub byte [rcx], 0x20 ; make it upper-case
    SKIP1:
        add rcx, 2 ; next wide-char character
        jmp LOOP1
    END1:
        pop rcx

        ; now search for ".PFM" and ".MMM" in the string
      
        push rcx
    LOOP2:
        cmp word [rcx], 0          ; did we reach end of the string?
        je END2                    ; note that we don't care if we test for four
                                   ; characters a bit beyond the buffer;
                                   ; there's always readable memory there and there can't be an
                                   ; unwanted match because the string is null-terminated
        mov rax, 004D00460050002Eh ; ".PFM" (in LSB byte order)
        cmp qword [rcx], rax       ; is there ".PFM" at [rcx]?
        je BLOCK                   ; if ".PFM" is found, we block the loading of the font
        mov rax, 004D004D004D002Eh ; ".MMM" (in LSB byte order)
        cmp qword [rcx], rax       ; is there ".MMM" at [rcx]?
        je BLOCK                   ; if ".MMM" is found, we block the loading of the font
    SKIP2:
        add rcx, 2                 ; next wide-char character
        jmp LOOP2
    BLOCK:
        pop rcx
        mov rax, 0                 ; simulate the syscall returning an error when trying to
                                   ; load the font
        retn                       ; return and avoid syscall being called
    END2:
        pop rcx
      
    code_end
  
patchlet_end



With this micropatch in place, all applications using Windows GDI for font-related operations will find any Adobe Type 1 PostScript fonts rendered invalid and unable to load. For example, Windows Explorer will start looking like this when viewing a folder with a pair of otherwise valid PFM and PFB files:


With our micropatch in place, Windows Explorer no longer shows glyphs from Adobe Type 1 PostScript fonts in thumbnails or in Preview or Details Pane.

Of course, other types of fonts, including OpenType fonts, remain valid.


Video



Here's our micropatch in action:







Frequently Asked Questions


Q: What are advantages of your micropatch compared to Microsoft's recommended workarounds?

Our micropatch requires zero user interaction for existing 0patch users - they do not even need to know there is some vulnerability out there and that they should do something to neutralize it. For Enterprise users, deploying this micropatch is as simple as enabling it in 0patch Central and waiting for 0patch Agents to sync. (Disabling it is just as simple, should it be needed.)


Q: Any disadvantages of your micropatch compared to Microsoft's recommended workarounds?

Renaming ATMFD.DLL or disabling ATMFD via registry makes the vulnerability unreachable even for a local attacker who has ability to execute low-privileged arbitrary code on the computer. Our micropatch doesn't protect against a local attacker: they can write their own program that makes a direct system call to the kernel and thereby avoid our micropatch. Our micropatch protects against remote attack vectors. 


Q: Will Microsoft provide a patch for these vulnerabilities to Windows 7 and Windows Server 2008 R2 users without Extended Security Updates?

Microsoft's advisory clearly states that they won't. This makes our micropatch especially important for 0patch users on these Windows systems. We at 0patch have committed to provide post-end-of-service security micropatches for Windows 7 and Windows Server 2008 R2 for three additional years. (Read FAQ for more information.)


Q: What will happen if I apply your micropatch, and then apply Microsoft's patch for these issues when it comes out?

Microsoft patch for these vulnerabilities  will likely be in ATMFD.DLL, not in GDI32.DLL which we patched. If April Windows Updates also happen to change GDI32.DLL, our micropatch will automatically stop applying. If not, our micropatch will keep getting applied to GDI32.DLL and will keep blocking Adobe Type 1 PostScript fonts from reaching the kernel. Most users have no need for such (very old) fonts and will not be affected by our micropatch. Users who need to use Adobe Type 1 PostScript fonts will be advised to disable our micropatch after they have applied Microsoft's fix for these issues.


Q: Is this a PRO-only micropatch, or is it also available to 0patch FREE users?

To help people and organizations in these difficult times, we decided to make this micropatch available to everyone, so it is included in 0patch FREE until Microsoft issues their official update. At that time, we'll limit availability of this micropatch to 0patch PRO license holders. (And, as always, recommend everyone to apply the official update.)


Q: How can I deploy this micropatch in my organization's network?

Contact [email protected] for our Enterprise offering (including central management, setting patching policies, group management etc.). We'll set you up with some trial licenses and technical support for making your deployment smooth and quick.


Cheers!

@mkolsek
@0patch













Our First Weeks of Securing Windows 7 and Windows Server 2008 R2

22 February 2020 at 00:40
A quick status update

by Mitja Kolsek, the 0patch Team

[Update 2/22/2020: More details on the exploit code for CVE-2020-0674 were published, making exploitation by new malicious actors more likely.]

Hi 0patch users and supporters around the globe!

With February 2020 Patch Tuesday we began our three-year journey of providing critical security micropatches for Windows 7 and Windows Server 2008 R2 to our users, who could not - or decided not to - use Microsoft's Extended Security Updates.


Status of Windows 7 and Windows Server 2008 R2 micropatches



This first Patch Tuesday brought a large number of security fixes for these platforms, and we've set up a status page for public tracking of our progress on providing associated micropatches, which you can always find at this address:

Status of Windows 7 and Windows Server 2008 R2 micropatches

As you know, it is not our goal to provide micropatches for all vulnerabilities fixed by Microsoft - instead, our goal is to provide micropatches for high-risk vulnerabilities: those that are likely to get exploited (e.g., because details are published), that allow for a remote attack (e.g., through visiting a malicious web page, or opening a malicious email or document). This doesn't mean we won't micropatch publicly detailed local privilege escalation issues, but they will have a lower priority.


Improved Micropatch for CVE-2020-0674


You will remember that after January Patch Tuesday, Microsoft issued an advisory about a remotely exploitable vulnerability in Scripting Engine CVE-2020-0674 that was detected as being used in the wild. There was no official patch from Microsoft and their workaround had some unpleasant side effects, so we stepped in and created a micropatch without such side effects. Both the workaround and our micropatch did prevent functioning of legacy JScript code, so any web page still using it (and we hear from our enterprise users that JScript is still very much alive in internal corporate web applications) would not work properly.

As expected, Microsoft fixed this issue with February Patch Tuesday, but not for Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. In addition, the original reporters of this issue, a Chinese security company Qihoo 360, published a technical article which provided sufficient information about the vulnerability that anyone skilled in this game could easily reproduce it. The latter changed our risk assessment - before the exploitation was limited, but now anyone motivated can build an exploit and start targeting vulnerable Windows computers.

And there are at least as many vulnerable Windows computers out there as there are Windows 7 computers without Extended Security Updates.

So we reproduced the issue and traced the root cause to JScript function sort(), specifically when called using a sorting function, and its binary code implementation in function JsArrayFunctionHeapSort.  This function has changed significantly with February updates, but so have many, many others, and we know from previous analyses of jscript.dll that many of these changes are not security related. (One is impressed with how much development effort Microsoft continues to invest in this legacy scripting engine.)

While we understood what the root cause of the issue was and knew what had to be done to fix it, we did not find a sufficiently risk-free method of doing it, at least not yet, and thus decided on a compromise: we would remove the exploitable part of sort()'s functionality, effectively causing

array.sort(sortfunction)

to become

array.sort()


It was our assessment that this change should not have a significant impact on majority of web applications using JScript. (If any 0patch users do experience a significant impact, please contact [email protected]!)

Our primary target for this micropatch were Windows 7 and Windows Server 2008 R2 computers, for which we also revoked our initial "workaround" micropatch. However, we subsequently learned that February Windows Updates were causing severe problems for Windows 10 v1903/v1909 users, prompting many of them to likely delay or forgo applying of these updates. Since that would leave them vulnerable to CVE-2020-0674, we ported our micropatch to Windows 10 v1903/v1909 as well (and revoked the associated "workaround" micropatch).


Online Test For 0patch Users


Once we had micropatched this web-deliverable vulnerability, we were able to construct an online test for all our 0patch users to check whether the micropatch is getting properly applied. This is particularly important for Windows 7 and Windows Server 2008 R2 users, who need to have their computers fully updated in order for our post-end-of-service micropatches to apply.





The online test page is located here:

https://0patch.com/poc/CVE-2020-0674/0patch_test.html

To use it, you have to visit it with Internet Explorer 11; Internet Explorer is the only browser using jscript.dll, and we only provided a micropatch for version 11 as this is the only still-supported version on Windows 7 and Server 2008.

Once you open the test page, you will see one of the following:






This means everything is okay; your computer is properly updated for 0patch, and 0patch has applied the micropatch for CVE-2020-0674 to your Internet Explorer, making you not-vulnerable.






This message indicates that our micropatch did not get applied. You may have not applied the January 2020 rollup update on your computer, or are using Internet Explorer version other than 11. Or, you may be on Extended Security Updates, in which case this test doesn't apply to you.

Go ahead, use this test and let us know ([email protected]) if our micropatch isn't getting applied.



What's Next?



Being that CVE-2020-0674 was the only remote code execution vulnerability with a published proof of concept, micropatching it was our priority. There are a couple of other issues in our status table that are already making us busy with either recreating a proof-of-concept or already analyzing the vulnerability, but there is one issue that stands out: the LNK vulnerability (CVE-2020-0729), which has "massive exploitation" written all over it. It also reportedly has a proof-of-concept successfully reproduced in the security research community, so once those details are available, we'll have to respond quickly to protect our users.

Cheers!

@mkolsek
@0patch






Letter To 0patch Users (February 10, 2020)

10 February 2020 at 15:10

Subject: 0patch - What you need to know about Windows 7 and Windows Server 2008 R2 security micropatches


Dear 0patch user,

Thank you for putting your trust in 0patch to supply your computers with security micropatches. Tomorrow is the first Patch Tuesday when Windows 7 and Windows Server 2008 R2 systems that aren't registered for Microsoft's Extended Security Updates will not receive official Windows security patches, and instead depend on us to provide security micropatches for the most critical vulnerabilities.

We'd like to set your expectations and help you stay well-informed during our journey.

Whenever we become aware of a critical vulnerability affecting Windows 7 or Windows Server 2008 R2 (whether through Microsoft issuing a patch for it, or from any other source), we'll create an article for that vulnerability on our Support site (https://0patch.zendesk.com) that will provide information such as:

    - CVE ID
    - Our own risk assessment (with explanation)
    - Status of our micropatch (e.g., "in development", "waiting for test case", "issued")
    - Possible (and reported) side effects of our micropatch
    - Workarounds (for when micropatch is not available, or if you don't want to apply it)
    - Frequently asked questions
    - Links to our own and external articles related to this issue
    - Procedure for testing our micropatch (optionally)
    - Credits to people helping us with the micropatch

We will continually update these articles as new information gets available.

We will also start sending Patch Tuesday updates and alerts about issued micropatches to "0patch News" mailing list (newsletter) so we highly recommend you subscribe to it to know which vulnerabilities we have micropatched and whether we recommend applying any workarounds for issues we can't (yet) micropatch.

To subscribe to "0patch News", visit https://0patch.com/contact.html, provide your email address to the form on the right side, tick the "0patch Newsletter" box and press Subscribe.

We will make our best effort to provide users will timely, accurate, and actionable information for keeping their Windows 7 and Windows Server 2008 R2 systems as secure as possible.

Thank you again,

Mitja Kolsek
0patch co-founder

Micropatching a Workaround for CVE-2020-0674

21 January 2020 at 15:23
A Kill Switch for Vulnerable jscript.dll

by Mitja Kolsek, the 0patch Team





Last Friday, Microsoft published an advisory about a remotely exploitable memory corruption vulnerability (CVE-2020-0674) that was reported to them by Qihoo 360 as being exploited in the wild. These attacks were reportedly limited so Microsoft decided not to rush with issuing a patch but will rather provide one as part of February's Patch Tuesday. They did, however, provide a workaround.

Because the provided workaround has multiple negative side effects, and because it is likely that Windows 7 and Windows Server 2008 R2 users without Extended Security Updates will not get the patch at all (their support ended this month), we decided to provide a micropatch that simulates the workaround without its negative side effects.

The vulnerability is in jscript.dll, which is the scripting engine for legacy JScript code; note that all "non-legacy" JScript code (whatever that might be), and all JavaScript code gets executed by the newer scripting engine implemented in jscript9.dll.

Microsoft's workaround comprises setting permissions on jscript.dll such that nobody will be able to read it. This workaround has an expected negative side effect that if you're using a web application that employs legacy JScript (and can as such only be used with Internet Explorer), this application will no longer work in your browser.

There also several other negative side effects:

Microsoft's advisory states that the provided workaround will have to be reverted when they issue a patch for jscript.dll. However, note that some additional side effects may result from changing the ownership on jscript.dll (from TrustedInstaller to the user you're implementing the workaround as).


Test Case


Finding a test case that triggers the loading of jscript.dll was not difficult - Google Project Zero has one published in an advisory from November last year. (It won't be at all surprising if the vulnerability at hand is either a clone of that one, or a bypass for its patch - but we'll know soon enough.)

So we took Google's example, simplified it to only cause the loading of jscript.dll for executing a single alert call. Note the important part is to specify JScript.Encode as language. (By the way, read the Wikipedia article on JScript.Encode for a primer on how to underestimate intelligent adversaries.)


<html>
<head>
 <meta http-equiv="X-UA-Compatible" content="IE=8"></meta>
</head>
<body>
<script language="Jscript.Encode">
 alert("jscript.dll was loaded");
</script>
</body>
</html>


The test was then simple: opening this file in IE without mitigation or patch should result in a popup saying "jscript.dll was loaded". With a patch, we would want the loading of jscript.dll to fail and consequently no popup to appear. Ideally, in a graceful manner without any ugly error messages or crashed processes.

Analysis


Sabotaging some functionality is usually a simple thing to do with a micropatch: you locate the code that implements or initializes said functionality, and make it fail. This was a case here too.

We first used Process Monitor to locate the code in Internet Explorer which loads jscript.dll. This was trivial as Process Monitor records a call stack for every operation, and it was obvious that mshtml.dll causes the loading of jscript.dll through a call to CoCreateInstance.


lea     eax,[esp+3Ch]
xor     edi,edi
push    eax
push    offset MSHTML!_GUID_bb1a2ae1_a4f9_11cf_8f20_00805f2cd064 (631bf2a8)
push    1
push    edi
lea     eax,[esp+0B4h]
push    eax
call    dword ptr [MSHTML!_imp__CoCreateInstance (641c301c)]
mov     ebx,eax
test    ebx,ebx


When this code is reached as a result of rendering a Jscript.Encode script block, the first argument (the last one pushed to the stack) points to a ClassID f414c262-6ac0-11cf-b6d1-00aa00bbbb58, which instantiates a jscript.dll object.

Great, could we just sabotage this call and be done with it? Unfortunately not; this same function is being used for instantiating other objects as well, so we need to be selective here.

We decided to make a micropatch that checks, before the call to CoCreateInstance is made, whether its first argument equals f414c262-6ac0-11cf-b6d1-00aa00bbbb58, and if so, sabotages the call by setting its last argument (pvv) to NULL, causing CoCreateInstance to return error 0x80070057 (E_INVALIDARG). This has the same effect as making jscript.dll impossible to read.

But before settling with that, we wanted to check if there were any other ways in which a malicious web page could have code executed by jscript.dll. So we scanned the Registry for all ClassIDs associated with jscript.dll that were loadable via a script tag - and found Jscript.Compact to be such an alternative. So we made another HTML test file:


<html>
<head>
 <meta http-equiv="X-UA-Compatible" content="IE=8"></meta>
</head>
<body>
<script language="Jscript.Compact">
 alert("jscript.dll was loaded");
</script>
</body>
</html>


And sure enough, this one also executed the alert with jscript.dll.We therefore had to add another ClassID check to our micropatch, also preventing cc5bbec3-db4a-4bed-828d-08d78ee3e1ed from getting instantiated.

The final micropatch then became:


MODULE_PATH "..\Affected_Modules\mshtml.dll_11.0.17763.831_32bit\mshtml.dll"
PATCH_ID 1000004
PATCH_FORMAT_VER 2
VULN_ID 5897
PLATFORM win32

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2

PATCHLET_OFFSET 0x3bcf36
N_ORIGINALBYTES 5

code_start

  ; At this point, ClassID is stored at address pointed to by [esp+0ACh]
  ; If we want to sabotage the call, we put 0 at [esp+0ch] (argument ppv), which
  ; will cause error 0x80070057 (E_INVALIDARG)

  ; Compare ClassID with f414c262-6ac0-11cf-b6d1-00aa00bbbb58 (Jscript.Encode)
  cmp dword [esp + 0ACh], 0xf414c262
  jne skip1
  cmp dword [esp + 0ACh + 4h], 0x11cf6ac0
  jne skip1
  cmp dword [esp + 0ACh + 8h], 0xaa00d1b6
  jne skip1
  cmp dword [esp + 0ACh + 0Ch], 0x58bbbb00
  jne skip1
 
  mov dword [esp + 0xc], 0 ; Sabotage the call to CoCreateInstance by setting ppv to 0
 
 skip1:

 ; Compare ClassID with cc5bbec3-db4a-4bed-828d-08d78ee3e1ed (Jscript.Compact)
  cmp dword [esp + 0ACh], 0xcc5bbec3
  jne skip2
  cmp dword [esp + 0ACh + 4h], 0x4beddb4a
  jne skip2
  cmp dword [esp + 0ACh + 8h], 0xd7088d82
  jne skip2
  cmp dword [esp + 0ACh + 0Ch], 0xede1e38e
  jne skip2
 
  mov dword [esp + 0xc], 0 ; Sabotage the call to CoCreateInstance by setting ppv to 0
 
 skip2:

code_end
patchlet_end


We ported this micropatch to the following platforms, both 32-bit and 64-bit:

  • Windows 7,
  • Windows 10 v1709,
  • Windows 10 v1803, 
  • Windows 10 v1809, 
  • Windows 10 v1903, [issued on 1/30/2020]
  • Windows 10 v1909, [issued on 1/30/2020]
  • Windows Server 2008 R2, 
  • Windows Server 2019 

If you're a 0patch user, you already have this micropatch downloaded to all your online computers with 0patch Agent, and - depending on your settings - already automatically applied to all processes using the Internet Explorer 11 engine for rendering content. This includes Internet Explorer (obviously), Microsoft Word, Microsoft Outlook, and a variety of other applications.

As all our micropatches, you can switch this micropatch on or off and have it instantly applied to, or removed from running applications - effectively making it a "kill switch" for jscript.dll.

If you're using other Windows versions or older Internet Explorer versions and are interested in having this micropatch ported to your systems, please contact us at [email protected].


Video


Here's our micropatch in action:






Frequently Asked Questions


Q: Why would we apply your micropatch instead of Microsoft's recommended workaround?

Our micropatch is designed to avoid negative side effects of Microsoft's workaround (see above). It can also be easily reverted (un-applied) with a switch of a button without leaving any traces, while the workaround changes the ownership on jscript.dll.


Q: Will Microsoft provide a patch for CVE-2020-0674 to Windows 7 and Windows Server 2008 R2 users without Extended Security Updates?

We don't know but these systems are now officially out of support and Microsoft has historically only issued security patches for unsupported systems in extreme cases (e.g., the Shadow Brokers leak, or BlueKeep / CVE-2019-0708).

We at 0patch have committed to provide post-end-of-service security micropatches for Windows 7 and Windows Server 2008 R2 for three additional years, which is why we're also issuing this micropatch for these platforms. (Read FAQ for more information.)


Q: What will happen if I apply your micropatch, and then apply Microsoft's patch for CVE-2020-0674 when it comes out?

When Microsoft issues a patch for this vulnerability, we'll inspect it and decide whether to replace our current micropatch (which resides in mshtml.dll and disables jscript.dll entirely) with a more targeted micropatch in jscript.dll (which will only fix that vulnerability but keep jscript.dll available). It might happen that we do so on supported Windows platforms but keep the current micropatch on Windows 7 and Windows Server 2008 R2. This also depends on user feedback (i.e., whether our micropatch causes anyone problems).

In any case, you won't have to do anything - Microsoft's patch will have precedence over our micropatch.


Q: I suspect your micropatch is causing problems on my computer. What should I do?

Make a quick test: Disable 0patch Agent and execute your affected process - if the problem is still there, it's unlikely the cause of your problem is our micropatch. However, if your problem goes away, please report that to [email protected] and temporarily disable micropatches 402-405 on your 0patch Agent.

Users on the Enterprise plan can enable and disable individual patches centrally through 0patch Central.


Q: Are there any applications using jscript.dll directly (not though Internet Explorer browser component) that could still be used as attack vector?

We're aware of one - Windows Media Player (WMP) uses jscript.dll directly and will still be able to do so when our micropatch is applied. WMP allows displaying a remote web site when playing certain files but the user has to confirm a security warning for that. This was the reason we decided not to micropatch WMP as well.


Q: How can I deploy this micropatch in my organization's network?

Contact [email protected] for our Enterprise offering (including central management, setting patching policies, group management etc.). We'll set you up with some trial licenses and technical support for making your deployment smooth and quick.


Cheers!

@mkolsek
@0patch








0patch Central: We are Now Ready to Micropatch Your Enterprise

6 January 2020 at 14:03

0patch Central, our central management solution, is now ready to accept first users 

 

by Stanka Salamun, the 0patch Team



At 0patch, we are on the mission to make your security patching virtually imperceptible:

  • We patch your most critical 0days.
  • We buy you time by protecting you with micropatches while you test official vendor updates.
  • We secure your unsupported products after they lose their vendors' support (Windows 7 and Windows Server 2008).

We do it in the most convenient way you've ever experienced: you don't need to reboot computers or restart applications, you can switch off a potentially problematic patch (and later switch it on again), our micropatches are so tiny that most could be published in a single tweet. They are delivered and applied within an hour of their publication, without any activity on user's or administrator's part. Needless to say, we don't tinker with functionality of your applications: we don't change, add or remove anything (unless it's vulnerable and we can't repair it any other way).
  
But one of the most common questions we've been receiving from our users lately was: when will your remote central management be ready for enterprises? We are excited to inform you that 0patch Central, our cloud-based enterprise management solution, is now ready to accept first users, and you're invited!

This is a big thing for us, and for all enterprise users asking for central management of their 0patch Agents. If you have a non-trivial fleet of Windows computers to protect with our micropatches, 0patch Central is your central management solution.

What can you do with 0patch Agents remotely?

  • You can make them completely silent for end users.
  • You can organize them into groups and subgroups.
  • You can move them between groups (which will change their patching policy to the destination group's).
  • You can enable or disable them.
  • You can update them to the latest version.
  • You can delete them. (But no worries, you can also bring them back.)
  • For each group you can define patches that are enabled or disabled. You can even do that for individual computers, remotely. 


And how do you set up patching policy in 0patch Central? 

0patch Central - "All Computers" group

 

Let's look at two frequent scenarios:


Scenario 1: The traditional enterprise "Test in a small group before deployment" setup

1) Open the root All Computers group, open the Settings tab, and set Default state for new patches to "Disabled" - this will result in all newly arrived patches being disabled on all computers in this group.

2) Create a subgroup called Testing, open its Settings tab, and set Default state for new patches to "Enabled" - this will result in all newly arrived patches being enabled on all computers in trhis group.

3) Select and move your testing machines from the All Computers group to the Testing group - these computers will get all newly downloaded patches immediately applied.

4) When you decide that some patch has been sufficiently tested on computers in the Testing group for network-wide deployment, open the All Computers group, Patches tab, locate the patch and set it to "Enabled"


Scenario 2: The "I don't have time for this, just micropatch my 0days immediately" setup

1) Open the root All Computers group, open the Settings tab, and set Default state for new patches to "Enabled" - this will result in all newly arrived patches being immediately enabled on all computers.




You'll find 0patch Central at address https://central.0patch.com, where you can login with your existing 0patch credentials, or register a new account. In case you don't have a 0patch account yet, just register a new account at https://central.0patch.com/auth/register. When you have your 0patch account ready, let us know at [email protected] which email address you used so we can issue some trial PRO licenses and turn on the "Enterprise" switch for you. This will allow you to access all Enterprise features such as organizing agents into groups and setting patching policy for each individual group.

If you apply for your Enterprise trial while we are still in "Early Access" you will get your 0patch Enterprise licenses for the price of 0patch PRO for your first yearly subscription. But do not wait too long as we are closing "Early Access" just before Q2 2020 starts.


Important! Remote management only works with our just-released 0patch Agent version (19.11.15.10650) so while you will be able to see your older agents in 0patch Central, you won't be able to do anything with them. To resolve this, please manually update all existing agents to the latest version and make sure to only use the latest agent version for all future installs. All subsequent agent updates will from then on be manageable from 0patch Central.

We tried to design 0patch Central intuitively and with minimal complexity, and hope you won't be needing much help using it. But we're not fooling ourselves. You'll surely have questions and we're anxiously waiting for you at [email protected]. Don't hesitate to ask or suggest anything as we want to make 0patch Central a tool that will make your patching life as easy as possible. If something is not obvious to you, it's probably not obvious to others as well, so do let us know about it.



We had to focus on enterprise features first, but next items on our to-do list will be to make life much easier for MSPs and VARs.

Welcome to 0patch Central, we hope it'll serve you well and become your effective little patching assistant!


Micropatching Keeps Windows 7 and Windows Server 2008 R2 Secure After Their End-Of-Support

20 September 2019 at 13:17
Becoming an Adoptive Parent For Abandoned Windows

by Mitja Kolsek, the 0patch Team





Hello people, it's nice to step out for a moment and see the daylight. Those of you following us have noticed our near radio silence in the past months. To stop you from worrying I'd like to just quickly update you all on what's going on inside our walls (spoiler: a lot) and what our plans are (spoiler: big).

As you know, Windows 7 and Windows Server 2008 R2 are reaching their end-of-support on January 14 next year, which is causing a lot of headaches for people and companies who are entirely happy with the way these OSs work, or have compatibility requirements preventing them from upgrading. If they want to keep receiving security fixes, their options are: (a) to upgrade to Windows 10 and a newer server version, or (b) to buy Extended Security Updates from Microsoft (conditions apply, and 3rd party patch management solutions cannot be used for delivery).

NetMarketShare shows that last month, 5 months before end-of-support, 30% of desktop OSs were running Windows 7. With the current upgrading trend, we can safely forecast that the number of Windows 7 machines on February 11, 2020 (the first Patch Tuesday to exclude them) will be approximately somewhere between huge and vast. There are few public stats on how Windows Server 2008 R2 is doing but judging from what our users are saying, it's not going to get extinct anytime soon.
 
You see where we're going with this. Back in January 2018, we at 0patch "security-adopted" Microsoft Office Equation Editor, a program integrated into Microsoft Word with which scientists, teachers and students had written millions of equations. They were all suddenly left without a way to edit their equations when Microsoft decided to delete Equation Editor from their computers.

What we did was create micropatches for all known Equation Editor vulnerabilities and made instructions for users to bring back Equation Editor on their computers so they could continue using it while keeping Office regularly updated with Microsoft's security patches.

But that was just a trial run for becoming an adoptive parent of a vendor-abandoned product. This time we're going bigger: we're going to security-adopt Windows 7 and Windows Server 2008 R2 for those of you who want to keep them patched after their official security updates have dried out.

What does this mean, exactly?

It means that after the last official security update has been issued for Windows 7 and Windows Server 2008 R2 in January 2020, we'll start doing the following:

  1. Each Patch Tuesday we'll review Microsoft's security advisories to determine which of the vulnerabilities they have fixed for supported Windows versions might apply to Windows 7 or Windows Server 2008 R2 and present a high-enough risk to warrant micropatching.
  2. For the identified high-risk vulnerabilities we'll inspect Windows Updates for supported Windows versions (e.g., Windows 10) to confirm whether the vulnerable code that was fixed in Windows 10 is actually present on Windows 7 or Windows Server 2008 R2. (For all intents and purposes, such vulnerabilities will be considered 0days for these OSs.)
  3. If the high-risk vulnerable code is found to be present on Windows 7 or Windows Server 2008 R2, we'll start a process of obtaining a proof-of-concept (POC) for triggering the vulnerability. Sometimes a POC is published by security researchers soon after the official vendor fix is out (and sometimes even before); other times we can get one from our partner network or threat intelligence sources; occasionally researchers share a POC with us privately; and sometimes we have to create a POC ourselves by analyzing the official patch and working our way out towards the input data that steers the execution to the vulnerability.
  4. Once we have a POC and know how the vulnerability was fixed by the people who know the vulnerable code best (i.e., Microsoft developers), we'll port their fix, functionally speaking, as a series of micropatches to the vulnerable code in Windows 7 and Windows Server 2008 R2, and test them against the POC. After additional side-effect testing we'll publish the micropatches and have them delivered to users' online machines within 60 minutes. (Which by the way means that many Windows 7 and Windows Server 2008 R2 will be patched sooner than those with still-supported Windows versions where organizations will continue to prudently test Windows updates for days or weeks before having them applied to all computers.)

We expected you might have questions at this point; please see our FAQ about Windows 7 and Windows Server 2008 R2 Post-End-of-Support Security Micropatches

Okay - but what are we so busy with now? A lot of things:
 
Firstly, in order for large organizations to be able to use 0patch efficiently, we're developing a central management service (think WSUS for 0patch, but nice and fast) which will allow admins to organize computers in groups and apply different policies to these groups. Admins will thus be able to set up "testing" groups where new micropatches will be applied immediately, and subsequently have them applied to the rest of their computers with a few clicks (and of course, without users ever noticing anything). Naturally they'll also be able to un-apply any micropatches just as easily and quickly should they choose to. There will be alerts, graphs, reports, and drill-downs, and the very next step will be an on-premises version of 0patch server which so many organizations are asking for.

Secondly, we're growing our team: things are buzzing in our 0patch bootcamp and a nice side effect of passing one's knowledge onto others is that one has to neatly organize and document it. Consequently, adding further new members to the team afterwards will be even smoother and quicker.

Lastly, we're enhancing our reversing, patch analysis, vulnerability analysis, micropatch development and micropatch porting processes with new tools and techniques. Suffice to say that we've never had as many disassemblers, debuggers, decompilers, plugins and concurrently opened reversing projects running as we have now. But the thing I'm personally most excited about is our introduction of symbolic execution in micropatch creation, verification and porting processes. We've been aiming for eventual formal verification of our micropatches since the beginning and we're finally working on that. But not only that: symbolic execution and emulation will help us avoid errors sooner during micropatch development and allow us to perform unit testing against micropatched code even before we have a POC. Goosebumps!

This concludes our news from the 0patch lab. If you're interested in getting early access to 0patch central management (in November), or have any questions about our service, please consult Frequently Asked Questions or send an email to [email protected].


Cheers!

@mkolsek
@0patch
❌