Enlarge (credit: Marco Verch / Flickr)
One of the more notable features of Google Project Zero’s (GPZ) security research has been its 90-day disclosure policy. In general, vendors are given 90 days to address issues found by GPZ, after which the flaws will be publicly disclosed. But sometimes understanding a flaw and developing fixes for it takes longer than 90 days—sometimes, much longer, such as when a new class of vulnerability is found. That’s what happened last year with the Spectre and Meltdown processor issues, and it has happened again with a new Windows issue.
Google researcher James Forshaw first grasped that there might be a problem a couple of years ago when he was investigating the exploitability of another Windows issue published three years ago. In so doing, he discovered the complicated way in which Windows performs permissions checks when opening files or other secured objects. A closer look at the involved parts showed that there were all the basic elements to create a significant elevation of privilege attack, enabling any user program to open any file on the system, regardless of whether the user should have permission to do so. The big question was, could these elements be assembled in just the right way to cause a problem, or would good fortune render the issue merely theoretical?
The basic rule is simple enough: when a request to open a file is being made from user mode, the system should check that the user running the application that’s trying to open the file has permission to access the file. The system does this by examining the file’s access control list (ACL) and comparing it to the user’s user ID and group memberships. However, if the request is being made from kernel mode, the permissions checks should be skipped. That’s because the kernel in general needs free and unfettered access to every file.