Known as WizardOpium for its use in the WizardOpium attacks, and first written about by Kaspersky Labs. The writeup by Kaspersky Labs can be found at https://securelist.com/windows-0-day-exploit-cve-2019-1458-used-in-operation-wizardopium/95432/ which shows that this vulnerability was used in conjunction with CVE-2019-13720, which was a 0day in the Chrome browser at the time that occurred due to a race condition between two threads.

In the WizardOpium attacks, the Chrome vulnerability, aka CVE-2019-13720, was first used to gain an arbitrary read/write primitive in the Chrome render process that lead to arbitrary code execution as the Chrome render (read more on this at https://bugs.chromium.org/p/chromium/issues/detail?id=888923 if your interested). However this still left attackers with a problem: they needed some way to escape the Chrome render’s sandbox if they wanted to get persistent access to the target.

This is where CVE-2019-1458 came in. Looking at the advisory at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1458 we can see this vulnerability affected quite a wide range of targets, going all the way from Windows 7 up to Windows 10 v1607. Later versions of Windows 10 are not affected, however.

If one dives around the internet a little bit more though they will stumble across https://googleprojectzero.blogspot.com/p/rca-cve-2019-1458.html which was written by the Project Zero team at Google which explains the vulnerability quite well. In essence there is a Uninitialized Variable error in Windows within its Windows Switching code whereby the field *(gpsi + 0x154) in the global structure tagSERVERINFO, which describes system windows (such as menus, desktops, switch windows, etc), which was not properly initialized at the start of a function, which allowed user mode code to set extra window data in a task switch window of Window class FNID_SWITCH, or 0x280, which can normally only be set by the kernel. Even worse though is the fact that this extra window data is essentially a pointer which is then dereferenced and then written to, which grants the attacker a limited arbitrary write primitive in kernel mode, which then can then use to perform limited controlled writes to kernel memory and take over the system. Attackers then used this limited kernel write primitive to overwrite their current process’s access token value with the value of the SYSTEM process’s access token value, thereby allowing them to execute code as SYSTEM.

If one then looks at https://github.com/piotrflorczyk/cve-2019-1458_POC, which does a deep technical dive into all of the details of this vulnerability, one can see that the affected function was InitFunctionTables() within win32k.sys, which didn’t appropriately initialize the fields *(gpsi+0x14E), *(gpsi+0x154), and *(gpsi+0x180), despite initializing other fields within the same structure. Microsoft’s patch ensured that these fields were all set up and initialized with appropriate values at the start of the InitFunctionTables() call, thus preventing this issue from occurring.