Today I’ll discuss yet another way to bring the Windows operating system down from the context of an unprivileged user, in a 5th and final post in the series. It hardly means that this is the last way to crash the kernel or even the last way that I’m aware of, but covering these bugs indefinitely could soon become boring and quite repetitive, so I’ll stop here and return with other interesting material in the near future. Links to the previous posts about Windows DoS issues are listed below:
- Windows Kernel Local Denial-of-Service #4: nt!NtAccessCheck and family (Windows 8-10)
- Windows Kernel Local Denial-of-Service #3: nt!NtDuplicateToken (Windows 7-8)
- Windows Kernel Local Denial-of-Service #2: win32k!NtDCompositionBeginFrame (Windows 8-10)
- Windows Kernel Local Denial-of-Service #1: win32k!NtUserThunkedMenuItemInfo (Windows 7-10)
The bug explained today can be found in the
win32k!NtGdiGetDIBitsInternal system call, which has been around since the very early days of Windows existence (at least Windows NT). The syscall is used by the GetDIBits, BitBlt and StretchBlt documented API functions, and has been recently subject to patching in Microsoft’s April Patch Tuesday, in order to fix an unrelated double-fetch vulnerability reported by Project Zero (CVE-2017-0058, issue #1078 in the tracker). The DoS problem was also reported to the vendor at that time, but due to its low severity, it didn’t meet the bar for a security bulletin.