Unpatched kernel-level vulnerability affects all Windows versions

From http://www.theregister.co.uk/2010/08/06/unpatched_windows_kernel_vuln/:

 

I'd like to see the exploit in action.

 

It's a "Local" problem: there already must be someone evil on your network

http://www.vupen.com/english/advisories/2010/2029

http://secunia.com/advisories/40870/

 

True, but if a remote attacker gets code to run on your system via some other manner, then it's a local problem that may matter.

 

How is "local" defined? Does it mean someone who is logged onto the system?
Can the attack not be used in drive by attacks?

 

Please see xxttp://ssj100.fullsubject.com/windows-hardening-f5/mis-understandings-about-privilege-escalation-exploits-t226.htm#1662

 

I don't see why it would. One of the cardinal rules of computer security is that once the attacker gets to run his code on your machine - local security hole or no local security hole - it's game over for you.

 

Let's assume we're running as a user with limited privileges. Certainly there are many bad things that code running with limited privileges can do. However, without privilege escalation or a poorly configured limited user account, other accounts on the system should not be affected, and malware autoruns can be spotted and removed easily.

Put another way, anybody who believes that statement shouldn't bother running as a limited user - just run as admin with UAC disabled .

 

http://www.computerworld.com/s/article/9180338/Microsoft_probes_new_Windows_kernel_bug?taxonomyId=85

 

Unless you're trying to suggest that a limited user account can and is supposed to prevent attacker code from executing, I'm afraid I don't quite follow your analogy, and what it has to do with the current scenario.

 

Off Topic: Why is SSJ100 not around anymore.

 

I think he is saying that the malicious code, if executed, will be running with the same permissions as the LUA, which means it cannot affect other accounts on the system, including system files (this is the whole point of LUA's in the first place). This is all part of the standard security model known as DAC.

Basically, it all just depends on what service/daemon is vulnerable and how it's exploited. Some attacks can be escalated from a user account to admin, giving the attacker total control. But generally, anything that happens in a LUA stays in a LUA -- it's a sandbox of sorts.

I am not familiar enough with this vuln to comment on its specifics. All I know is it's a heap vuln in some Windows kernel module, which means it would probably give the attacker admin access if exploited. I do know that "local user" does not necessarily mean the user has to be physically at the PC. It means anyone with a user account (or anyone who has cracked a user account). This obviously can be done remotely.

 

That's all well and good, but what I didn't quite grasp was the relevance of his analogy to the topic at hand. We know what a standard account and UAC does, but why does that mean we need to lose sleep over a vulnerability exploitable only by local users?

Depending on the details of this vulnerability, it possibly can, but attackers can't just magically reach into your machine to exploit this flaw. Which brings us back to my original point: in the absence of a remote vulnerability, it's a waste of time fretting over local vulnerabilities.

I believe you know this very well, chronomatic. You've argued as much in defense of Linux's local vulnerabilities in the past, if I remember correctly.

 

That indeed is what the article states. I believe it's incorrect though - the attacker doesn't have to be physically at the machine.

 

That's probably true - there probably would have to be another vulnerability exploited to be in a position to take advantage of this vulnerability.

The statement "if an attacker runs code on your machine, it's game over" is problematic IMHO. That statement would seem to imply that the only thing that matters is what code runs, not what the code is allowed to do if it runs. I'd strongly prefer that malicious code doesn't run at all, but if it does, I'd strongly prefer that the malicious code runs with limited privileges instead of unlimited privileges.

 

Kernel heap overflow

So looks like it, doable maybe, but not today

 

Good question. I asked him the same question on another forum but even he doesn't know why

 

Absolutely. No way will I pretend to be an expert, but in limited testing (20+ samples) of malware in a vm, I've seen what little damage it tends to only do in a standard account, making removal quite easy.

 

I'm curious to know why do you think it's "probably" true. Do you believe there's still a chance that this vulnerability is exploitable without another remote flaw to take advantage of first?

As you've admitted earlier, a full range of payloads is perfectly possible even within a standard account. So, yes, it would seem like once the attacker gets his code going, it's game over.

Of course, it depends on what you mean when you say "matters". If we're talking about infection, then yes, it's the only thing that matters. Restricting access privileges would only be relevant if you want to include post-infection cleanup in the overall picture as well.

 

Very unlikely - I added the "probably" because I didn't look at the specific details of this case closely.

Beyond just cleanup, there are other reasons I'd rather have an infection take place in a standard account vs. in an admin account:

• Other accounts are typically not affected, so for example that keylogger your kid got infected with in his standard account doesn't affect you when you're using your account.
• The likelihood of infection detection in a given amount of time should be higher compared to infection in an admin account, which would reduce the time you're exposed to the malware.
• Malware in a limited account can do plenty of bad things, but not as much as malware in an admin account.

 

Malware in a limited user account cannot change(**) the system. That is the big difference. If malware is allowed to change the system, things can get dicey; it can potentially make anti-malware software impotent (other than if booting from a anti-malware rescue cd). In the worst case, malware with admin privileges can completely fry your windows install. If there is malware with admin privileges, you cannot trust anything; as you are playing by the malware's rules.

**The exception is when malware in a LUA gains admin privileges. But this is not easy to do (but sometimes kernel level vulnerabilities do exist).

 

Fry the system? So what. Reinstalling Windows takes 20-30 minutes at most, 5 if you have a backup image. Not to mention that the malware writers get zero financial benefit out of ruining your OS. They've stopped caring about melting down your system a long time ago. In fact, it's counterproductive.

Your personal data is where the money is. They're what's going to cause you grief if you lose them, and they're what can be monetized by hackers. And UAC doesn't do anything to protect them, unfortunately.

 

In absense of a backup image, that is a severe understatement

That is true, kinda
Since damage is localised in LUA, this opens up a host of new defenses...eg create admin account, LUA-1 account, and LUA-2 account. Password protect LUA-1 directory.
--Use LUA-1 only for financial transactions.
--Admin account only for system maintainence.
--LUA-2 for all other browsing needs.

Such a setup would make is real hard for hackers to get hold of your financial data.

 

Statement from Microsoft