URL File NTLM Hash Disclosure Vulnerability (0day) - and Free Micropatches for it

 

Our researchers discovered a vulnerability on all Windows Workstation and Server versions from Windows 7 and Server 2008 R2 to the latest Windows 11 v24H2 and Server 2022. The vulnerability allows an attacker to obtain user's NTLM credentials by simply having the user view a malicious file in Windows Explorer - e.g., by opening a shared folder or USB disk with such file, or viewing the Downloads folder where such file was previously automatically downloaded from attacker's web page.

We reported this issue to Microsoft, and - as usual - issued micropatches for it that will remain free until Microsoft has provided an official fix.

We are withholding details on this vulnerability until Microsoft's fix becomes available to minimize the risk of malicious exploitation. 

This is the third 0day we have recently found and reported to Microsoft, after the Windows Theme file issue (still a 0day without an official patch) and the Mark of the Web issue on Server 2012 (also still a 0day without an official patch).

In addition, the "EventLogCrasher" vulnerability, allowing an attacker to disable all Windows event logging on all domain computers (reported to Microsoft in January this year by security researcher Florian), is still waiting for an official patch so our patches for it are the only ones available.

There are also currently three NTLM-related publicly known "wont fix" vulnerabilities that Microsoft decided not to patch with 0patch patches available: PetitPotam, PrinterBug/SpoolSample and DFSCoerce. All of these are present on all latest fully updated Windows versions, and if your organization is using NTLM for any reason, it could be affected.

Currently, 40% of our users are using 0patch for protection against 0day and "wont fix" vulnerabilities, while others use 0patch for keeping their legacy Windows systems and Office versions secure with our security patches.

Micropatch Availability

Since this is a "0day" vulnerability with no official vendor fix available, we are providing our micropatches for free until such fix becomes available.

Micropatches were written for:

 Legacy Windows versions:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 - fully updated with no ESU or ESU 1
    
11. Windows Server 2012 R2 - fully updated with no ESU or ESU 1
12. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
    

 Windows versions still receiving Windows Updates:

1. Windows 11 v24H2 - fully updated   
2. Windows 11 v23H2 - fully updated
3. Windows 11 v22H2 - fully updated
4. Windows 10 v22H2 - fully updated
5. Windows Server 2022 - fully updated
   
6. Windows Server 2019 - fully updated 
7. Windows Server 2016 - fully updated 
8. Windows Server 2012 fully updated with ESU 2
   
9. Windows Server 2012 R2 fully updated with ESU 2

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

 

Did you know 0patch will security-adopt Windows 10 when it goes out of support in October 2025, allowing you to keep using it for at least 5 more years? Read more about it here.

To learn more about 0patch, please visit our Help Center.

Windows Server 2012 Mark of the Web Vulnerability (0day) - and Free Micropatches for it

Our researchers discovered a previously unknown vulnerability on Windows Server 2012 and Server 2012 R2 that allows an attacker to bypass a security check otherwise enforced by Mark of the Web on certain types of files.

Our analysis revealed this vulnerability was introduced to Windows Server 2012 over two years ago, and remained undetected - or at least unfixed - until today. It is even present on fully updated servers with Extended Security Updates.

We reported this issue to Microsoft, and, as usual, issued micropatches for it that will remain free until Microsoft has provided an official fix.

We are withholding details on this vulnerability until Microsoft's fix becomes available to prevent malicious exploitation.

Micropatch Availability

Since this is a "0day" vulnerability with no official vendor fix available, we are providing our micropatches for free until such fix becomes available.

Micropatches were written both for our:

 Legacy Windows versions:

1. Windows Server 2012 updated to October 2023
2. Windows Server 2012 R2 updated to October 2023

 Windows versions still receiving Windows Updates:

1. Windows Server 2012 fully updated with Extended Security Updates
   
2. Windows Server 2012 R2 fully updated with Extended Security Updates
   

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

 

Did you know 0patch will security-adopt Windows 10 when it goes out of support in October 2025, allowing you to keep using it for at least 5 more years? Read more about it here.

To learn more about 0patch, please visit our Help Center.

Micropatches for "LNK Stomping" Windows Mark of the Web Security Feature Bypass (CVE-2024-38217)

 

September 2024 Windows Updates brought a patch for CVE-2024-38217 a.k.a. "LNK Stomping", a security bypass vulnerability allowing an attacker to prevent the "Mark of the Web" (MotW) being applied to a downloaded malicious file.

The vulnerability was reported by security researcher Joe Desimone with Elastic Security, who published a detailed analysis and shared a proof-of-concept. This allowed us to reproduce the issue and issue our own patches for it for various security-adopted Windows versions that are no longer receiving updates from Microsoft.

 

The Vulnerability

Any downloaded file should get a Mark of the Web (a label in its alternate data stream marking its untrusted origin) and this also goes for LNK (Windows shortcut) files. A LNK file points to an executable file with optional parameters, such as powershell.exe or cmd.exe, which gets executed with optional command-line arguments when a user double-clicks the shortcut.

However, when a LNK file points to an executable file ending with some additional character (e.g., an extra dot), Windows automatically correct this by removing the extra character from the path and saving the corrected LNK file back to disk - removing the Mark of the Web in the process.

 

Microsoft's Patch

Microsoft patched this issue by modifying the CShellLink::_SaveAsLink function such that instead of calling SHCreateStreamOnFileW when saving a corrected LNK file, it now calls SHCreateStreamOnFileEx using an additional flag, which results in MotW not being deleted in the process.

Our Micropatch

Our patch is functionally identical to Microsoft's.

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012, Server 2012 R2 - fully updated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
    

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Joe Desimone with Elastic Security for sharing their analysis and proof-of-concept, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

Fixing a Bunch of Scripting Engine Vulnerabilities by Disabling Just-In-Time Compiler (CVE-2024-38178)

 

August 2024 Windows Updates brought a patch for CVE-2024-38178, a remotely exploitable memory corruption issue in "legacy" Scripting Engine (JScript9.dll). This engine, while part of long-expired Internet Explorer, is still present on all Windows computers and can be invoked via various mechanisms, for instance from an Office document.

Subsequently, security researchers Hosu Choi and Minyeop Choi of S2W Talon published a detailed article, which included a short proof-of-concept script, allowing us to reproduce the issue and issue our own patches for it.

 

The Vulnerability

This is yet another vulnerability in JScript9.dll's Just-in-Time (JIT) compiler. We've patched these kinds of issues in JScript9 JIT before (CVE-2021-34480, CVE-2022-41128), and this issue is actually just a bypass for the latter's patch.

In a similar way as with CVE-2022-41128, exploitation is done by malicious JavaScript code rendered by JScript9.dll, which first forces Scripting Engine to switch to JIT by executing a very long loop, thereby triggering JIT optimization. The JIT'ed malicious function is written so that JIT compiler generates flawed code, which is then used for corrupting memory and finally executing attacker's code on user's computer.

We encourage you to read the SW2 Talon article for details.

 

Microsoft's Patch

Microsoft patched this issue with a substantial amount of additional code, and an extension of some data structures.

Our Micropatch

We usually create our patches to be logically identical, or at least similar to Microsoft's. However, in this case we decided to take a different approach: namely, while JIT-compiled code can be significantly faster than interpreted JavaScript bytecode, this effect is strongest on special cases that are typically not encountered in real-world use.

On the other hand, about 50% of all vulnerabilities in browsers are related to JIT, which led Microsoft to introduce a "Super Duper Secure Mode" to their Edge browser already back in 2021. This mode disables JIT, and as claimed in their article, "... we find that users with JIT disabled rarely notice a difference in their daily browsing."

So we decided to fix some past JIT-related vulnerabilities that we had no test cases for, and all future JIT-related vulnerabilities in Jscript9.dll - by simply disabling JIT. In contrast to Edge, Internet Explorer never had a switch to disable JIT, so we couldn't piggyback on that and had to find our own way. Our approach was to patch function NewFunctionCodeGen, which is called whenever some JavaScript code should be JIT compiled, such that it always returns an error - so the execution continues with JavaScript bytecode instead.

Our patch has a single CPU instruction, setting the return value of function NewFunctionCodeGen to 0. The calling function, checking for this error, does the rest of the work.

;XX-2521
MODULE_PATH "..\AffectedModules\jscript9.dll_11.00.22000.1641_Win11-21H2_64-bit_u2023-10\jscript9.dll"
PATCH_ID 2075
PATCH_FORMAT_VER 2
VULN_ID 7838
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x104183
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    code_start
        mov rax, 0
        
    code_end
patchlet_end

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 R2 - fully updated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
    

 

Interestingly, JScript9.dll on Windows Server 2012 (non-R2) does not seem to support JIT, so we didn't have to write a patch for it there.

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Hosu Choi and Minyeop Choi of S2W Talon for sharing their analysis and proof-of-concept, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

Micropatches Released for Remote Registry Service Elevation of Privilege Vulnerability (CVE-2024-43532)

 

October 2024 Windows Updates brought a patch for CVE-2024-43532, a vulnerability in Windows Remote Registry Service that could allow an attacker with access to network communication between administrator's computer and computer under remote administration to hijack the network connection and obtain administrator's credentials. These could then be relayed to another server, for instance an Active Directory Certificate Server, and used for creating a new certificate for subsequent authentication.

Note that the official title of this issue ("Remote Registry Service Elevation of Privilege Vulnerability") is incorrect, as the vulnerability is not in the Remote Registry Service but rather in the remote registry client code, i.e., in the component that remotely connects to the Remote Registry Service on another computer. We're reluctantly keeping this title to avoid the risk of anyone thinking these are two separate issues.

Security researcher Stiv Kupchik of Akamai found this vulnerability and reported it to Microsoft. Subsequently, Stiv published a detailed article and provided a proof-of-concept tool.

 

The Vulnerability

The root cause of this vulnerability is the use of an insecure authentication level in a RpcBindingSetAuthInfo call (advapi32.dll) from function BaseBindToMachine, which provides user-supplied parameters that control the behavior of an RPC binding to the remote machine. 

The default behavior of the BaseBindToMachine call is to first try to bind to the RPC endpoint using named pipes and RPC_C_AUTHN_LEVEL_PKT_PRIVACY, but when that doesn't work, fall back to the vulnerable tcp_ip protocol with RPC_C_AUTHN_LEVEL_CONNECT - which provides no security. Because of the vulnerable RPC_C_AUTHN_LEVEL_CONNECT parameter, the tcp_ip biding can then be relayed to a different endpoint of attacker's choosing, while authenticating with victim's credentials.

Stiv Kupchik found one occurrence of the vulnerable RegConnectRegistryExW call in the registry editor application, but various other applications are likely to use remote registry connections in the same way.

 

Microsoft's Patch

Microsoft patched this issue by changing the default behavior of remote registry connections initiated through function BaseBindToMachine, but it also introduced new registry values that control the protocol fallback policy and security policy. 

Our Micropatch

Our patch is logically equivalent to enforcing the "patched" behavior of function BaseBindToMachine (i.e., when TransportFallbackPolicy is absent or set to 1 - DEFAULT), disabling the fallback functionality and only allowing remote registry connections over named pipes with RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

Our patch has a single CPU instruction, whereby the pointer to the fallback protocol name is set to 0. Microsoft's original code in advapi32.dll then does the rest.

;XX-2562
MODULE_PATH "..\AffectedModules\advapi32.dll_10.0.19041.1052_Win10-2004_64-bit_u2021-12\advapi32.dll"
PATCH_ID 2029
PATCH_FORMAT_VER 2
VULN_ID 7839
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x42d9c
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
            
    code_start

        mov r15, 0x0    ;move 0 to r15 to replace the fallback protocol name pointer.

    code_end
patchlet_end

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 (standard and R2) - fully udpated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
    

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Stiv Kupchik of Akamai for sharing their analysis and proof-of-concept, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

We Patched CVE-2024-38030, Found Another Windows Themes Spoofing Vulnerability (0day)

TL;DR: While patching CVE-2024-38030, we found another similar issue, reported it to Microsoft and created free micropatches for 0patch users on both legacy and still-supported Windows versions so they don't have to wait for an official patch.

When last year Akamai security researcher Tomer Peled decided to look into Windows themes files, they found that when a theme file specified a network file path for some of the theme properties (specifically BrandImage and Wallpaper), Windows would automatically send authenticated network requests to remote hosts, including user's NTLM credentials when such theme file would be viewed in Windows Explorer. This meant that merely seeing a malicious theme file listed in a folder or placed on the desktop would be enough for leaking user's credentials without any additional user action.

Microsoft patched this issue (CVE-2024-21320) three months after receiving the report, and when vulnerability details were shared, we created patches for Windows systems that were no longer receiving Windows updates.

Tomer then looked at Microsoft's patch and noticed that it used function PathIsUNC to check if a given path in a theme file is a network path, and if so, disregarded such path. This should have prevented NTLM credentials leaks, if it weren't for James Forshaw, who described multiple ways of bypassing function PathIsUNC back in 2016. Tomer noticed that tricks described by James could be used to bypass Microsoft's patch for CVE-2024-21320, and reported that to Microsoft so they could try again.

Microsoft did fix their patch and assigned CVE-2024-38030 to the new issue.

When we learned about this second flaw, we had to fix our patches for CVE-2024-21320 as well. (We admit, we trusted Microsoft's choice on using PathIsUNC, but will be more careful going forward.) While analyzing the issue, our security researchers decided to look around a bit and found an additional instance of the very same problem that was still present on all fully updated Windows versions, up to currently the latest Windows 11 24H2.

So instead of just fixing CVE-2024-38030, we created a more general patch for Windows themes files that would cover all execution paths leading to Windows sending a network request to a remote host specified in a theme file upon merely viewing the file.

We were surprised Microsoft did not find this additional instance when fixing Tomer's initially reported issue. Namely, in their blog post about "Additional Fixes" Microsoft described their process of finding "variations" of reported vulnerabilities:

"The MSRC Engineering team reviews the affected component of each externally reported vulnerability. One part of the review is the “Hacking for Variations” (HfV) stage, which helps mitigate the threat of variants being discovered after the update is released. The HfV process is jointly undertaken by MSRC-Engineering and the product team. It involves reviewing the source code and the bug database as well as fuzzing the component and hurling it through our gauntlet of tools; many of which are new or have been updated since the component was first written."

Admittedly, said blog post was issued in 2011, and the only other Google hits on “Hacking for Variations” are also from 2011 or earlier. In any case, looking for bug variations seems like something every software vendor should be doing when learning about a security issue in their product.

Be that as it may, we reported our 0day to Microsoft and will withhold details from public until they have re-fixed their patch. Meanwhile, 0patch users are already protected against this 0day with our micropatch.

Micropatch Availability

Since this is a "0day" vulnerability with no official vendor fix available, we are providing our micropatches for free until such fix becomes available.

Micropatches were written both for our security-adopted legacy versions of Windows Workstation, and all still-supported Windows versions with all available Windows Updates installed:

 

 Legacy Windows versions:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3

 Windows versions still receiving Windows Updates:

1. Windows 10 v22H2 - fully updated
2. Windows 11 v22H2 - fully updated
3. Windows 11 v23H2 - fully updated
4. Windows 11 v24H2 - fully updated 
   

 

Note that patches were only created for Windows Workstation but not for Windows Server. This is because for Windows Themes to work on a server, the Desktop Experience feature needs to be installed (it's not by default). In addition, for credentials leak to occur on a server it's not enough just to view a theme file in Windows Explorer or on desktop; rather, the theme file needs to be double-clicked and the theme thus applied. Actually applying a Windows theme from an untrusted source is, from the security perspective, not very different from launching an untrusted executable. Getting a user to view a theme file in Windows Explorer, on the other hand, may be a simple matter of forcing a download of the theme file while the user is on attacker's web page, then waiting for the user to open the Downloads folder (depending on the view type of the Downloads folder).

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Tomer Peled of Akamai for sharing details of CVE-2024-38030. This prompted us to take a deeper look at theme files, find this additional issue, and allowed us to create a micropatch to fix it for 0patch users.

Did you know 0patch will security-adopt Windows 10 when it goes out of support in October 2025, allowing you to keep using it for at least 5 more years? Read more about it here.

To learn more about 0patch, please visit our Help Center.

Micropatches for Windows Installer Elevation of Privilege Vulnerability (CVE-2024-38014)

 

September 2024 Windows Updates brought a patch for CVE-2024-38014, a privilege escalation vulnerability in Windows Installer that could allow a local low-privileged attacker to execute arbitrary code as Local System user.

Security researcher Michael Baer with SEC Consult Vulnerability Lab found this vulnerability and reported it to Microsoft. Subsequently they also published an article detailing this vulnerability, which allowed us to create a micropatch for it.

 

The Vulnerability

This vulnerability is an addition to a series of Windows Installer security flaws that were found over the last few years (and patched by 0patch: [1, 2, 3, 4]). Most of these exploited the "repair" operation in one way or another, and so does this one. Its exploitability depends on a product being installed on the computer, whereby product's installer has to fulfill a number of conditions described in SEC Consult's article.

This vulnerability finally pushed Microsoft to create a patch that fixed not just this particular issue, but a whole class of issues that might result from non-admin users invoking the repair operation. After September 2024 update is applied, the repair operation on a product installed "for all users" requires administrative privileges. In case the user is a Windows administrator, the UAC (User Account Control) dialog is shown according to the computer's UAC policy, otherwise the user is prompted for administrative credentials. Note that a non-admin can still perform the repair operation on a product installed "for this user only" without administrative privileges. This makes sense, as such operation does not include privileged actions that could be exploited.

Microsoft's article describes the effects of the change: "When [Windows Installer] repairs an application, the User Account Control (UAC) does not prompt for your credentials. After you install this update, the UAC will prompt for them. Because of this, you must update your automation scripts. Application owners must add the Shield icon. It indicates that the process requires full administrator access. To turn off the UAC prompt, set the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer\DisableLUAInRepair registry value to 1. The changes in this update might affect automatic Windows Installer repairs."

Note that this fix also addresses a vulnerability in Windows Installer reported to Microsoft by Adrian Denkiewicz with Doyensec in December 2023, which Microsoft reportedly could not reproduce. This vulnerability also exploited the repair operation and the fact that some actions can be executed with elevated privileges, which a non-admin user could "hijack" to launch code as Local System.

Our Micropatch

Our micropatch is simpler but logically equivalent to Microsoft's: it requires administrative privileges for all repair operations on products installed "for all users".

The effect of this change is identical to that of Microsoft's patch (see above) but in contrast to reverting this change with a registry value, our patch can be disabled either locally via 0patch Console or remotely via 0patch Central if needed.

Here's the source code of our micropatch (note that in the title, the size of our micropatch is said to be "4 instructions", which is true for some Windows versions; this particular one for 32-bit Windows 10 v2004 only needed two instructions.)

;XX-2369
MODULE_PATH "..\AffectedModules\msi.dll_5.0.19041.1415_Win10-2004_32-bit_u2021-12\msi.dll"
PATCH_ID 1960
PATCH_FORMAT_VER 2
VULN_ID 7835
PLATFORM win32
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x1ddfb7
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msi.dll!0x1de0a1        
    code_start
        
        cmp eax, 0x2        ;check if the current operation is repair
        je PIT_0x1de0a1     ;if yes, jump to the block that enables UAC
       
    code_end
patchlet_end

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 11 v21H2 - fully updated
2. Windows 10 v21H2 - fully updated
3. Windows 10 v21H1 - fully updated
4. Windows 10 v20H2 - fully updated
5. Windows 10 v2004 - fully updated
6. Windows 10 v1909 - fully updated
7. Windows 10 v1809 - fully updated
8. Windows 10 v1803 - fully updated
9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
10. Windows Server 2012 (standard and R2) - fully udpated with no ESU
11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
    

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Michael Baer with SEC Consult Vulnerability Lab for sharing their analysis, which made it possible for us to create a micropatch for this issue. We'd also like to thank Adrian Denkiewicz with Doyensec for sharing their analysis, which allowed us to confirm that our patch also fixes the vulnerability they had found.

To learn more about 0patch, please visit our Help Center.