Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

To handle devices on which drawing can be performed (pixel-based devices), Windows provides so-called device contexts (DCs). Device contexts are an abstraction of the user-mode and low-level drivers that actually perform the actions for rendering on the screen, such as pens, brushes, bitmaps and so on.

Bitmaps are rendered as surface objects in Windows. The hdev value of a bitmap is used as a handler to point to an object in physical memory, being a device object. Gaining control over this value would spell havoc!

Prior to Windows 2000, printer and screen drivers were in the kernel. But, because vendors were making horrible drivers that were riddled with security issues, the printers were stuck into user mode. Still though, a fair amount of printer functionality still exists in the kernel that just points back to user mode functions. Sometimes, there are differences between the two!

By calling one of the kernel functions instead of the user mode functions we are able to control values that we normally cannot control. In this case, we have control over the dhpdev and flags when calling SelectObject or EngAssociateSurface in the kernel world. dhpdev can either point to kernel memory or user space memory when passed into this function.

When GDI graphics are used, there are two code paths that can be taken: the known path and the generic implementation, which is taken via the flags field to call a specific list of allowed functions. By mixing and matching the kernel and user space API calls, we can get the program into a state where the dhpdev is desynced from the expectation. Instead of pointing to a pointer in the kernel it now points to user-mode memory.

This is a really interesting type confusion bug! We control a pointer to data that we should not be able to directly control. Using this bug, we can trick the display driver into overwriting arbitrary kernel memory by passing in a malicious dhpdev block. There are some tricky requirements that are specific to Windows and the subsystem (so, I won't go into it).

The rest of the article is about creating a malicious dhpdev block that allows for compromise of the kernel. The other interesting thing about the article though is the fix for the bug. Microsoft added a function called win32kbase.sys!bIsSurfaceAllowedInDC to check for this exact case of events. Seems like a brittle fix to me.

Great research and a lot of background on this part of the Windows OS. Type confusion/logic bugs are always fascinating to me because it is using the system in an extremely unintended but just barely valid way.