The patch released by Microsoft in March 2019 fixes two zero-day vulnerabilities in the wild Windows, where CVE-2019-0808 was discovered by Google Threat Analysis Team and submitted to Microsoft.
According to Microsoft, this vulnerability affecting Win32k components allows an attacker to elevate permissions and execute arbitrary code in kernel mode. Google said the vulnerability only affects Windows 7 and Windows Server 2008. Windows 10 will not be affected because Microsoft introduced vulnerability mitigation measures in the latest version of the operating system. But Windows 7 still has a certain percentage of users, and the vulnerability combined with Chrome RCE (CVE-2019-5786) has been used for real APT attacks, so it is very likely to be exploited to perform large-scale attacks and pose a real threat. Therefore,360 core security technology center constructs the POC by writing code, and some restoration of the vulnerability triggering process is performed, so that the security manufacturer can increase the corresponding protection measures.
- Causes of Vulnerability
After receiving the menu window object returned by the window procedure function, the xxxMNFindWindowFromPoint function does not effectively check the validity of its member tagPOPUPMENU, causing the subsequent MNGetpItemFromIndex function to trigger the zero pointer dereference vulnerability.
- Vulnerability triggering process
The main process is explained below.
Step 1: First, you need to set the whole message hook function to intercept the MN_FINDMENUWINDOWFROMPOINT message sent by xxxMNFindWindowFromPoint.
Step 2: Create a menu item with drag and drop functionality, and a special window handle hpwn for backup.
Step 3: Enter the NtUserMNDragOver function by dragging the menu or directly calling the relevant system call.
Step 4: The calling relationship is as follows: NtUserMNDragOver-> xxxMNMouseMove -> xxxMNFindWindowFromPoint, xxxMNFindWindowFromPoint will send the MN_FINDMENUWINDOWFROMPOINT message to the window and receive the returned window handle. Since the whole message hook function is set, the execution flow returns to the user layer.
Step 5: Since the window procedure function of the menu window is replaced before, the whole message hook function will enter the FakeWindowProc function after execution, and directly return the previously used window handle hpwn.
Step 6: After obtaining the window handle, the xxxMNFindWindowFromPoint function directly returns its corresponding window object and passes it to the xxxMNUpdateDraggingInfo function. It should be noted that the window object obtained here is immediately faked hpwn window object, its internal member tagPOPUPMENU is not set completely, most members are 0!
Step 7: After the xxxMNUpdateDraggingInfo function obtains the window object, it will access its member tagPOPUPMENU object through the MNGetpItem function.
The MNGetpItem function will continue to access the spmenu member of the tagPOPUPMENU object, causing a zero pointer dereference vulnerability.
03. Vulnerability patch
In the Windows 7 patch in March, Microsoft fixed the window type confusion (not NULL for the MENU type), and checked the state of the popupMenu object. The code comparison is as follows.
Before the patch:
After the patch:
- In Conclusion
Through the constructed POC, it is found that the cause of the vulnerability is that when the NtUserMNDragOver function is called in a specific case, the zero pointer dereference in win32k!MNGetpItemFromIndex is caused. The vulnerability uses the Windows kernel driver module win32k.sys to perform local authorization. After the authorization is successful, it can break through the restrictions of ordinary user rights, and can be used as a security sandbox to escape and completely control the user computer system.