Slashdot Mirror
Google Security Expert Finds, Publicly Discloses Windows Kernel Bug
hypnosec writes "Security expert Tavis Ormandy has discovered a vulnerability in the Windows kernel which, when exploited, would allow an ordinary user to obtain administrative privileges of the system. Google's security pro posted the details of the vulnerability back in May through the Full Disclosure mailing list rather than reporting it to Microsoft first. He has now gone ahead and published a working exploit. This is not the first instance where Ormandy has opted for full disclosure without first informing the vendor of the affected software."
http://xkcd.com/1200/
History tells us that telling Microsoft privately puts it on their radar for three to five years out. Disclosing publicly actually gets a patch to users.
- Michael T. Babcock (Yes, I blog)
No, user level programs can't generally do that. Since Vista user privileges don't give access to other app's data or any system files. There is no easy way to steal credentials out of a browser or read email or anything like that.
That is why viruses often try to trick the user into granting them admin level permissions via a UAC warning prompt. In this case a way has been found to take those permissions without a prompt, giving the user a false sense of security and not alerting them to potentially dangerous behaviour.
As for drivers even a kernel level exploit usually won't be able to install them these days. Drivers need to be signed before Windows will allow them to be installed. On Windows 7 you can installed unsigned code after the user gives permission, but Windows 8 flat out refuses to install unsigned binaries as drivers.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
News? TFS is flamebait.
This Fucking Site?
The Friendly Summary.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
No, user level programs can't generally do that. Since Vista user privileges don't give access to other app's data
I'm sorry, but you are incorrect. Programs running under the same user's security context are all on equal footing and can inspect and interact with each other. Notepad could, for example, read the entire contents of Firefox's private memory. I can create a remote thread in the Firefox process to do whatever it pleased. Vista did not change this.
There is no easy way to steal credentials out of a browser or read email or anything like that.
This is also not true. Firefox clearly stores passwords using reversible encryption (how else could it send the plaintext passwords to websites?). Both the encrypted password and the decryption key is available to any program running under the user's context.
"Reading email" is a little vague, but if absolutely nothing else, a program could capture the text being displayed in the email application using any number of Win32 API / accessibility calls.
That is why viruses often try to trick the user into granting them admin level permissions via a UAC warning prompt
UAC does nothing to prevent a program from gaining adminstrative access (elevating). This has been reliably demonstrated many times by different people, and even Microsoft has said that UAC is not a security boundary. It was created (essentially) for one thing: to force software vendors to start writing programs that did not assume or require the user to have administrator rights. It had a positive side effect of making Microsoft look more focused on security.
As for drivers even a kernel level exploit usually won't be able to install them these days. Drivers need to be signed before Windows will allow them to be installed.
I'm sorry, but this is also incorrect. Keep in mind there are multiple meanings of a "driver", but once you are executing code inside kernelspace, all bets are off. As Raymond Chen likes to say, It rather involved being on the other side of this airtight hatchway.
Windows 8 flat out refuses to install unsigned binaries as drivers
That's unfortunate for independent/small software development shops and open-source software projects. I remember when I had control over what ran on my computer; those were good days. If, however, malicious code has found its way into the kernel your machine is still fully compromised.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
But for corporate users, a system level exploit allows things like installing sniffers and key loggers so that more passwords can be collected. Including the admin/root passwords.
Absolutely. What takes it to the next level is that most (effectively all) Windows sysadmins will log into workstations using their user credentials which are members of the Domain Admins group. If a standard user is able to gain administrative access on their computer and then get a sysadmin to log in to "look at a problem" (very easy), they will likely gain full control over the local domain. This includes the ability to distribute a malicious binary over the network to every computer in the domain, allowing them to collect personal credentials and information from every other person in the company.
Even without getting a Domain Admin to log into their workstation, there is potential for other security problems. For example, the user might extract the hashed passwords stored in the active directory credential cache which likely contains an entry for a Domain privileged user. They could then attempt brute force decryption on this (salted and hashed) cached password. With modern GPU farms such brute force attacks aren't as crazy as they used to be, especially if the password is weak.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Firstly getting in at that level is hard. The kernel is not monolithic, and the different parts have different permissions. That's why you don't see many viruses that actually do that any more - all the attack vectors that are exposed are for stuff that runs outside the core kernel level we are talking about.
It is typically hard, but this exploit runs at ring-0.
Even if you can get in at that level it still isn't easy to just install your driver. The driver management code won't accept unsigned code even from the inner kernel. You would have to replicate those routines yourself and patch it directly into the driver system. Bypassing the driver loading system, as you say. Hardly trivial.
I don't think you understand what it means to "install your driver". I'm not talking about adding a .dll and .inf file, I'm talking about actually executing driver/shellcode in the kernel. This exploit executes code in ring-0 which gives full access to the kernel memory, hardware, OS, filesystem, registry... everything. There is no need to bypass anything. You've already "installed the driver" and anyone with the skill to exploit a kernel vulnerability will have no trouble overwriting the crypto check function in program space with a "return success" stub. Since this attack does not require the exe to be signed, it can permanently install itself by adding a startup entry in the registry. SecureBoot won't protect against that.
What SecureBoot does protect against is some malware permanently installing itself on the system /after/ the OS has been patched.
Asymmetric keys are merely *better* obscurity than most other means.
You are using a false information model.
"Obscurity" in the context of IT security does not refer to private information of any kind.
"Security through Obscurity" refers to the false assumption that my ROT13 encryption algorithm is any better if I don't tell you that I'm using ROT13. The assumption being that it'll take you additional time to figure out what algorithm I'm using, making it more difficult to crack my code.
That assumption is false, because with any actual security measure, the amount of work required to figuring out the algorithm is insignificant compared to the amount of work required to break it.
Asymmetric keys are not "better" obscurity. You can't break a good encryption algorithm with even a huge cluster. That's the whole point - that I don't need obscurity. I can tell you what algorithm I used, what size my key is, absolutely everything except the key itself - and it'd still take you a century with all the current computing power on the planet to break it.
Obscurity is usually a weak algorithm that can be broken in minutes once you've figured out the one "trick" they keep secret.
If you still don't see the difference, re-read Applied Cryptography.
Assorted stuff I do sometimes: Lemuria.org