The fourth horseman: CVE-2019-0797 vulnerability

In February 2019, our Automatic Exploit Prevention (AEP) systems detected an attempt to exploit a vulnerability in the Microsoft Windows operating system. Further analysis of this event led to us discovering a zero-day vulnerability in win32k.sys. We reported it to Microsoft on February 22, 2019. The company confirmed the vulnerability and assigned it CVE-2019-0797. Microsoft have just released a patch, crediting Kaspersky Lab researchers Vasiliy Berdnikov and Boris Larin with the discovery:

This is the fourth consecutive exploited Local Privilege Escalation vulnerability in Windows we have discovered recently using our technologies. Just like with CVE-2018-8589, we believe this exploit is used by several threat actors including, but possibly not limited to, FruityArmor and SandCat. While FruityArmor is known to have used zero-days before, SandCat is a new APT we discovered only recently. In addition to CVE-2019-0797 and CHAINSHOT, SandCat also uses the FinFisher/FinSpy framework.

Kaspersky Lab products detected this exploit proactively through the following technologies:

1. Behavioral detection engine and Automatic Exploit Prevention for endpoint products;
2. Advanced Sandboxing and Anti Malware engine for Kaspersky Anti Targeted Attack Platform (KATA).

Kaspersky Lab verdicts for the artifacts used in this and related attacks are:

• HEUR:Exploit.Win32.Generic
• HEUR:Trojan.Win32.Generic
• PDM:Exploit.Win32.Generic

Brief technical details – CVE-2019-0797

CVE-2019-0797 is a race condition that is present in the win32k driver due to a lack of proper synchronization between undocumented syscalls NtDCompositionDiscardFrame and NtDCompositionDestroyConnection. The vulnerable code can be observed below on screenshots made on an up-to-date system during initial analysis:

Snippet of NtDCompositionDiscardFrame syscall (Windows 8.1)

On this screenshot with the simplified logic of the NtDCompositionDiscardFrame syscall you can see that this code acquires a lock that is related to frame operations in the structure DirectComposition::CConnection and tries to find a frame that corresponds to a given id and will eventually call a free on it. The problem with this can be observed on the second screenshot:

Snippet of NtDCompositionDestroyConnection syscall inner function (Windows 8.1)

On this screenshot with the simplified logic of the function DiscardAllCompositionFrames that is called from within the NtDCompositionDestroyConnection syscall you can see that it does not acquire the necessary lock and calls the function DiscardAllCompositionFrames that will release all allocated frames. The problem lies in the fact that when the syscalls NtDCompositionDiscardFrame and NtDCompositionDestroyConnection are executed simultaneously, the function DiscardAllCompositionFrames may be executed at a time when the NtDCompositionDiscardFrame syscall is already looking for a frame to release or has already found it. This condition leads to a use-after-free scenario.

Interestingly, this is the third race condition zero-day exploit used by the same group in addition to CVE-2018-8589 and CVE-2018-8611.

Stop execution if module file name contains substring “chrome.exe”

The exploit that was found in the wild was targeting 64-bit operating systems in the range from Windows 8 to Windows 10 build 15063. The exploitation process for all those operating systems does not differ greatly and is performed using heap spraying palettes and accelerator tables with the use of GdiSharedHandleTable and gSharedInfo to leak their kernel addresses. In exploitation of Windows 10 build 14393 and higher windows are used instead of palettes. Besides that, that exploit performs a check on whether it’s running from Google Chrome and stops execution if it is because vulnerability CVE-2019-0797 can’t be exploited within a sandbox.