tekwizz123 (20)

Wrote up a full analysis of this bug in two parts at https://versprite.com/blog/security-research/cve-2019-1169-vulnerability-windows/. I believe that in reality CVE-2019-1169 actually covers several vulnerabilities, as if one looks at ZDI’s advisory at https://www.zerodayinitiative.com/advisories/ZDI-19-709/ they can see that one of the bugs covered by CVE-2019-1169 is actually an information leak.

My blog post covers this information leak which is exploitable by attackers who have some knowledge of how Windows messages work and how windows hooks and event hooks operate. Exploiting the vulnerability is only possible on Windows 7 x86 and prior as it is a NULL pointer dereference vulnerability, however successful exploitation results in the ability to read a DWORD worth of information at two arbitrary addresses in kernel memory per exploitation attempt.

I have also written up exploit code which will trigger this info leak vulnerability, which is available at https://github.com/VerSprite/research/tree/master/exploits/Ndays/CVE-2019-1169

This is a decent vulnerability that was found by István Kurucsai and Vignesh S Rao of Exodus Intelligence and was detailed at https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping/. Metasploit now has a fully working exploit for this vulnerability that grants RCE provided a user browses to an attacker controlled web page. However, as it stands the current module requires the sandbox to be disabled for its shellcode to work properly (see https://github.com/rapid7/metasploit-framework/pull/13008).

Overall its likely that most people will be automatically updating this vulnerabilty, however I will note that it is theoretically possible to make this bug easier to exploit by targeting older versions of the Windows OS such as Windows 7 and prior whereby exploiting a win32k bug may allow the attacker to go from running inside the Chrome render process to running as SYSTEM within the context of the Windows kernel. This is something that has been done in the past (see https://blog.exodusintel.com/2019/05/17/windows-within-windows/ for an example).

Note however that since newer versions of the Windows operating system introduced win32k system call filtering, which Chrome takes advantage of, unless an attacker has a vulnerability in some other core component accessible from the Chrome sandbox they wouldn’t be able to exploit this vulnerability. Whilst vulns still do exist, the reduction in the attack surface (since win32k is a primary source of privilege elevation vulnerabilities) does make this particular vulnerability a lot harder to exploit on modern Windows systems, however it may pose a higher threat for those organizations who are still running legacy systems in their environment.

Overall not a bad bug but unless paired with a sandbox escape bug on an older system, chances are that most people will either be up to date, or running on a system that limits their attack surface. Main target will likely be those running legacy systems were software updates aren’t as easily applied and/or as regular.

Analysis is available at https://github.com/afang5472/CVE-2020-0753-and-CVE-2020-0754/blob/master/WERReport-CVE-2020-0754/WERRaceCondition.docx although it doesn’t seem like the PoC code is available upon initial inspection.

This vulnerability is fairly similar to CVE-2020-0753 and results in arbitrary file deletion as the SYSTEM user should an attacker be able to create a symbolic link for a temporary file at the right time.

Vulnerabilty also exists within wersvc.dll, although the given function name is not provided within the writeup to the best of my knowledge.

A technical writeup for this bug was published today and is available at https://github.com/afang5472/CVE-2020-0753-and-CVE-2020-0754/blob/master/WERReport-CVE-2020-0753/POC.md along with a working PoC. The vulnerability itself exists within CWerService::SvcMergeETWLogs within Wersvc.dll according to the writeup.

From what I can see in the writeup the bug is a race condition which is relatively difficult to exploit, however because it is within the Windows Error Reporting Service it should be available by default on most Windows systems. Successful exploitation will result in arbitrary file deletion as the SYSTEM user.

Rated this as medium on exploitation as whilst it is a race condition, the fact that one is able to gain a 4-5 second window to exploit the bug by taking advantage of how the GetTempFileNameW() operation works. for generating the temp file name. Basically by prepopulating a directory with all file names from WER0000.tmp to WERFFFE.tmp (aka 0000 to FFFE), one forces GetTempFileNameW() to generate a file with the name WERFFFF.tmp.

Then following steps are executed (taken from writeup):

Then , I put all the WER***.tmp in \(pwd\1\, and junction \)pwd\2\ –> $pwd\1\;

we create a process to continuously trigger this function with the path \(pwd\2\. and create the other process to continuously execute the command SetOplock \)pwd\1\WERFFFF.tmp;

Once the Oplock is triggered , we junction \(pwd\2\ -> \RPC CONTROL\, and then create object symbolic \RPC CONTROL\WERFFFF.tmp -> \)target and \RPC CONTROL\WERFFFF.tmp.etl –> $target

Release the oplock , the target file will be deleted with system privilege

This is a vulnerability within NtGdiEnsureDpiDepDefaultGuiFontForPlateau() on Windows 10 which I wrote up an analysis of at https://versprite.com/blog/security-research/silently-patched-information-leak/. Originally I thought this was a silently patched bug, but Matt Miller corrected me on this (see https://twitter.com/epakskape/status/1215698153346744321) The bug occurs due to the fact that GreEnsureDpiDepDefaultGuiFontForPlateau() naturally leaks the value of the win32kbase!gahDpiDepDefaultGuiFonts pointer under certain conditions. which can allow attackers to potentially bypass KASLR under certain conditions.

To the best of my knowledge, this was fixed by Microsoft patching NtGdiEnsureDpiDepDefaultGuiFontForPlateau() so that it always returns 0 by adding an extra instruction which does:

xor eax, eax

This is shown in the screenshots in the article. As NtGdiEnsureDpiDepDefaultGuiFontForPlateau() was only added within Windows 10 v1709 (see j00ru’s system call list at https://j00ru.vexillium.org/syscalls/win32k/64/ and search for NtGdiEnsureDpiDepDefaultGuiFontForPlateau() ) , this bug is unique to Windows 10 hosts despite the fact that this CVE actually covers several related bugs (see Matt Millers comment on this at https://twitter.com/epakskape/status/1217189528806412288).

Wrote up a technical analysis of this bug for Exodus Intelligence at https://blog.exodusintel.com/2019/05/17/windows-within-windows/. The bug itself is relatively easy to trigger if you understand how Window messages work, but is a bit tricky to understand if your not familiar with this. Exploit reliability is high unless exploiting from the Chrome sandbox; in these scenarios it is still possible to exploit the target on older versions of Windows (Windows 7 and prior) however we did find that there was some interesting behavior going on with the Chrome sandbox escape shellcode as while it would disassociate the current process with the Chrome sandbox job (and henceforth the job’s limitations), it would occasionally trigger APC_INDEX_MISMATCH errors under certain conditions, particularly if the target user was an administrator.

TLDR: This exploit does takes a bit of knowledge of Win32k.sys and Windows internals to exploit, but provided an attacker has this knowledge, or has access to the public exploit, they can easily escalate their privileges to a SYSTEM user from any privilege level.