Google, Microsoft Work Together For a Year To Figure Out New Type of Windows Flaw (arstechnica.com) 53
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...
Is anybody surprised? (Score:5, Insightful)
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.
kernel defined (Score:4, Funny)
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.
Permission bits explained (Score:3)
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.
Re: Permission bits explained (Score:1)
Tootsie rolls are all soft core. You meant to describe a Tootsie Pop, with a hard sugar-candy sucker shell over a Tootsie Roll center.
Re: (Score:3)
My bad. Right you are. Especially the rootbeer flavored candy shells. Mmmmmm
Re: (Score:2)
Re: Is anybody surprised? (Score:1)
Microsoft has always had security inside out. They began as a company intending to break the grip of the white-coated Computer Operators of old. Computers for everyone, no central control. Power for whomever has the hardware on their desk. This was liberating and made the surly old guard of Computer Operators upset.
Microsoft extended their influence with their open design philosophy that any software written for their system should continue to work on later versions of their system. This sort of open design
Re: Is anybody surprised? (Score:1)
Stallman and his friends refused to put passwords on their accounts.
Cough... setuid root.... cough (Score:2)
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.
.
Re: (Score:2)
Google, Microsoft Work Together
I'm surprised enough that I almost spit tea all over my monitor.
Re: (Score:2)
It could have just been in search of performance, like when they merged the Kernel and graphics memory spaces in NT4 (which had been separate in NT3.51) in pursuit of graphics performance.
Re: (Score:2)
MS makes utterly stupid decision, different from what anybody competent has done before for this task, insecurity ensues. Nobody with a clue is surprised.
Re: (Score:2)
Maybe. This is a common type of bug that was prevalent in UNIX and Linux distributions a decade or so ago. Many bugs were found along a similar permissions boundary such as setuid and sudo. There have also been many privilege escalations connected to drivers and their interactions with user space calls with their APIs.
As long as we continue to allow security researchers to do their work without legal trouble we can slowly root these out or at least make the findings so expensive it will be hard for criminal
Re: So basically... (Score:1)
Does anybody even bother to read this crapflooding? It's just noise, to route around like dog feces on the sidewalk.
"various reasons" (Score:3)
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?
Re: (Score:2)
They also broke it by not switching to the secure desktop to take inputs. Granted for malware to take advantage and be able to actually send events to the UAC window; it pretty much has to have elevated already but still... The Vista solution was more secure if more annoying. Microsoft gets into trouble because they make some many exceptions to their own rules.
As you point out with the auto-elevate of their own stuff (also all their own stuff is allowed by default applocker configs) they move the security
Re: "Leaky abstraction" (Score:2)
âoeVarious reasonsâ are bugs in the drivers. Itâ(TM)s quite clear in the article.
Security flaw by design... (Score:2)
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.