Friday, June 26, 2020

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




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.

Tuesday, June 16, 2020

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


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.

Wednesday, May 27, 2020

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




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.
  
 









Wednesday, May 20, 2020

Micropatching PrintDemon Vulnerability (CVE-2020-1048)


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.

Thursday, March 26, 2020

Micropatching Unknown 0days in Windows Type 1 Font Parsing

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 sales@0patch.com 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













Friday, February 21, 2020

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

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 support@0patch.com!)

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 (support@0patch.com) 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






Monday, February 10, 2020

Letter To 0patch Users (February 10, 2020)


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