Slashdot Mirror
Google, Microsoft Work Together For a Year To Figure Out New Type of Windows Flaw (arstechnica.com)
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...
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...
So Kernel mode privileges need to be limited to the Kernal and not userland. Gee. Security mind blown!
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
Telemetry needs it, I suspect is 90% of the various reasons.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
....the code is a mess.
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.
IIRC, Microsoft broke UAC long ago by allowing its own software to "auto-elevate" without asking. Are those the kind of reasons we're talking about?
- J K R
*gets popcorn*
kernel /krnl/
noun: kernel;
plural noun: kernels
A softer, usually edible part of a nut, seed, or fruit stone contained within its hard shell.
In computer science this refers to the inner composition of edibles found in vending machines, such as the filling in a twinkie. For example, in an M&M peanut candy the peanut is the Kernel, and the candy coating it the usermode.
Kernel's are not always nuts, in computer science, For example, In raisenets the raisin is the kernel and imiatation choclate coating is the userland.
Some drink at the fountain of knowledge. Others just gargle.
An example of permission bits in computer science vending machine food is the tootsie roll. The operating system specifies that the user may not access the tootsie roll center in less than ten licks but there's nothing that stops a rogue driver from biting it after three licks.
Some drink at the fountain of knowledge. Others just gargle.
Gates would have found it a long time ago, fixed it himself, and gone to every customer personally to apologize and comp the license of their choice. Just sayin
This is called a leaky abstraction. Clearly the design is to separate the privileges of usermode from the privileges of the kernel, but for "various reasons" this abstraction isn't maintained. Things that shouldn't be in the kernel are there for performance reasons. Things that should be in the kernel are probably delegated to usermode for flexibility. Thus the workarounds begin and as usual functionality > security. Holes are punched into the separation of privileges.
I suspect that the impending EOL of standard win7 is a larger part of that 90%. There was very little 'meat' in the OP. More like a loud worldwide suggestion/enticement/challenge to malware creators. The end result is to force people to 'upgrade'. The newest windows are not vulnerable...wink.
Reminds me of this: accessing user-space data from the kernel is tricky. It's good to see they're working harder to resolve this issue, regardless of the OS.
âoeThe kernelâ should be âoea kernelâ and should, with a few limited exceptions, only have access via hardware/software/mathematically-enforced controls to anything. Itâ(TM)s ridiculous that for mainstream OSâ(TM)s you still basically have to trust your software AND the OS and hardware. Weâ(TM)ve known for a few decades how to fix this.
Maybe linux has a few ACL shortcuts too?
Apple made the same mistake with their dynamic log files which had the root execution privs even when run as user.
.
Some drink at the fountain of knowledge. Others just gargle.
Fox and weasel coop management, discover new method of protecting chickens from hawks- news at 11.
...spend all that time figuring out how to make a flaw?
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.
That's moronic. Even the kernel should respect file permissions. It should always be able to CHANGE the permissions (because the permissions are not part of the file but of the file system), but if a file is not 'x' the kernel should not treat it as executable, and if it is not 'r' it should not be readable.