Micropatches Released for Windows Workstation and Server Service Elevation of Privilege Vulnerability (CVE-2022-38034, CVE-2022-38045, No CVE)

 

 

October 2022 Windows Update brought fixes for two interesting vulnerabilities, CVE-2022-38034 and CVE-2022-38045. They allowed a remote attacker to access various "local-only" RPC functions in Windows Workstation and Windows Server services respectively, bypassing these services' RPC security callbacks. These vulnerabilities were found by Ben Barnea and Stiv Kupchik of Akamai who published a detailed article and provided a proof-of-concept tool.

We missed this publication back in 2022 (probably being busy patching some other vulnerabilities), but once we found it we confirmed that some of the legacy Windows versions that we had security-adopted were affected and decided to provide patches for them.

 

The Vulnerability

The vulnerability stems from the fact that older Windows systems, but also current Windows systems with less than 3.5GB of RAM, pack two or more services into the same svchost.exe process. Apparently this can be a problem; in our case, it enables both Workstation and Server Service - which normally don't accept authentication requests - to accept authentication requests when bundled up with another service that does. When that happens, the previously (remotely) inaccessible functions from these services become remotely accessible because successful authentication gets cached and is subsequently looked up without additional security checks.

Microsoft's Patch

Microsoft's patch effectively disabled said caching for both services. Patched versions of wkssvc.dll and srvsvc.dll contain updated flags that are passed to the RpcServerRegisterIfEx function when these service are initialized. The flags that were previously 0x11 (RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH | RPC_IF_AUTOLISTEN) have been replaced with 0x91 (RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH | RPC_IF_AUTOLISTEN | RPC_IF_SEC_CACHE_PER_PROC).

Our Micropatch

We could patch these vulnerabilities in wkssvc.dll and srvsvc.dll in exactly the same way Microsoft did, but that would require users to restart Workstation and Server services for the modified flags to kick in. (Remember that Windows updates make you restart the computer anyway, but we have higher standards than that and want our patches to come in effect without a restart.)

Therefore, we decided to place our patches in rpcrt4.dll, which gets loaded in all RPC server processes and manages the cache and security callbacks for every Windows RPC interface. Our patch sits in the RPC_INTERFACE::DoSyncSecurityCallback function that processes the cached values and decides whether to call the security callback or use the cached result. It first checks if it's running in the Workstation or Server Service process, and if so, simply forces the security callback.

Here's the source code of our micropatch.

;XX-1699
MODULE_PATH "..\AffectedModules\rpcrt4.dll_10.0.19041.1288_Win10-2004_64-bit_u2021-12\rpcrt4.dll"
PATCH_ID 1736
PATCH_FORMAT_VER 2
VULN_ID 7814
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x96ae2
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT rpcrt4.dll!0x4e0b4,kernel32.dll!GetModuleHandleW
           
    code_start
        
        call MODNAME1
        db __utf16__('wkssvc.dll'),0,0  ;load "wkssvc.dll" string
    MODNAME1:
        pop rcx                         ;pop the string into the first arg
        sub rsp, 0x20                   ;create the shadowspace
        call PIT_GetModuleHandleW       ;call GetModuleHandleW to check if wkssvc.dll is
                                        ;loaded in the current process
        add rsp, 0x20                   ;delete the shadowspace
        cmp rax, 0x0                    ;check if the call succeeded   
        jne PIT_0x4e0b4                 ;if success, we are in the Workstation Service process,
                                        ;so we block security callback caching by simulating
                                        ;the caching flag being disabled    
        call MODNAME2
        db __utf16__('srvsvc.dll'),0,0  ;load "srvsvc.dll" string
    MODNAME2:
        pop rcx                         ;pop the string into the first arg
        sub rsp, 0x20                   ;create the shadowspace
        call PIT_GetModuleHandleW       ;call GetModuleHandleW to check if srvsvc.dll is
                                        ;loaded in the current process
        add rsp, 0x20                   ;delete the shadowspace
        cmp rax, 0x0                    ;check if the call succeeded   
        jne PIT_0x4e0b4                 ;if success, we are in the Server Service process,
                                        ;so we block security callback caching by simulating
                                        ;the caching flag being disabled
    
    code_end
patchlet_end

 

While working on this patch we noticed that the Workstation Service security callback behaved differently on different Windows versions. On Windows 10 and later, the security callback blocks functions with numbers ("opnums") between 8 and 11 from being executed remotely, which is exactly what CVE-2022-38034 bypasses. However, on older Windows versions like Windows 7 up to ESU 2 (2nd year of Extended Security Updates), these functions are not blocked from remote access at all. For our CVE-2022-38034 patch to even make sense on these older versions of Windows, we therefore first needed to add the missing security callback checks to wkssvc.dll.

We were curious about the origin of these security checks and did some digging across different wkssvc.dll versions. We found they were added to the Workstation Service some time before April 2021 on Windows 10, and sometime after January 2022 on Windows 7, but we were unable to find any CVE references associated with them. Our best guess is that they were added silently, first on Windows 10 and almost a year later also on Windows 7.

Our patch for this CVE-less vulnerability behaves the same as Microsoft's. First, we get the caller's binding data,  then we check the opnum of the called function and determine whether the user is local or not. If the called opnum is between 8 and 11 and the caller is not local, we fail the call with "access denied" error. 

Micropatch Availability

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

1. Windows 10 v2004 - fully updated
2. Windows 10 v1909 - fully updated
3. Windows 10 v1809 - fully updated
4. Windows 10 v1803 - fully updated
5. Windows 7 - fully updated with no ESU, ESU 1 or ESU 2
6. Windows Server 2008 R2 - fully updated with no ESU, ESU 1 or ESU 2

 

  

Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent 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, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Ben Barnea and Stiv Kupchik of Akamai for sharing their analysis and proof-of-concept, which made it possible for us to create micropatches for these issues.

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