Unpatched kernel-level vulnerability affects all Windows versions

Discussion in 'other security issues & news' started by MrBrian, Aug 6, 2010.

Thread Status:
Not open for further replies.
  1. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    From http://www.theregister.co.uk/2010/08/06/unpatched_windows_kernel_vuln/:

     
  2. ParadigmShift

    ParadigmShift Registered Member

    Joined:
    Aug 7, 2008
    Posts:
    203
    I'd like to see the exploit in action.
     
  3. wrongway67

    wrongway67 Registered Member

    Joined:
    Apr 5, 2008
    Posts:
    45
    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/

     
  4. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
  5. wearetheborg

    wearetheborg Registered Member

    Joined:
    Nov 14, 2009
    Posts:
    667
  6. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Please see xxttp://ssj100.fullsubject.com/windows-hardening-f5/mis-understandings-about-privilege-escalation-exploits-t226.htm#1662
     
    Last edited by a moderator: Aug 7, 2010
  7. Eice

    Eice Registered Member

    Joined:
    Jan 22, 2009
    Posts:
    1,413
    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.
     
  8. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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 ;).
     
    Last edited: Aug 7, 2010
  9. wrongway67

    wrongway67 Registered Member

    Joined:
    Apr 5, 2008
    Posts:
    45
    http://www.computerworld.com/s/article/9180338/Microsoft_probes_new_Windows_kernel_bug?taxonomyId=85
     
  10. Eice

    Eice Registered Member

    Joined:
    Jan 22, 2009
    Posts:
    1,413
    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.
     
  11. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Off Topic: Why is SSJ100 not around anymore.
     
    Last edited by a moderator: Aug 7, 2010
  12. chronomatic

    chronomatic Registered Member

    Joined:
    Apr 9, 2009
    Posts:
    1,343
    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.
     
  13. Eice

    Eice Registered Member

    Joined:
    Jan 22, 2009
    Posts:
    1,413
    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.
     
  14. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  15. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
  16. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,833
    Kernel heap overflow

    So looks like it, doable maybe, but not today :p
     
  17. Greg S

    Greg S Registered Member

    Joined:
    Mar 1, 2009
    Posts:
    1,039
    Location:
    A l a b a m a
    Good question. I asked him the same question on another forum but even he doesn't know why
     
  18. wat0114

    wat0114 Guest

    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.
     
  19. Eice

    Eice Registered Member

    Joined:
    Jan 22, 2009
    Posts:
    1,413
    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.
     
  20. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
  21. wearetheborg

    wearetheborg Registered Member

    Joined:
    Nov 14, 2009
    Posts:
    667
    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).
     
  22. Eice

    Eice Registered Member

    Joined:
    Jan 22, 2009
    Posts:
    1,413
    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.
     
  23. wearetheborg

    wearetheborg Registered Member

    Joined:
    Nov 14, 2009
    Posts:
    667
    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.
     
  24. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Statement from Microsoft
     
Loading...
Thread Status:
Not open for further replies.