Google, Microsoft Work Together For a Year To Figure Out New Type of Windows Flaw

Google researcher James Forshaw discovered a new class of vulnerability in Windows before any bug had actually been exploited. The involved parts of the flaw '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,' reports Ars Technica. Thankfully, Microsoft said that the flaw was never actually exposed in any public versions of Windows, but said that it will ensure future releases of Windows will not feature this class of elevation of privilege. Peter Bright explains in detail how the flaw works. Here's an excerpt from his report: 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. As well as this security check, there's a second distinction made: calls from user mode require strict parameter validation to ensure that any memory addresses being passed in to the function represent user memory rather than kernel memory. Calls from kernel mode don't need that same strict validation, since they're allowed to use kernel memory addresses.

Accordingly, the kernel API used for opening files in NT's I/O Manager component looks to see if the caller is calling from user mode or kernel mode. Then the API passes this information on to the next layer of the system: the Object Manager, which examines the file name and figures out whether it corresponds to a local filesystem, a network filesystem, or somewhere else. The Object manager then calls back in to the I/O Manager, directing the file-open request to the specific driver that can handle it. Throughout this, the indication of the original source of the request -- kernel or user mode -- is preserved and passed around. If the call comes from user mode, each component should perform strict validation of parameters and a full access check; if it comes from kernel mode, these should be skipped. Unfortunately, this basic rule isn't enough to handle every situation. For various reasons, Windows allows exceptions to the basic user-mode/kernel-mode split. Both kinds of exceptions are allowed: kernel code can force drivers to perform a permissions check even if the attempt to open the file originated from kernel mode, and contrarily, kernel code can tell drivers to skip the parameter check even if the attempt to open the file appeared to originate from user mode. This behavior is controlled through additional parameters passed among the various kernel functions and into filesystem drivers: there's the basic user-or-kernel mode parameter, along with a flag to force the permissions check and another flag to skip the parameter validation...

Read more of this story at Slashdot.