Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Windows Bug Microsoft Security Technology

Newly-Found Windows Bug Affects All Versions Since NT 393

garg0yle writes "A researcher has found a security bug that could allow privilege escalation in Windows. Nothing new there, right? Well, this affects the Virtual DOS Machine, found in every 32-bit version of Windows all the way back to Windows NT. That's 17 years worth of Windows and counting. 'Using code written for the VDM, an unprivileged user can inject code of his choosing directly into the system's kernel, making it possible to make changes to highly sensitive parts of the operating system. ... The vulnerability exists in all 32-bit versions of Microsoft OSes released since 1993, and proof-of-concept code works on the XP, Server 2003, Vista, Server 2008, and 7 versions of Windows, Ormandy reported.'"
This discussion has been archived. No new comments can be posted.

Newly-Found Windows Bug Affects All Versions Since NT

Comments Filter:
  • by Jesterace ( 914041 ) on Wednesday January 20, 2010 @11:24AM (#30832276) Homepage
    Well the article says that Microsoft was notified of this bug June 2009. Guess they feel it isn't that big of a threat if they haven't patched it as of yet. But then again that's nothing new. Guess I'm glad I run 64bit.
  • by Attack DAWWG ( 997171 ) on Wednesday January 20, 2010 @11:26AM (#30832294)
    Hmm . . . cue the Microsoft apologists in even less time than that, I guess.
  • Is this a hole nobody knew about or a hole nobody but the people who knew about it knew about, and those people weren't talking?

    Well we don't really know do we?

  • by recoiledsnake ( 879048 ) on Wednesday January 20, 2010 @11:30AM (#30832338)

    This is the cost of backward compatibility at the expense of everything else. That is what made Microsoft and that is what may break it.

  • by clarkn0va ( 807617 ) <apt,get&gmail,com> on Wednesday January 20, 2010 @11:31AM (#30832364) Homepage
    Recent events seem to suggest that the biggest threats, from MS's point of view, are media exposure and public opinion. The fact that this has now appeared on /. and other media outlets means it will likely be patched in the coming month or so; sooner if people get really loud about it.
  • by sys.stdout.write ( 1551563 ) on Wednesday January 20, 2010 @11:34AM (#30832396)

    This is the cost of backward compatibility at the expense of everything else. That is what made Microsoft and that is what may break it.

    Yeah, people hate it when their applications continue to work after buying a new computer.

  • by Anonymous Coward on Wednesday January 20, 2010 @11:42AM (#30832534)

    The difference here is that anybody can audit or fix the Linux code, and many people and organisations have and do. So yeah, you're safer using Linux than Windows in that regard.

    Like all those people auditing the change to the SSL code made by that Debian maintainer before it was committed? Oops...

  • by Anonymous Coward on Wednesday January 20, 2010 @11:44AM (#30832558)

    This is the cost of backward compatibility at the expense of everything else. That is what made Microsoft and that is what may break it.

    Yeah, people hate it when their applications continue to work after buying a new computer.

    That's the "what made Microsoft" part.

    The "what may break [Microsoft]" part: Backwards compatibility with something that sucks, sucks.

  • by zookeeperme ( 1722156 ) on Wednesday January 20, 2010 @11:56AM (#30832776)
    Anyone still running only 32-bit Windows deserves the vulnerability. This is just one more reason why people should be upgrading to 64-bit.
  • by PitaBred ( 632671 ) <slashdot&pitabred,dyndns,org> on Wednesday January 20, 2010 @12:02PM (#30832880) Homepage

    The difference is how much faster it was fixed once it was discovered, and how much less work and money that it takes to run a new version of Linux. Switching from a vulnerable Win2K or NT to 7 is a VERY costly endeavor. Switching to a new version of Linux is not nearly as big of an undertaking.

  • by plague3106 ( 71849 ) on Wednesday January 20, 2010 @12:03PM (#30832890)

    Except that as those exploits prove, people AREN'T auditing the code. Otherwise, how would they end up in the wild?

  • by flerlerp ( 447410 ) on Wednesday January 20, 2010 @12:11PM (#30833038)

    This isn't a "Newly-found" bug. It was discoverd and reported to Microsoft on 12-Jun-2009. Not sure what's worse: An OS vendor whom doesn't patch holes quickly or a blog editor whom is clueless and uses inaccurate headlines to waste readers time.

  • by snemarch ( 1086057 ) on Wednesday January 20, 2010 @12:17PM (#30833130)

    Good luck auditing even such a "limited" part as the kernel, even if you've got a full team of people - claiming that any individual could audit an entire distro is lunacy.

    And it's not like serious bugs haven't had long timespans in linux before they were discovered; probably not any that were present as long as the NTVDM bug :), but still - shows that having the ability to audit the code doesn't help _that_ much if nobody are actually doing it.

  • Not "Newly-Found" (Score:5, Insightful)

    by Len ( 89493 ) on Wednesday January 20, 2010 @12:18PM (#30833162)

    Microsoft was informed about this vulnerability on 12-Jun-2009, and they confirmed receipt of my report on 22-Jun-2009. Regrettably, no official patch is currently available. As an effective and easy to deploy workaround is available, I have concluded that it is in the best interest of users to go ahead with the publication of this document without an official patch.

    from Tavis Ormandy's disclosure [neohapsis.com]

    So the bug was found six months ago, but Microsoft only decided it was serious enough to fix after it was publicized. Seems like another case of "responsible disclosure" being used to cover up a vulnerability, instead of fixing it (or publishing a workaround) before the bad guys find out about it.

  • by X0563511 ( 793323 ) on Wednesday January 20, 2010 @12:31PM (#30833414) Homepage Journal

    Yes, exactly. You will notice that that error was found and corrected fairly quickly, and didn't rot around for almost two decades...

  • by daveime ( 1253762 ) on Wednesday January 20, 2010 @12:37PM (#30833518)

    I have a 32 bit processor on a 32 bit motherboard and 2GB of DDR2.

    Why in fucks name would I want 64 bit OS to do the same thing as I can do with a 32 bit OS, and mores to the point, why do *I* deserve crappy code written by someone else ?

    You don't *have* to upgrade just because "it's the latest thing". And saying 64 bit is somehow better when it can't even run the same legacy code that 32 bit still can is hardly a valid reason to upgrade. (The fact that some of that legacy code is vulnerable is beside the point).

  • by tacarat ( 696339 ) on Wednesday January 20, 2010 @12:38PM (#30833538) Journal
    So it's not Windows vs Linux security, but a Closed vs Opens source security discussion.
  • by dpilot ( 134227 ) on Wednesday January 20, 2010 @12:42PM (#30833610) Homepage Journal

    Elsewhere in this thread there are comments like, "Just because it can be audited doesn't mean that it is," etc. Those comments are to a true, to a certain extent. Certainly long-hiding bugs have been found in the Linux kernel and software.

    But there is one other factor at work, here. I've spent a few decades in the corporate world, and I can guarantee that the first response will be political/legal. Technical issues will come later. Let's say that Joe Coder-in-the-trenches finds a lurking bug in the source code that can be exploited. He reports it, and it starts moving up the management chain, probably gaining urgency as it goes. But at some point, some level of management is going to say, "What would an emergency patch for this look like to our customers?", "What does this do to our statistics?", "What are the potential liabilities?", etc. At that point, the patch will go in, and it will get fixed, but it will be put into "the process" and run through as quietly/non-disruptively as possible. The longer a bug has existed without being exploited, the more delay in "the process" will be tolerated.

    I've also seen situations where patching a bug is interpreted by management as "admission of guilt," and then they start worrying about liability/recall type issues. In particular there was once a situation where they stonewalled a problem so hard that it when it finally broke, of course they got dynamic, let us fix it the way we'd been pushing to do, took credit, and gave themselves nice pat$ on the backs. In that case, it was at least decent that they didn't punish us other than during the stonewalling phase. We even got some pat$ on the back, too.

    I have more confidence that such decisions in Linux will be technically, not politically based. I also know that there are personality issues, so it's not 100%, but it will generally be better.

  • by Anonymous Coward on Wednesday January 20, 2010 @12:50PM (#30833752)

    and yet, several holes existed for years before being found.....

    Lets be clear, all OS'es may have exploitable holes, all exploitable holes can and will be hacked, in this regard, windows, linux and OSX (and any OS for that matter..)are no different.

    The only difference is how and when those holes get handled. the Linux community seems to quicker at fixing exploits than MS, but thats because there are 10 million Linux gurus willing to fix those holes as quickly as possible.

    MS on the other hand has a smaller number of developers, some willing to fix exploits quickly as possible (willing, but not autorized!), others not so much. WHY? MS is FOR PROFIT company, and will only do things if it deems it profitable.

    So lets stop with the pre-amble that Linux is impenetrable or invincible. It isnt. Neither is Windows. Or OSX. or OS/400. etc....

  • by slimjim8094 ( 941042 ) on Wednesday January 20, 2010 @12:51PM (#30833766)

    Mac OS X managed to move from MacOS to a Unix - a far more significant change than anything Windows has done - without breaking much at all. Same with PowerPC to x86.

    Backwards compatibility doesn't need to be integral. In fact, it's probably safer if what's been deprecated is made really obvious.

  • by aztektum ( 170569 ) on Wednesday January 20, 2010 @12:58PM (#30833872)

    One of the big differences here is that those bugs are fixed and were fixed rather quickly. How long will we have to wait for MS to do anything about this one? Will they simply suggest people use 64-bit Windows? They're going to take a stance that they feel best benefits them and, until they do, Windows users are in the dark and fucked.

  • by HotBits ( 1390689 ) on Wednesday January 20, 2010 @01:33PM (#30834444)

    ... Microsoft finally starting taking security seriously.

    Where starting is the operative word. Here is one indication of how far they still have to go:

    Visit the Microsoft Online Safety password checker (https://www.microsoft.com/protect/fraud/passwords/checker.aspx). Try “Password1”.

    Wow, a "Strong" password! They don’t even do a simple dictionary check. Same is true in the OS from what I’ve seen so far.

    How long has that been built into Linux?

    From what I’ve seen in the field, dictionary attacks are the first thing malware attempts to gain control of a network.

    They are just starting to be serious about security.

  • Wasn't rewritten? (Score:2, Insightful)

    by palmerj3 ( 900866 ) on Wednesday January 20, 2010 @01:49PM (#30834650) Homepage
    So, you mean to tell me Microsoft lied all those times they claimed Windows was rewritten? Didn't see that one coming...
  • by Bacon Bits ( 926911 ) on Wednesday January 20, 2010 @02:24PM (#30835138)

    Well, look at the vulnerability. It's in the Virtual DOS Machine. That means you have to get 16-bit code onto the system and then make Windows execute it. So, in order to exploit the vulnerability, you've already got to have local access. No wonder Microsoft is dragging their feet. It's only exploitable in cases where you can already gain access to the system. If you're not logged on, I don't see any way to exploit this. It's not like you could even put 16-bit code in a buffer overrun and expect the kernel to execute it. It's got to be run through the NT Virtual Dos Machine or Windows-on-Windows, or it's not executable code.

    I'm sure someone will correct me if I'm wrong, but AFAIK there's no possible way to remotely exploit this (outside of another vulnerability). It's a Moderate vulnerability at best.

  • by Blakey Rat ( 99501 ) on Wednesday January 20, 2010 @02:47PM (#30835546)

    Mac OS X managed to move from MacOS to a Unix - a far more significant change than anything Windows has done - without breaking much at all.

    Buulllshiiittt.

    Spoken like a true, "I never touched Classic Mac in my life." The reason people say shit like this is only because Apple has *always* been so bad about breaking apps, that they didn't break any *more* than expected when OS X came out. (Remember the legions of apps that System 7 busted when it came out? Christ. Expectations are pretty low compared to that.)

    I switched away from OS X when it became apparent that:
    1) Classic would never be fixed to run more apps, nor would its more substantial flaws be fixed. (For example, how it drained laptop batteries like crazy for no reason.)
    2) Apple doesn't give a shit about anything older than about 3 years. For example, my parents can't use their camcorder with their laptop because, while OS X supports USB camcorders, it only supports them on x86 and their computer is a very-late-model PPC

    In the Mac world, if you don't upgrade once a year, you're fucked. I don't have the money or patience for that.

    Same with PowerPC to x86.

    That went smoother, as did their transition from 68k to PPC. But that just means they usually break apps for reasons other than CPU changes. :)

  • by JesseMcDonald ( 536341 ) on Wednesday January 20, 2010 @04:48PM (#30837278) Homepage

    This exploit lets any unprivileged local user inject arbitrary code into the kernel, and you think it only deserves a rating of moderate? Apparently you've never heard of local privilege escalation. This reduces the actual security of every NT-based Windows system to the single-user "security" last seen in Windows ME.

    Sure, it's not a remote exploit (yet). That doesn't mean it's not a major issue, particularly for those administering multi-user systems and/or network domains.

E = MC ** 2 +- 3db

Working...