Microsoft Windows Remote Kernel Crash Vulnerability

At the end of January 2018, the FortiGuard Labs team discovered a remote kernel crash vulnerability in Microsoft Windows and reported it to Microsoft by following Fortinet’s responsible disclosure process. On June 12, Microsoft released an advisory that contains the fix for this vulnerability and identifies it as CVE-2018-1040.

This kernel crash vulnerability exists in the Microsoft Windows Code Integrity Kernel Module “ci.dll”. All popular Windows versions are affected, including Windows 10, Windows 7, Windows 8.1, Windows Server 2008, Windows Server 2012, and Windows Server 2016.

The vulnerability I discovered can be triggered by remotely downloading a crafted .dll or .lib file on Windows from a website or SMB share. When using IE or Edge to download the file and save it, a Windows kernel pointer dereference to an invalid address is executed. As a result, a Windows Bugcheck (Kernel crash) occurs. On Windows 10, after the system is rebooted, a kernel crash occurs when users login it. This results in the Windows 10 kernel crashing in a loop.

In this blog, I want to share my detailed analysis of this vulnerability.

Analysis

To reproduce this remote kernel crash vulnerability, you can open IE or Edge on Windows 10, enter the url http://192.168.0.111/poc.dll (it can be any url where the PoC file is hosted), then choose “save” in the pop-up window. When the file poc.dll is saved, you can see that Windows 10 bugcheck (kernel crash) occurs as a result. For the kernel crash in Windows 10, the kernel crash continues to occur even if it’s rebooted, which results in Windows 10 not working any more. For users, the system may need to be re-installed.

Following is the call stack when the crash occurs.

From the above call stack output, we can see that the kernel crash occurs when calling the function “KERNELBASE!GetFileVersionInfoSizeExW”, which then calls the function “KERNELBASE!LoadLibraryExW”. Finally, it results in a complete kernel crash.

When IE/Edge downloads a .dll or .lib file and saves on disk, it will call the function “KERNELBASE!GetFileVersionInfoSizeExW” to retrieve the .dll/.lib version information. To get the .dll/.lib version information, it then calls the function “KERNELBASE!LoadLibraryExW” to load the .dll/.lib file with dwFlags equaling 0x22. Searching in Microsoft MSDN, we can see that dwFlags 0x22 is the combination of “LOAD_LIBRARY_AS_DATAFILE(0x00000002)” and “LOAD_LIBRARY_AS_IMAGE_RESOURCE(0x00000020)”. So IE/Edge loads the downloaded .dll/.lib file as a resource .dll/.lib and data file to retrieve related info. Due to the crafted poc.dll, after the kernel crash in Windows 10 occurs, even rebooting can’t restore the system. This is because the .dll/.lib file in IE/Edge temporary directory is scanned when users login Windows.

The function LoadLibraryExW loads the crafted PoC file poc.dll. When it deals with SizeOfHeaders, it gets a crafted size of 0x06 (the correct size is 0x200). This results in an integer overflow when calculating the sha1 hash block size in the function CI!CipImageGetImageHash in CI.dll. The overflowed block size is 0xfffffeb6. With the overflowed block size 0xfffffe7a, which is obtained after calculation, calling the function CI!SymCryptSha1AppendBlocks—due to the overlarge crafted sha1 block size—results in a large loop and a kernel memory read access violation. As a result, a Windows bugcheck (kernel crash) occurs.

By reverse engineering and tracing, we can see that the call of the function _CipImageGetImageHash results in a sha1 block size integer overflow.

With the overflowed sha1 block size, it finally calls the following function:    

From the above analysis, we can see that the root cause of the remote kernel crash is that the function LoadLibraryEx fails to correctly parse a crafted .dll/.lib file as resource and data file. When the poc.dll includes a crafted SizeOfHeaders value 0x06 (the correct value should be 0x200) which is located at offset 0x104 in the PoC file, an integer overflow occurs.

The crafted size value results in a wrong sha1 block size being calculated (it becomes a negative value). Due to an insufficient bounds check, the sha1 calculation function enters a large loop, which results in a memory read access violation. Finally, the system bugcheck (kernel crash) occurs

Solution

All users of vulnerable Microsoft Windows are encouraged to upgrade to the latest Windows version or apply the latest patches. Additionally, organizations that have deployed Fortinet IPS solutions are already protected from this vulnerability with the following signature:

MS.Windows.Code.Integrity.Module.DoS

 



Check out our latest Quarterly Threat Landscape Report for more details about recent threats.

Sign up for our weekly FortiGuard intel briefs or for our FortiGuard Threat Intelligence Service.



*** This is a Security Bloggers Network syndicated blog from Fortinet All Blogs authored by Fortinet All Blogs. Read the original post at: http://feedproxy.google.com/~r/fortinet/blogs/~3/R2Vwa5LC4zI/microsoft-windows-remote-kernel-crash-vulnerability.html