Newly-Found Windows Bug Affects All Versions Since NT

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.'"

Comments

Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Anonymous Coward]

Cue "Windows Sucks" comments in 5, 4, 3, 2, 1....

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Attack DAWWG]

Hmm . . . cue the Microsoft apologists in even less time than that, I guess.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[yakumo.unr]

cue hahaha I switched to 64bit the moment I could in....er, now.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[jbezorg]

Cue the "cue the" comments in 3, 2, 1, 0, -1, -2, -3....

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Anonymous Coward]

Windows Sucks. But then you obviously knew that already.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[darkpixel2k]

Cue the "cue the" comments in 3, 2, 1, 0, -1, -2, -3....

-1? Looks like you just found a bug that's been in Microsoft's Meta Countdown tool. This one goes all the way back to Windows 2.0.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Anonymous Coward]

WINDOWRETPSM SUXXORZ!!!

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[ei4anb]

just to be pendantic:

Cue the "cue the" comments in 3, 2, 1, 0, -2147483648, -2147483647, -2147483646

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[xtracto]

I am using Windows XP SP3 right now and the POC code provided does not work.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Winter]

in 0x00000003, 0x00000002, 0x00000001, 0x00000000, 0x80000000, 0x80000001, 0x80000002..... Huh.... the other one makes more sense (3, 2, 1, 0, -1, -2...) as it would be what you got if you decrement a 32bit int: 0x00000003, 0x00000002, 0x00000001, 0x00000000, 0xffffffff, 0xfffffffe, 0xfffffffd

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[pleappleappleap]

Only if you count in 32-bit complement arithmetic. I know I don't.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Anonymous Coward]

Cue the "cue the" comments in 3, 2, 1, 0, 65535, 65534, ...

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Z00L00K]

May I get a patch for Windows NT 3.51?

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[neoform]

You just managed to make a recursive comment...

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Anonymous Coward]

Cue "Windows Sucks" comments in 5, 4, 3, 2, 1....

Why? We already know it does. You just said so yourself. :D

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Antiocheian]

Are you using a different name for the %systemroot% ?

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[IorDMUX]

I'm only 16 bits, you insensitive clod!

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[bpsheen]

Tell That to my wireless card which for some reason refuses to stay associated in Ubuntu when i connect via iwconfig , but in debian seems to just fine using of course iwconfig. Hmmmm...... oh, btw , its a broadcom 4306. (i had to use the firmware)

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[vonux]

I bet you're popular with the girls, you pendant!

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Khyber]

I wonder if this happens to work on the 64-bit DEC Alpha version of NT4?

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[bami]

More like cue the comments in 3, 2, 5 days, 3 hours, 23 minutes, 8 minutes, 2 hours 15 minutes, 15 seconds, 'Any moment now', 2 years.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[whoisisis]

-1? Looks like you just found a bug that's been in Microsoft's Meta Countdown tool. This one goes all the way back to Windows 2.0.

Sorry, can't help it: xkcd again has something to say here.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[ikarigullwing]

DELETE ****ING EVERYTHING.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[hguorbray]

I hate to be pedantic, well, no, not really, but I think you meant pedantic:

http://en.wikipedia.org/wiki/Pedant

-I'm just sayin'

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[scottv67]

>I wonder if this happens to work on the 64-bit DEC Alpha version of NT4?

Only if you run the compiled exploit code through FX!32.... ;^)

http://windowsitpro.com/article/articleid/270/migrating-to-alpha-with-fx32.html

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[yuhong]

Actually nope, as the V86 mode does not exist on non-x86, NT/Alpha do not contain the vulnerable code. NTVDM was an emulator on non-x86 arches.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[Khyber]

So in other words, my older than shit 533 MHz 64-bit DEC with NT4 is technically more secure than any other machine running any other Windows OS.

Thanks for that heads up. Fuck you yet again, Microsoft.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[aliquis]

my older than shit 533 MHz 64-bit DEC with NT4 is technically more secure than any other machine running any other Windows OS.

I doubt that, may have less already written exploits for it though.

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[aliquis]

Someone update http://www.urbandictionary.com/define.php?term=swoosh for this guy.

How do we know it's not already in use?

[jollyreaper]

Every time I read about one of these long-undiscovered instant pwn bugs, I always have to wonder if there's someone sitting deep underground in an NSA computer center saying "Well shit, looks like we'll not be using that exploit anymore."

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?

Re:How do we know it's not already in use?

[Skratchez]

My first thoughts exactly. I've always assumed any Windows PC I'm using could have been rooted long ago to an extent that no security tool could detect or repair it. I guess I'm just paranoid, I should really just switch to a Linux distro and start compiling my own kernels. As if I wouldn't screw that up too.

Re:How do we know it's not already in use?

[Jesterace]

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.

Re:How do we know it's not already in use?

[TheRaven64]

For a lot of them, that's almost certainly true. This one is interesting though. It's in the virtual MS DOS subsystem. This hasn't changed a huge amount of attention since NT 3.5. Someone might have found it back then, but if they didn't then it's more likely that they'd have focussed their attention on new code in new versions.

It's also worth noting that this doesn't affect 64-bit kernels for the very simple reason that they don't support 16-bit compatibility and so don't have the affected subsystem.

Re:How do we know it's not already in use?

[Dynedain]

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?

Re:How do we know it's not already in use?

[Anonymous Coward]

The same thing could happen in the Linux kernel, tbh. You're not safer using Linux over Windows for old exploits.

Re:How do we know it's not already in use?

[clarkn0va]

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.

Re:How do we know it's not already in use?

[think_nix]

funny how the security researcher (TFA) works at google , and now with the google china scenario this bug is now getting press when it was reported back in june 2009 , and still has not been fixed.
Wonder if all these new MS & IE bugs exploits being made known through google are due to lack of solidarity on some issues between google / ms ?

Re:How do we know it's not already in use?

[maxume]

It's a problem for corporate security, but for home users that were running XP as Administrator already, it doesn't do much to help the untrusted code that they chose to execute.

Re:How do we know it's not already in use?

[timeOday]

We can be pretty sure it wasn't widely exploited, otherwise somebody somewhere would have noticed.

Re:How do we know it's not already in use?

[Anonymous Coward]

I think you're only partly right. It seems like MS wants limited exposure of these threats because they can use it to
get people to upgrade. I'm sure this will help sales of 64-bit Win7 more than it hurts them from losses to other OSes.

Even the recent IE exploit was met with "upgrade to out new OS" spin until they realized it was getting out of control.

Re:How do we know it's not already in use?

[recoiledsnake]

Yea such exploits do not happen in Linux.

http://news.zdnet.com/2100-9595_22-332141.html

http://www.theregister.co.uk/2008/05/21/massive_debian_openssl_hangover/

Re:How do we know it's not already in use?

[think_nix]

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?

That is usually how it works with a lot of zero day or hardcore exploits from security researchers. Vendors/Developers are notified and given time to fix it until it is made public so the said fix is there before it is widely known.

Re:How do we know it's not already in use?

[clarkn0va]

Any code can potentially be compromised. 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.

Re:How do we know it's not already in use?

[Anonymous Coward]

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

Re:How do we know it's not already in use?

[Anonymous Coward]

"Well shit, looks like we'll not be using that exploit anymore."

They won't need to say that until 2011, when MS finally gets off it's backside and produces a patch.

In 2012 they'll say "shit, the botnet's shrinking" when the world finally gets around to actually applying the patch.

In 2013 they'll say "no problemo! I had an idea - I thought 'we need a new backdoor', so I asked Microsoft and they did it. I'm NSA and Windows 10 was my idea!"

Re:How do we know it's not already in use?

[TheRaven64]

Assuming, of course, that you're not running any binary blobs like, for example, the nVidia driver that had a remote exploit allowing an attacker to gain kernel privilege and wasn't fixed two years after it was first reported. No one outside of nVidia could audit the code and fix it, but other people (like the person who reported it) had found it and were able to exploit it.

Re:How do we know it's not already in use?

[Anonymous Coward]

that very true, if people upgrade to Vista/Win 7 / IE8 the IE exploit only hangs the appilcation, if you run WIN64 the WIN16 bug won't run, that's a very clear message from MS: "upgrade your systems to avoid future problems".

Re:How do we know it's not already in use?

[Nadaka]

The same thing "could" happen in the Linux kernel, true. But that does not mean it "isn't safer" to use linux over windows.

You will never be able to review the source code of your windows OS. You "can" do so in linux. For a sufficiently small linux distro, you could inspect the code yourself. There used to be linux distro's that fit on a single 1.44 mb floppy, I have had a hard time finding them now, smallest I can find recently is about 2mb. If you are an expert, thats small enough to review in a couple years. In a modern distro, it would be impossible for an individual to vet the entire code base, it would not be impossible for an organized, determined group of a few thousand experts to do so. I believe that the NSA does just this with selinux, or at least thats the claim.

The point I am making is that under the open development model, every change to the code is reviewed and inspected by several different people before it is included, this may not happen in a closed environment. Even after a change is approved, implemented and distributed, the availability of the source to everyone makes it more likely that such flaws are noted soon and then fixed quickly.

Re:How do we know it's not already in use?

[Xest]

More likely Google discovered this one as a result of a security audit in the light of the Chinese attacks against them.

Interestingly though, the parent may have a point, it could be that this one of the exploits the Chinese used internally at Google precisely because they have known about it so long.

But still, who knows.

Re:How do we know it's not already in use?

[plague3106]

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

Re:How do we know it's not already in use?

[Anonymous Coward]

Maybe I should just read your link, but how on earth does a video driver bug lead to a remote exploit?

Re:How do we know it's not already in use?

[John Hasler]

> Guess I'm glad I run 64bit.

Why do you assume that you are not subject to a different but equally appalling set vulnerabilities? The same people wrote 64bit Windows.

Re:How do we know it's not already in use?

[TheCycoONE]

You should have probably read the link. Buffer overflow allowed code to run as root (because the nvidia drivers do)

Re:How do we know it's not already in use?

[John Hasler]

True. For home users you just pop up a window saying "Click here to install keylogger".

Re:How do we know it's not already in use?

[Frans Faase]

It is not unthinkable that Microsoft has some (kind of) agreement with NSA with respect to not fixing these kind of security holes.

Re:How do we know it's not already in use?

[Chatterton]

If you are really paranoid, you will write yourself your own C compiler or else this could happen:
http://scienceblogs.com/goodmath/2007/04/strange_loops_dennis_ritchie_a.php

Re:How do we know it's not already in use?

[kalirion]

I should really just switch to a Linux distro and start compiling my own kernels

Don't forget to compile your own compiler...... Oh wait.... Better write it in binary on a computer you've assembled yourself from parts you've created yourself.

Re:How do we know it's not already in use?

[snemarch]

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.

Re:How do we know it's not already in use?

[noackjr]

Requisite Rumsfeld:
http://www.youtube.com/watch?v=_RpSv3HjpEw

Re:How do we know it's not already in use?

[0xdeadbeef]

Yes, but Linux is secure the same way OS X is secure - nobody cares enough to exploit it.

Re:How do we know it's not already in use?

[Nadaka]

I actually didn't claim any individual could audit the entire distro.

One expert could, with a few years of effort, could do so for the smallest distro's (those that can fit on a single floppy).

Your second paragraph I do agree with. There are probably not enough people testing for issues and auditing code in linux to keep "every" long standing flaw like this from going undetected for years. So get out there and audit some code! ;)

Re:How do we know it's not already in use?

[miknix]

In a modern distro, it would be impossible for an individual to vet the entire code base, it would not be impossible for an organized, determined group of a few thousand experts to do so. I believe that the NSA does just this with selinux, or at least thats the claim.

http://www.nsa.gov/research/selinux/index.shtml
http://www.cs.utah.edu/flux/fluke/html/flask.html

Indeed, SELinux is based on the FLASK kernel architecture which is formally verified. This means that flask has a mathematical model (specification) which researchers use to test for bugs and check for correctness. They CANNOT guarantee that the whole architecture is free of bugs, however they totally guarantee that for all the tests and validations performed the architecture is 100% free of bugs.
If the software (in this case a kernel) is developed exactly following the formal specification, then we can guarantee that the software will behave like the tested specification (mathematical model).

I'm not from formal methods but I believe it is something like that.

Re:How do we know it's not already in use?

[Anonymous Coward]

>The same thing "does" happen in the Linux kernel, true.
Fixed that for you

>But that does not mean it "isn't safer" to use linux over windows.
[Citation needed]

It's fanboys like you that hold back Linux.

Re:How do we know it's not already in use?

[Anonymous Coward]

Yeah you're right code review doesn't happen in closed environments.

Re:How do we know it's not already in use?

[psnyder]

It looks like the NSA may have had a backdoor to Windows since the mid 90s. They don't need other exploits if they've built in their own.

From the article written in 1999:

Dr Nicko van Someren reported at last year's Crypto 98 conference that he had disassembled the ADVADPI driver. He found it contained two different keys. One was used by Microsoft to control the cryptographic functions enabled in Windows, in compliance with US export regulations. But the reason for building in a second key, or who owned it, remained a mystery.

Two weeks ago, a US security company came up with conclusive evidence that the second key belongs to NSA. Like Dr van Someren, Andrew Fernandez, chief scientist with Cryptonym of Morrisville, North Carolina, had been probing the presence and significance of the two keys. Then he checked the latest Service Pack release for Windows NT4, Service Pack 5. He found that Microsoft's developers had failed to remove or "strip" the debugging symbols used to test this software before they released it. Inside the code were the labels for the two keys. One was called "KEY". The other was called "NSAKEY".

Fernandes reported his re-discovery of the two CAPI keys, and their secret meaning, to "Advances in Cryptology, Crypto'99" conference held in Santa Barbara. According to those present at the conference, Windows developers attending the conference did not deny that the "NSA" key was built into their software. But they refused to talk about what the key did, or why it had been put there without users' knowledge.

The NSA has also been "helping" Windows' security development since then as well.

I always thought that was one of China's motivations for Red Flag linux: take out the U.S's backdoor and put in their own. Red Flag first appeared in 1999, the same year that this speculation of the NSA backdoor began.

Re:How do we know it's not already in use?

[X0563511]

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

Re:How do we know it's not already in use?

[Manfre]

How do you know that gcc and other compilers have not been compromised in such a way as to inject code in to certain compiled applications? The only way to be certain is to formally prove a compiler's source and then compiled binary.

Re:How do we know it's not already in use?

[tacarat]

So it's not Windows vs Linux security, but a Closed vs Opens source security discussion.

Re:How do we know it's not already in use?

[sconeu]

You've got to build your own toolchain, too.... from the bare metal.

Reflections on Trusting Trust.

And I guess you have to trust the CPU not to have backdoors, too...

Re:How do we know it's not already in use?

[jittles]

Review the code all you want, you're not going to find everything. No one releases bug free software. IMO, the only advantage open source can possibly claim is a lower MTTF, or mean time to fix.

Re:How do we know it's not already in use?

[dpilot]

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.

Re:How do we know it's not already in use?

[Anonymous Coward]

This shows one of Linux's biggest weaknesses, no support for legacy exploits.

Re:How do we know it's not already in use?

[Anonymous Coward]

> Guess I'm glad I run 64bit.
>
And you think this helps? Has it come to your attention that you can run on a 64bit system, 32bit binaries and 16bit binaries?

Re:How do we know it's not already in use?

[Anonymous Coward]

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

Re:How do we know it's not already in use?

[Nadaka]

No one releases bug free closed source software either. And that was at least part of my point, that there is an MTTF advantage. I wouldn't say its the only advantage though. A closed source software provider could choose to ignore the flaw and you will never get a fix, while in an OS project, if the provider doesn't fix it quickly, you or someone else has the option to fork and correct it.

Re:How do we know it's not already in use?

[aztektum]

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.

Re:How do we know it's not already in use?

[kellyb9]

You must be new here. Negative media exposure for Microsoft on /. is pretty much the norm.

Re:How do we know it's not already in use?

[snemarch]

Yeah, there was the privilege escalation that affected all architectures and kernels across 2.4->2.6 (around 8 year timespan), the chunked-encoding exploit in Apache was around for quite a while as well, iirc - and those are just what I can remember off top of my head :) At least this NTVDM is "only" privilege escalation - it's pretty damn bad, but not as bad as a remote service hole, or something that can auto-trigger in your browser (you don't need admin privs to do nasty stuff, even though admin privs help). Btw, I thought Vista introduced running NTVDM processes in a way that LUA accounts couldn't interact with the processes, not even send window messages (and thus paste text etc.) - but perhaps I'm confusing this security with the win32 console mode subsystem, which is something completely different from NTVDM.

Re:How do we know it's not already in use?

[SirWhoopass]

So, Linux's obscurity provides its security?

Re:How do we know it's not already in use?

[ei4anb]

Two of the vulnerabilities that I discovered (and wrote exploit code for) in 1979 still have not been rediscovered, or at least not published. They were useful for about 12 years but that OS is no longer widely deployed. So, yes it is possible.

Re:How do we know it's not already in use?

[Anonymous Coward]

The argument that linux is safer because anyone can audit and fix the code isn't entirely sound. Anyone can also audit and exploit, if they choose. There's no such thing as a secure OS. I'll continue to favour obscurity over openness until the day everyone leaves their house doors unlocked.

Re:How do we know it's not already in use?

[Jesterace]

With what TheRaven64 said ... "It's also worth noting that this doesn't affect 64-bit kernels for the very simple reason that they don't support 16-bit compatibility and so don't have the affected subsystem." I have no doubts there are other exploits and flaws in my 64bit version. Just this one specifically affects the 32bit version.

Re:How do we know it's not already in use?

[Anonymous Coward]

Bingo.

Re:How do we know it's not already in use?

[Anonymous Coward]

This presumes that someone able to make a change knew about the potential exploit. To be honest, well crafted exploits are very difficult, and require a lot of research and understanding more often than not. I've caught potential buffer overflows, and even simple race conditions more often than I care to admit in other people's code. This is in large organizations and financial institutions even. Though I haven't actually worked in the money processing side of things. I can say it's very easy for a potential exploit to go unnoticed. Look at the DNS poisoning for example, that sat there for years and years, mostly under open-source DNS implementations. Then to realize the design itself is flawed in a few ways.

To be honest it doesn't surprise me much at all, and probably isn't an area that's been under much scrutiny since XP, when they added a lot of compatibility to the NTVDM for extra DOS support, for the migration from DOS-Based Windows.

Re:How do we know it's not already in use?

[welsh git]

You are wrong.

I have released bug free software.

Here it is, under creative commons license:

10 PRINT "Hello World"
20 GOTO 10 :-)

Re:How do we know it's not already in use?

[Anonymous Coward]

.. an attacker could exploit the vulnerability by creating a mapping at address zero containing code to be executed with privileges of the kernel, thus triggering a vulnerable operation ..

Explain, how the hell is possible from userland to create "a mapping at address zero containing code to be executed with privileges of the kernel", should not this be the first thing to totally disallow in the first place ?

Re:How do we know it's not already in use?

[Anonymous Coward]

The little Linux which would run from a 1.44MB floppy was called Tom's Root Boot. Great little rescue tool in its day.

Re:How do we know it's not already in use?

[Anonymous Coward]

It's times like these that makes me glad I use OpenBSD for everything.

No, wait... it's EVERYDAY that makes me glad I use OpenBSD. Lulz.

Re:How do we know it's not already in use?

[Lunix Nutcase]

You will notice that that error was found and corrected fairly quickly

Actually it wasn't found until 2 years after the code was originally committed.

Re:How do we know it's not already in use?

[mR.bRiGhTsId3]

Presumably one has to have local access, since to provide input to the NVidia driver one needs a display server running locally and provide bogus input to it.

Re:How do we know it's not already in use?

[fialar]

You can always run OpenBSD (http://www.openbsd.org) Only one security hole found in over 10 years!

Re:How do we know it's not already in use?

[aztracker1]

Honestly, it's more that the diversity and fragmentation of actual Linux deployments make any potential exploit a fairly small target. Aside from core vulnerabilities in in OpenSSL, it'd be difficult to find any exploit that would work on even half of linux distros. Though today, more and more places are focusing on x86/x64 based distros (which means there's some safety in using a BE vs LE platform) with Fedora/Redhat, SuSE and Ubuntu being the most common distros in play it becomes easier to target specific exploits more broadly.

IMO tuned attacks are more common for Linux, where broad based attacks are more common for Windows. I don't see that either is particularly safer, generally speaking. I do think there are advantages to both closed and open source software. What is more important, for the most part is some common sense, and basic knowledge. Having some generally basic precautions will help as well. This exploit doesn't seem to be remotely exploitable, but it's easy enough to get a large enough group of people to run malicious code. Of course 64-bit windows doesn't have the NTVDM anymore.

Re:How do we know it's not already in use?

[Lunix Nutcase]

You will never be able to review the source code of your windows OS.

That's funny. In school we got to examine a huge chunk of the NT kernel source code. One has been able to do so in an academic environment for years now.

Re:How do we know it's not already in use?

[frogzilla]

I don't think it is pedantic to point out (well maybe it is) that mega uses an M not an m and byte is signified with B not b. I see errors with unit symbols too often. Please remember that units are important. Remember Spinal Tap (" and ' are units too though I prefer to avoid them if possible).

You took the time to capitalise your writing according to standard rules of english. Just try to remember that Mb and MB are not letters as you are used to using but symbols with special meaning that coincidentally look like letters. This goes for all of the metric system prefixes and SI symbols.

I'll probably regret writing this but it hurts my head when I see these mistakes.

The main point you made was clear and I agree with you. Access to the source is a benefit to the user community.

Re:How do we know it's not already in use?

[Anonymous Coward]

The point was to contrast that to the two decades it took this other bug TFA is about.

Re:How do we know it's not already in use?

[aztracker1]

But wouldn't the same be true of Linux, only the fact that they're paid for upgrades vs. free would seem to be the biggest difference. To be honest, I switched to Win7 x64 the day the RTM became available on MSDN, I'd been running the Beta/RC on my netbook for a while before the release. To be honest, I don't care too much what my main host OS is, I have VMWare for my work, which is usually under various VMs.

Re:How do we know it's not already in use?

[Anonymous Coward]

Can u help me 2 compile this. I have tryed everything but gcc says it is error.

Re:How do we know it's not already in use?

[Anonymous Coward]

Nope. There was a published exploit straight to remote root from web page view.

Re:How do we know it's not already in use?

[aztracker1]

I'd say this is probably unlikely. Since this security hole in particular isn't remotely exploitable except through social engineering. It's more likely though that the NSA does have a shared source agreement with MS, and simply doesn't tell anyone when they find certain potential exploits. I doubt they'd even do that though, considering how many government employees with potentially sensitive information run Windows on laptops. The greater good would be to have the OS secure over have that potential to exploit foreign machines.

Re:How do we know it's not already in use?

[aztracker1]

This really is only exploitable via social engineering, there's little value in it by itself. If it were abused it would be more likely to be so by those with guest accounts on a given machine, with direct access to the hardware in order to raise their level of access.

Re:How do we know it's not already in use?

[Anonymous Coward]

The vast majority of people could not spot a security hole, even if they searched for one, in any OS, even if they had the source code.

Finding these holes (through source inspection) requires sophisticated reasoning, experience, an extreme focus on details, and the ability to reason about the interaction between many different components of a system. Most of these bugs are not of the form "if (x 0) grant_root_access();". Instead, they are usually based on one developer making assumptions about some component that turn out not to be true.

For example, new kernel developers often don't understand exactly how probing and locking works, when validating parameters that they receive from user-mode using pointers directly into the VA of the calling process. They don't think about the fact that a different thread (in the same process) can modify the page tables, page attributes, or modify the contents of memory. So a lot of bugs creep in this way. If you're reading the syscall implementation code, you're likely to overlook this. If you're reading the VM code, you're likely to overlook this. You have to consider *both* of them together, in order to find the bugs.

So this requires experienced, sophisticated developers. And I'm sorry, but 99.9% of all users (including Windows, Mac, and Linux users) just don't have that level of sophistication in software engineering, and don't *want* to.

So the real issue is -- who really has the experience, the ability, and the motivation to find these kinds of bugs? In the Microsoft world, there are people are paid, day in and day out, to look for these things. Microsoft frequently publishes patches for issues before any else finds them. That doesn't mean that the process is perfect -- obviously people outside Microsoft find bugs, and obviously sometimes those bugs are fairly serious.

Similar reasoning applies to Mac OS.

In the Linux world, it is certainly true that anyone *can* review the code. However, 10,000 amateurs don't equal even 1 expert. There certainly are experts -- talented, motivated, and experienced -- in the Linux world. Unfortunately, many of them are not paid to do what they do, and so they have little economic incentive to spend 100% of their daily life looking for security bugs. (A few do, but the majority don't.)

And unfortunately, there IS one set of people who all have a strong economic motivation, and that's authors of malware. This includes organized crime, unscrupulous large companies, and obviously governments (Hi, China!). Having access to the source code is enormously helpful for these folks. They can also get by with reverse engineering, but having the source code makes their job far easier.

Re:How do we know it's not already in use?

[DemoLiter3]

BSD holds the crone for the bug unpatched for the longest time (25 years):
http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug

Well, at least they patch them.

Re:How do we know it's not already in use?

[welsh git]

Ahhh, Gcc doesn't like the smiley face at the end of line 20

Re:How do we know it's not already in use?

[bdrewery]

It's a pretty common vulnerability. Bugs like this occurred in Linux recently, as well as FreeBSD (completely different kernel code bases obviously). Some things like DOS emulation require mapping at 0, but in most cases this is unnecessary. Both Linux and FreeBSD disallow mapping at address 0 now. OpenBSD has disallowed this by default of course for quite some time.

Re:How do we know it's not already in use?

[clarkn0va]

Said binary blobs are not part of Linux itself, although they may be part of a Linux distribution. They would be more like Windows than Linux in my original example--closed code that can carry bugs for years without the public ever being aware. It's one reason we 'free software freaks' don't care for binary blobs.

Re:How do we know it's not already in use?

[recoiledsnake]

That contrast is meaningless considering the null pointer bug that was in the Linux kernel for 8 years and the fact that MS takes backward compatibility as a Holy Grail compared to almost any other software maker.

Re:How do we know it's not already in use?

[Smegly]

It is not unthinkable that Microsoft has some (kind of) agreement with NSA with respect to not fixing these kind of security holes.

Your sooo flirting with the Trolls on that one - even whispering that idea is bound to rile up the Microsoft/Gov astroTurfers. You could be absolutely right - it would be the logical way to extraofficially backdoor your closed source operating system - but it would be almost impossible to either disprove or prove that it is/is not indeed a deliberate back door. When/if it is ever publicized then it can be shrugged off and downplayed as just another serious security flaw (despite it just happening to affect every version of your OS, for decades + be ignored when finally did come to light).

Re:How do we know it's not already in use?

[recoiledsnake]

The same people wrote 64bit Windows.

And a similar kind of people wrote, reviewed and audited Linux.

http://news.zdnet.com/2100-9595_22-332141.html

Re:How do we know it's not already in use?

[garaged]

be sure to use the selinux patch !

Re:How do we know it's not already in use?

[Anonymous Coward]

I remember when I found a bug in the network login script at the company I worked for (huge international company btw) in the late 80s.
A weird combination of commands dropped me through to a network server (NetWare, if I remember correctly) command line interface, allowing me to modify stuff I shouldn't be allowed to.

I contacted the it-department and told them about the bug. Their first reaction was that I was abusing the network and should be fired, mostly because they were embarrassed by the situation, I think.

After they discussed the whole thing with my boss I became a member of the company security group instead.

The next time I found a security hole in a company product I hesitated before reporting it.

Re:How do we know it's not already in use?

[H0p313ss]

Windows users are in the dark and fucked.

You make that sound like a bad thing.

Re:How do we know it's not already in use?

[recoiledsnake]

So why didn't it stop this 8 yr old exploit?

http://isc.sans.org/diary.html?storyid=6820

Re:How do we know it's not already in use?

[nschubach]

That really depends on a few things... I mean, a dark prison and a dark bedroom are two totally different comfort zones. Not to mention your relationship to the "provider" has a little bit of relevance.

Re:How do we know it's not already in use?

[Anonymous Coward]

I always have to wonder if there's someone sitting deep underground in an NSA computer center saying "Well shit, looks like we'll not be using that exploit anymore."

I know a penetration tester that went into law enforcement over a decade ago that uses that trick. As well, there's a buffer overflow in the FAT16 code that allows arbitrary code execution in ring 0. Good luck trying to find it, though... it's quite subtle, but like this one also depends on memory pointers being 32bits. /Posting as AC because the NSA is really the least of my worries.

Re:How do we know it's not already in use?

[Lennie]

Obviously adding a link to what you are talking about is always nice:

http://en.wikipedia.org/wiki/Backdoor_%28computing%29#Reflections_on_Trusting_Trust

Re:How do we know it's not already in use?

[unixfan]

Agreed. My reason to switch to Linux, back in -95, was because I had no hope that things would get better with MS products. With windows you know that when a new SP comes out it will also break things but w Linux I've almost never had that happen. Just look how long it took to get MS to even admit to having bugs.

With Linux there is this desire to fix things. And when things break I'm not overly concerned as I expect it will be fixed, or if I really need to, I can get it done. As you said, it is technology driven.

If you support others, or they depend on your product, that is a huge advantage. The O/S is not fighting me, but contributing to what I'm trying to do.

Re:How do we know it's not already in use?

[westlake]

The difference here is that anybody can audit or fix the Linux code, and many people and organisations have and do.

Which - taken literally - implies that Linux could fragment into a thousand or ten thousand unique "distributions."

Each with their own hodgepodge of patches.

Re:How do we know it's not already in use?

[Anonymous Coward]

From wikipedia: The tour in support of Born Again included a giant set of the Stonehenge monument. In a move that would be later parodied in the mockumentary This Is Spinal Tap, the band made a mistake in ordering the set piece. As Geezer Butler later explained: We had Sharon Osbourne's dad, Don Arden, managing us. He came up with the idea of having the stage set be Stonehenge. He wrote the dimensions down and gave it to our tour manager. He wrote it down in meters but he meant to write it down in feet. The people who made it saw fifteen meters instead of fifteen feet. It was 45 feet high and it wouldn't fit on any stage anywhere so we just had to leave it in the storage area. It cost a fortune to make but there was not a building on earth that you could fit it into.

Re:How do we know it's not already in use?

[Anonymous Coward]

I also use obscurity for security. Good luck finding my door. I've obfuscated it. Or was that not what you were talking about?

Re:How do we know it's not already in use?

[Anonymous Coward]

It was not too long ago that they found some "less secure" key space in one of the more advanced encryption theories ..

which was located by some researcher and published .. 20 years after some memo from the nsa advising to not use the key space in question ..

So yea .. I bet they knew about it :-)

Re:How do we know it's not already in use?

[Bacon Bits]

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.

Re:How do we know it's not already in use?

[b1t r0t]

When people talk about a "remote" exploit, they usually mean "remotely exploiting a box that's sitting there minding its own business", which is a form of exploit that Windows has had particular problems with. A web exploit still requires a local user to make it happen.

Re:How do we know it's not already in use?

[nschubach]

I was too busy clicking "Next" to read the title of that Window. How can I tell if I installed it?

Re:How do we know it's not already in use?

[Mr. Shiny And New]

64-bit windows drops support for 16-bit binaries.
http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edition#Windows_XP_Professional_x64_Edition

Re:How do we know it's not already in use?

[Anonymous Coward]

I'll continue to favour obscurity over openness until the day everyone leaves their house doors unlocked.

Bad analogy. Leaving the door unlocked on a house implies you don't have any security at all because you trust everyone in your (usually small) community and that's not the case with open source (although that is still the case in some small towns where everyone knows everyone else). Perhaps you could make a case if you said you made your "open" house out of wood and proprietary houses are made out of lead, while knowing that the bad guys can commonly use X-ray machines. Either of the two houses might have ways to break in, through the roof or through unlocked doors or windows. It's easier for both you and the bad guys to use X-ray machines to spot those vulnerabilities in the wooden house but you have to have the discipline and process to do that regularly and fix problems you find. It's also a bigger risk in the wooden house to not check everything if you have young kids unlocking doors and windows. But living in the lead house doesn't help you if you also leave a lot of unlocked doors and windows and someone actually goes up and checks them instead of doing it from the curb with an X-ray machine. However this analogy probably breaks down when you talk about newborns and toddlers gnawing on the lead house.

Re:How do we know it's not already in use?

[Anonymous Coward]

And thus proving that there this magical notion of all open source code being audited to be total bunk as I pointed out originally here?

Re:How do we know it's not already in use?

[leuk_he]

If you use windows 16 bit code is like using linux 2.0 or 0.99 binaries. There could be bugs there,but 16 bit code is supposed to be froma an era you had fulle control over the hardware anyway.

Re:How do we know it's not already in use?

[miknix]

So why didn't it stop this 8 yr old exploit?

http://isc.sans.org/diary.html?storyid=682

SELinux is an additional layer of *ACLs* to system resources and it is located in kernel layer. I can't put it better than that.

Just because SELinux is based on a formally verified architecture, it won't stop you for specifying wrong ACL rules which it seems to be the case here.

--
Even Bing would have found the answer for you!

Re:How do we know it's not already in use?

[Anonymous Coward]

The only difference between Linux and Windows, is if you are still running Windows 2000 for whatever reason, you are most likely SOL! With Linux, you can at least hire someone to get the problem fixed if you cared enough.

Re:How do we know it's not already in use?

[FalcDot]

"A new software built by my company is released. The UI locks up. The computer crashes and loses everyone's data. Now, should we initiate a patch? Take the number of copies of our software in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a patch, we don't do one."

Original quote from Fight Club.

Re:How do we know it's not already in use?

[Anonymous Coward]

Every time I read about one of these long-undiscovered instant pwn bugs, I always have to wonder if there's someone sitting deep underground in an NSA computer center saying "Well shit, looks like we'll not be using that exploit anymore."

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?

Here is what I believe, without any particularly good reason to do so: The NSA is nothing close to what you think. The US has too developed an IT industry for these guys to be competitive employers of talent. The reason people think the NSA has all this well kept powers is simply due to decades of bombarding of US military propaganda in the mainstream media that leads some to believe these people were able to use a satellite to read the newspaper in Saddam Hussein's hands. The US military and intelligence capabilities are grossly overstated by the masses, especially US residents. For example, see: http://slashdot.org/story/07/11/12/222237/Chinese-Sub-Pops-Up-Amid-US-Navy-Exercise

On the other hand, many people may indeed know about these "unknown" holes. But they do because there is a market structure that adds value to this knowledge. And the Eastern European and Chinese blocks have an excess of talent that cannot be assimilated by the formal economy, to which these activities are a perfectly fine way of making a living. Don't get me wrong, action movies are great fun and no one makes them better than Hollywood, but the moment we step out of the theater or turn off the TV, also please shut down the suspension of disbelief.

Re:How do we know it's not already in use?

[Anonymous Coward]

Right, because if you still ran 32 bit you might have attacked yourself and elevated your privileges. I mean, come on - a local elevation of privilege is a serious bug - but it doesn't get you "attacked" unless you are running unknown executables. It's more of a worry for a company that runs standard user accounts as their own employees may try to get some exploit code working in order to "get something done" that requires admin rights and inadvertently introduce something into the environment that they should not (or heck just end up violating copyright by installing something they shouldn't), but for the individual user the risk from something like this is very minimal.

Re:How do we know it's not already in use?

[Obfuscant]

Presumably one has to have local access, since to provide input to the NVidia driver one needs a display server running locally and provide bogus input to it.

Since it was a display driver, all you had to do to exploit it was be able to see the screen.

Re:How do we know it's not already in use?

[Anonymous Coward]

Holy Crap, this is consuming all my memory- DENIAL OF SERVICES!!!!

Re:How do we know it's not already in use?

[TheRaven64]

Exactly, but read any discussion about Linux and you'll have people saying 'I buy nVidia cards because they have the best Linux support' and when people point out that they are blobs saying 'I don't care, they work and that's all that matters' It doesn't matter how secure Linux is if you're going to run a big blob of unaudited code right next to it in ring 0. Not that the Linux kernel has a particularly good security record recently...

Re:How do we know it's not already in use?

[Sulphur]

Is the search for bugs automated?

--

Sig removed by accident

Re:How do we know it's not already in use?

[maxwell demon]

Don't forget to first check the details of the computer design you build. Oh, and the description of the working of a transistor you got from your books could be manipulated, so you better verify it for yourself. With a self-built measurement apparatus, of course.

Re:How do we know it's not already in use?

[blueskies]

I'll continue to favour obscurity over openness until the day everyone leaves their house doors unlocked.

Why the arbitrary condition? I'll continue X until everyone wears red on thursdays. The fact that people make their doors obvious shows that they aren't relying on obscurity to secure their house.

Re:How do we know it's not already in use?

[Anonymous Coward]

Yawn! Again? How many times more do we have to present OpenBSD as the winner of this game?

Re:How do we know it's not already in use?

[Anonymous Coward]

I'll bite :)
1) Different people wrote 64-bit Windows -- it was just written for the same company (someone feel free to prove me wrong on this one).
2) 64-bit was written with some lessons already learned, so it'll be different vulnerabilities (as stated) -- not the ones people have known about for years already. This means there's some level of security through obscurity.
3) there are way fewer people who target 64-bit environments, both exploiters and developers. There are also fewer people who use it. This means that it is a much smaller target for a much smaller group of archers. Of course, it also means that the people who are exploiting it are probably very good at what they do.

Summary: smaller pond, smaller fish, more difficult to obtain bait needed, fewer fishermen experienced at catching them.

Re:How do we know it's not already in use?

[Martin Foster]

What about OpenBSD? The core distro has apparently gone through the rigours of auditing and I am sure that is dealing with a fair amount of lines of code.

Sure OpenBSD does not offer every bell and whistle in their distribution. It certainly shows that it can be done if you have the will and resources to do it.

Re:How do we know it's not already in use?

[SpaceLifeForm]

Use the source Luke, use the source.

Re:How do we know it's not already in use?

[Anonymous Coward]

My first thought was.... Wasn't Vista/7 said to be a "ground up" redesign of Windows???? Obviously not really...

Re:How do we know it's not already in use?

[nschubach]

Considering the name (it's not BackslashDot) and the fact that you can find literally hundreds of "Microsoft friendly" websites out there... I don't see a problem with that.

Re:How do we know it's not already in use?

[Manfre]

Using source is pointless if the compiler binaries you have are not entirely trusted. It is entirely possible that at some point many years ago malicious code was added to gcc and undetected. This code would become compiled in to a malicious binary. At that point, the malicious source code could be removed because it would get inserted by the maliciously built binary. All subsequent source can no longer be trusted since it is used to compiled clean source to create the next binary for the compiler. The malicious code would get passed on from version to version because it is stored in the compiled binary from many version before.

Re:How do we know it's not already in use?

[Anonymous Coward]

My reason to switch to Linux, back in -95

96 years before Jesus was born?

Re:How do we know it's not already in use?

[armareum]

If your analogy takes longer to explain, you shouldn't bother.

Re:How do we know it's not already in use?

[JesseMcDonald]

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.

Re:How do we know it's not already in use?

[steelfood]

there's no possible way to remotely exploit this (outside of another vulnerability)

Your caveat says more than the rest of your post. Considering how many external-facing exploits exist, and how many probably remain undiscovered, I wouldn't be surprised if this one is often used to root a machine once it's been compromised. You can clean infected files, but only if you can detect them, and they're separate and distinct from your files.

One external-facing exploit can wreck havoc before it's fixed or the machine's reformatted. Add this one into play, and the operator simply won't realize the machine's compromised.

Re:How do we know it's not already in use?

[Anonymous Coward]

That's because negative impact by Microsoft upon the world in general is pretty much the norm.

Re:How do we know it's not already in use?

[Drantin]

[...]Only one security hole found in over 10 years!

That's something of a misstatement. The claim only relates to remotely exploitable holes, and there have now been two of them. Although without digging too deep, for all I know the first was over 10 years ago...

Re:How do we know it's not already in use?

[Anonymous Coward]

Moderate or above! easily
easy email spam with malicious payload
MS advice on not using administrator accounts is no defense against this browsing the web or email.

In corporate environments this is trouble
1000s of users with limited terminal user access to RDP, 2008 terminal services and Citrix in limited user accounts can install root kits on the shared machines, worse a kernel level keylogger, dos attack or network trawler.

Re:How do we know it's not already in use?

[Anonymous Coward]

"The difference here is that anybody can audit or fix the Linux code"

Just as long as they are not auditing/fixing it on my machine...Just send me a patch.

As long you have network security in place--you need to be on the machine for this exploit--that's another issue.

Also for the Linux model, sure the code is audited and fixed, but MS has the same procedures, they're slower cause they have quality and deployment controls where Linux has none (everyone must be exactly the "same"). And don't tell me every patch pushed to you from the Linux community has never broken any application, driver or the kernel itself. In windows, if you get kernel level compatibility problems in Windows, you reinstall the OS and then your apps as 90% of them will usually work, in Linux you downgrade and wait until it's fixed or you're left to fix it yourself. It's choosing the lesser of 2 evils.

Re:How do we know it's not already in use?

[zukinux]

You don't know what's in Linux Kernel. http://www.theregister.co.uk/2003/11/07/linux_kernel_backdoor_blocked/ Things like that can happen. I hope the community is doing a good job. and they are :) p.s, I use linux myself, and trust no one.

Re:How do we know it's not already in use?

[Anonymous Coward]

"I have more confidence that such decisions in Linux will be technically, not politically based"

Windows is the dominant OS currently. And Linux is the new comer, fresh ideas OS. But look at how the FOSS community works--it's on prestige and not cash (windows). Prestige and cash actually are mirror concepts (power and money).

When Linux is the dominant OS (trending looks good), and the next new fresh OS comes on the scene--[Linux] politics will rule the day. I guarantee it. I think the 1st signs of this are Pulse Audio vs. OSS.

Re:How do we know it's not already in use?

[AmberBlackCat]

Wasn't there a recent Linux vulnerability that required access but not root access? How is this worse?

Re:How do we know it's not already in use?

[tacarat]

The general theory is like this.

1. Write down the dates of when the bugs were introduced.
2. Write down the dates of when the bugs were discovered/announced.
3. Write down the dates of when the fixes were provided.

Closed source is generally expected (at least at /.) to have long gaps between those three dates. Open source, due to anybody being able to audit the code, is expected to have shorter periods of time between them. Granted, the time period between #1 and #2 can be lengthy for both, but the spans between #2 and #3 is where OSS tends to shine. If one group of coders won't fix a known bug, another will.

That's the theory, at least. Every program has bugs at one point or another. OSS's strength is that it can be fixed by the community/individual rather than having to wait for the originator. Popular projects benefit more from this, but if you really want to, you can always DIY or hire folks if the program is important to you but not everybody else.

Re:How do we know it's not already in use?

[Tacvek]

You are probably thinking of tomsrtbt, which fits on a standard 3.5 inch floppy, but is greater than 1440 KiB in size. It requires low-level formatting a floppy to "1.7 MB" rather than the standard 1.44 MB. All 3.5 High Density floppy drives can support formatting a diskette like that, and obviously if they can format it like that, they can read it.

Re:How do we know it's not already in use?

[Anonymous Coward]

What abouot closed vs open? I keep reading that open is more secure than close but I didn't see any proob yet. Why exactly it must be that way? It seems to me than if it's harder to find vulnerabilities in closed source and thus it takes more time to get fixed, that means the bad guys also take more time in finding it. Where is the scientific study that open is more secure again?

Re:How do we know it's not already in use?

[Anonymous Coward]

This does show that MS likely can audit the code back to DOS 3.1 if needed. That at least says something from a CM standpoint. Can Linux community even audit back to 2.0 kernel?

Re:How do we know it's not already in use?

[Anonymous Coward]

Yes, you have to be on the machine--this bug is sort of like a nice R&D project that goes nowhere since it's based on obsolete technology.
Like proving a wooden stick breaks when everyone is using knives.

Re:How do we know it's not already in use?

[Unequivocal]

It's not security through obscurity - it's more like reverse honeypot. WinOS is such a sweet, widely distributed honeypot, that there's very little incentive to invest in cracking Linux to build lucrative botnets etc. Cracking an individual Linux server might yield some criminal benefit, but why bother when botnets are easier and require no/little new code..

Re:How do we know it's not already in use?

[Anonymous Coward]

dude, there are lot of public terminals running windows allowing users to operate with limited privilages.
For an example anyone can install keyloggers on public terminals at air ports. So I don't think we can/should call it a Moderate vulnerability.

Re:How do we know it's not already in use?

[Hurricane78]

And with what will you compile your own C compiler?
Unless to compile it to machine code by hand, on paper, and then feed it to a computer that you have built yourself, the same stuff can still happen.

Re:How do we know it's not already in use?

[socz]

But that's the point, the extremely low number of exploits compared to other OS'. But once again, the question of usability comes into play. Are you willing to work within the restricted work space or do you want to run wild like Windows 98?

Re:How do we know it's not already in use?

[socz]

You know how I explain this to non-technical people who ask me about anti virus and protection?

I say: well, think of computers like a lock. It could be a lock to your house, car or garage. Just because someone doesn't have the key doesn't mean they can't get in.

I go on in detail about sneaking in, brute force and other much more elaborate ways of doing it. But even then they think 1 program they heard about can protect their computer. It really comes down to what my buddy Billy used to say "What do I care? I got nothing people want to steal besides my porn. And hell, I give that away for free anyways..."

Re:How do we know it's not already in use?

[sapphire wyvern]

Compile it with every C compiler you can get your hands on. Feed your compiler's source code into the compiler executables that you built using every available C compiler on the market, and then compare the second-generation binaries of your own compiler. While I would expect the first generation compiler binaries to be different (since they were made with different third-party compilers), assuming that your compilation code works in a predictable fashion, shouldn't all the self-compiled second generation binaries be identical? If they aren't, then you can tell which of the first-generation binaries is/are compromised. Unless, of course, all the second-generation binaries are different, or they're all compromised in an identical fashion, in which case you're FUBAR'd.

I guess you could take the same strategy to try and verify the hardware as well?

Re:How do we know it's not already in use?

[dpilot]

Years back I found a bug in the network login script, too. A friend scheduled us for departing flights prior to 7:00am, and then failed to show. I figured I'd give him a little favor for getting us on the early flight, then skipping out on us. The normal login policy was, "5 failed logins and you get locked out."

So I attempted to login to his account 5 times with random passwords. On the 5th try I got in.
I couldn't believe I'd guessed it, so I tried 5 times again, with a single bogus password. On the 5th try I got in.

I went straight to the security guy and showed him. After turning a few shades, he thanked me and told me not to tell anyone. A few days later I was told that the problem had been put in just the weekend before, and that it was fixed now. Some time later, the friend who had skipped out on the flight told me he'd gotten a call from security about odd activity on his account.

At least in those (pre-internet, pre-PC) days, things weren't so paranoid that there would be talk about firing people.

Re:How do we know it's not already in use?

[clarkn0va]

Well, if you're right, and I'm right, then we can thank /. for being an ongoing force in ensuring regular Windows updates.

Re:How do we know it's not already in use?

[Anonymous Coward]

How does running Linux help you in this case, and, specially how EXACTLY does building your own kernels help?

Re:How do we know it's not already in use?

[bruno.fatia]

Windows users are in the dark and fucked.

Are you complaining about Windows or about Linux users not getting laid?

Re:How do we know it's not already in use?

[X0563511]

... and the severity is different as well.

What's worse? A weak cipher, or an escalation? Depends on the use certainly... but yea.

Re:How do we know it's not already in use?

[Bacon Bits]

Yes, it only deserves a rating of Moderate. It's not remote and requires local user intervention. This is pretty much the definition of a moderate vulnerability.

The industry appears to agree with me:
http://secunia.com/advisories/38265/
http://www.vupen.com/english/advisories/2010/0179

Re:How do we know it's not already in use?

[petermgreen]

but AFAIK there's no possible way to remotely exploit this (outside of another vulnerability).
Which is the key, in most cases* neither a local "root" vulnerability or a remote vulnerability in some unprivilaged daemon are that much of a threat on thier own.

Combine the two though and you get the equivilent of a remote root vulnerability which is about the most serious class of vulnerability arround.

Since remote unprivilaged code execution vulnerabilities are pretty common closing holes in the local privilages system promptly is a vital part of keeping systems secure.

* there are exceptions to this, terminal servers would be an obvious one where a local root vulnerability is a very serious issue on it's own.

Re:How do we know it's not already in use?

[petermgreen]

from the advisory:

"It is important to note that glyph data is supplied to the X server by the X client. Any remote X client can gain root privileges on the X server using the proof of concept program attached.

It is also trivial to exploit this vulnerability as a DoS by causing an existing X client program (such as Firefox) to render a long text string. It may be possible to use Flash movies, Java applets, or embedded web fonts to supply the custom glyph data necessary for reliable remote code execution."

Re:How do we know it's not already in use?

[mR.bRiGhTsId3]

I'm pretty sure that's still a local exploit since X has reversed the conventional role of the client/server. For the X client to gain access to the local X server that is running someone has to be logged in locally and launch a remote client through some means.

Re:How do we know it's not already in use?

[petermgreen]

64-bit windows can't run 16-bit binaries, afaict the only reason for not supporting win16 binaries is that MS couldn't be bothered debugging the code in question.

wine on 64-bit linux OTOH can run win16 binaries ;)

But does it run on Linux?

[oodaloop]

No, I guess it wouldn't, would it?

Someone had to say it though.

Re:But does it run on Linux?

[0racle]

Nope, Linux can't even run a simple app that will run on every version of NT since 1993. Some OS Linux is.

Re:But does it run on Linux?

[recoiledsnake]

Linux has it's own version of such bugs. Yes, even with the 'many eyes' looking at the source, it does happen, F/OSS is no panacea.

From http://news.zdnet.com/2100-9595_22-332141.html

A hole has been found in Linux kernel versions stretching back eight years that is 'as trivial as it can get to exploit', according to the Google employees who discovered it.

Julien Tinnes and Tavis Ormandy, the security researchers who discovered the vulnerability, have already issued a patch for the flaw. According to a blog post written by Tinnes on Thursday, the hole "affects all 2.4 and 2.6 kernels since 2001 on all architectures", and is "the public vulnerability affecting the greatest number of kernel versions".

Re:But does it run on Linux?

[Anonymous Coward]

just like NT cant run nix apps made in the 70's some OS NT is

Don't be a twit

Re:But does it run on Linux?

[psbrogna]

Sure it can- Wine. I've had surprisingly good luck running Windows apps natively on Linux (ie. not in a virtual machine or emulator).

Re:But does it run on Linux?

[TheRaven64]

That's not an equivalent bug, because it affects all architectures. This bug is in some architecture-specific code for running the VM86 mode on IA32 chips. It doesn't affect NT 4 on Alpha, PowerPC, or MIPS, or any more recent versions on x86-64 or IA64.

Re:But does it run on Linux?

[bmecoli]

Last I checked WINE doesn't virtualize DOS.

Re:But does it run on Linux?

[PitaBred]

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.

Re:But does it run on Linux?

[plague3106]

Wine enumlates dos now? Hmm.

Of course, your own phrase illuminates the problem. I don't want to rely on "suprisingly good luck" to run applications.

Re:But does it run on Linux?

[jetxee]

Switching to a new version of Linux is not nearly as big of an undertaking.

Clearly, you don't have an ATI video card, do you?

Re:But does it run on Linux?

[ClosedSource]

Last time I checked, Wine didn't even fully implement Win32.

Re:But does it run on Linux?

[jedidiah]

Wine doesn't have to. There are other applications that virtualize DOS. They seem to do better than XP does at it too.

Re:But does it run on Linux?

[TeXMaster]

Linux has it's own version of such bugs. Yes, even with the 'many eyes' looking at the source, it does happen, F/OSS is no panacea.

From http://news.zdnet.com/2100-9595_22-332141.html

A hole has been found in Linux kernel versions stretching back eight years that is 'as trivial as it can get to exploit', according to the Google employees who discovered it.

Julien Tinnes and Tavis Ormandy, the security researchers who discovered the vulnerability, have already issued a patch for the flaw. According to a blog post written by Tinnes on Thursday, the hole "affects all 2.4 and 2.6 kernels since 2001 on all architectures", and is "the public vulnerability affecting the greatest number of kernel versions".

Eight year is a pretty 'good' record, but Windows still wins by 7 more (NT3.5 released in 1994, more or less the time of release of Linux 1.0). Also notice that then Linux bug was fixed almost contextually with its report, whereas the one this article is about has not not been fixed 6 months+ after the report was acknowledged. This is where open source wins.

Re:But does it run on Linux?

[jedidiah]

ATI makes crap binary blob drivers. Whether or not you are updating your kernel has little bearing on this.

Of course if you follow the recommendations of Windows-centric hardware review sites, you don't won't have this problem. '-p

Re:But does it run on Linux?

[arose]

If you want to run MS DOS apps use dosemu or dosbox. In fact do this in 32bit Windows as well...

Re:But does it run on Linux?

[radish]

Agreed on time to patch.

But comparing switching from Win2K to 7 to a simple Linux upgrade isn't fair. We're talking about 10 year old software here - as an example Ubuntu don't support simple in-place upgrades for anything more than a couple of years old (and while I'm no expert Debian seems to have similar multi-step upgrades for older versions). If you're running an OS from 2000 (of any type) and want to upgrade to the latest, you're basically looking at a wipe & reinstall regardless.

Re:But does it run on Linux?

[Anonymous Coward]

What is this, 2003?

Re:But does it run on Linux?

[jc79]

yum update kernel
yum update xorg-x11-drv-ati

There, that wasn't so hard, was it?

Re:But does it run on Linux?

[Anonymous Coward]

OK so it's not equivalent. It is more serious.

Re:But does it run on Linux?

[Anonymous Coward]

Nope, Linux can't even run a simple app that will run on every version of NT since 1993. Some OS Linux is.

And this is a bad thing?

Re:But does it run on Linux?

[recoiledsnake]

Switching to a new version of Linux is not nearly as big of an undertaking.

Sure it's not.

http://linux.slashdot.org/linux/06/10/28/239258.shtml

http://www.theregister.co.uk/2009/11/03/karmic_koala_frustration/

Re:But does it run on Linux?

[yupa]

Not really some architectures like arm doesn't have this bug (because page 0 is used for something else).
Also one of the most use of mapping page0 is for running ... dosemulator on x86 via vm86 [1].

So they seems related.

Re:But does it run on Linux?

[Anonymous Coward]

christ are you that dense? linux can do it, and can do it well.

Re:But does it run on Linux?

[Anonymous Coward]

Then run windows or use native linux/bsd apps, you wouldn't buy a mac and expect to run windows apps, or install windows and expect to run linux apps, the fact that wine is so complete and capable is quite remarkable and it gives operating systems that support it useful additional functionality, but it's not the only solution.

btw, what's enumlation?

I was RIGHT !

[Anonymous Coward]

Don't just dump IE.

Dump MicroSLOP
completely !

Yours In Novosibirsk,
K. Trout

Re:I was RIGHT !

[Anonymous Coward]

Don't just dump IE. Dump MicroSLOP completely !

I don't know about you, but I don't want all those unemployed former MS-programmers to get down to Linux.

I'm helping to keep the Linux codebase clean and pragmatic by running Windows once in a while and giving a false sense of userdemand.

But seriously though, I have seen alot of "opensource windows clones", they all look like clowns to me in usability and aesthetics.

Re:I was RIGHT !

[nschubach]

I don't know about you, but I don't want all those unemployed former MS-programmers to get down to Linux.

It's alright. There's no possible way that will happen as Visual Studio still doesn't run in Linux, even under Wine. They'd all be too confused by the lack of magic code generating wizards, play buttons and twiddly knobs.

Re:I was RIGHT !

[pclminion]

Yeah, the quality of Microsoft's products is clearly due to programmer incompetence, it certainly has nothing to do with management or mis-prioritization. As we all know, management at Microsoft is composed of angels and benevolent demi-gods. If only those developers with hearts of pure evil would stop messing everything up...

Doesn't affect 64-bit?

[Anonymous Coward]

Yet another driving factor for using the 64-bit editions of Windows (or something completely different from Windows altogether!).

Backward compatibility

[recoiledsnake]

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.

Re:Backward compatibility

[sys.stdout.write]

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.

Re:Backward compatibility

[Anonymous Coward]

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.

Re:Backward compatibility

[Taevin]

Short-term backwards compatibility is one thing, but when do you draw the line? If I remember my history correctly, Windows 95 was the first 32-bit Windows operating system, the last release of which was 12 years ago.

Re:Backward compatibility

[sacrilicious]

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

There, fixed that for ya. :)

Re:Backward compatibility

[JustOK]

Yah. Same thing when I converted from a horse to a car. Had a hard time converting all that hay to gas.

Re:Backward compatibility

[NJRoadfan]

Short-term backwards compatibility is one thing, but when do you draw the line? If I remember my history correctly, Windows 95 was the first 32-bit Windows operating system, the last release of which was 12 years ago.

Windows NT 3.1, which this bug first appeared, was released in 1993. The one nice thing about NT's VDM and WoW subsystem is that it froze the Win16 API/environment so any 16-bit applications that worked with NT basically kept working without any new bugs up to Windows 7 32-bit. My old Windows 3.x apps kept working through various versions of NT, yet my Win32 apps kept breaking with each upgrade, go figure.

Re:Backward compatibility

[HideyoshiJP]

A lot of companies still need backward compatibility for their ancient ass applications, though. They still need to replace hardware and it's really difficult to run an old OS on modern hardware properly. I thought it was an accomplishment when I managed to jam NT 4.0 Workstation on Optiplex 755

Re:Backward compatibility

[nedlohs]

Which is the "what made" point. Do you enjoy just repeating half of the posts you reply to?

Re:Backward compatibility

[Anonymous Coward]

Even worse than that, microsoft 'fixed' DirectX a couple of times in the span of Windows XP breaking a shit ton of my older games (The late 9x/2k/XP stuff, which was actually written properly... except that certain functions in directx had their return codes changed in later years and thus broke some apps display functions.)

The thing that makes this most hilarious is a bunch of 'Microsoft Games' based games are among these, including a few with broken 3d support (due to modern videocards only supporting 32bit depths and lacking non-power of 2 texture support.)

Best part? Wine dumped compatbility between win31 and winxp such that those transitory apps are broken as well.

Re:Backward compatibility

[slimjim8094]

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.

Re:Backward compatibility

[aztracker1]

IIRC there was a 32-bit subsystem for WFW 3.11 not to mention the NT line, though I don't recall any applications that had broad reach that utilized it. I think a lot of it was changed/enhanced in Windows 95 IIRC. I also remember there being some differences with the WFW and the NT line in terms of the Win32 support... this persisted into the Win9x line as well, which was generally an extended version of WFW 3.x with the 32-bit extensions, and a fancy UI grafted on.

Re:Backward compatibility

[Anonymous Coward]

What backwards compatibility? I have a good few hundred dollars worth of games I purchased in the latter half of the 90s that don't work on XP. Oh how I miss thee Screamer Rally!

Re:Backward compatibility

[sys.stdout.write]

It was actually a response to the suggestion that steadfast support for backwards compatibility will "break" Microsoft. I think it's one of their major advantages over competitors.

Forgive me for being too subtle.

Re:Backward compatibility

[sys.stdout.write]

Indeed. I would love to see a ground-up rewrite of Windows. But the point is that backwards compatibility is really important; perhaps even worth having age-old bugs surface from time to time.

Re:Backward compatibility

[selven]

Yeah, people hate it when they're forced to accept a large volume of insecure bloat just so some enterprise user can use his outdated applications.

Re:Backward compatibility

[Blakey Rat]

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. :)

Re:Backward compatibility

[nedlohs]

No such suggestion was made, "may" is a very different beast than "will".

Maintaining backwards compatibility has costs and benefits. I'm sure Microsoft could have found other things for their developers to do that making sure SimCity didn't crash on a new windows version and adding specific checks and memory management special cases so it would.

Apple showed that emulation can work 15 years ago, and "Windows XP mode" in Windows 7 seems to indicate MS finally noticed (though it's not as nice as Apple's old approach).

Re:Backward compatibility

[drsmithy]

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.

The move from DOS-based Windows to NT-based Windows was at least as significant.

Neither of Apple's migrations were without their problems, either.

Free time.

[Anonymous Coward]

This bug was discovered by Tavis Ormandy.

Tavis, you need a girlfriend.

Re:Free time.

[taviso]

Applications Welcome ;-)

Re:Free time.

[JustOK]

There's an app for that?

Re:Free time.

[Anonymous Coward]

This is why I still read Slashdot.

Re:Free time.

[nschubach]

To get dates?

64 Bit

[ZeroSerenity]

Yet another reason people need to abandon 32-bit OSs. Seriously. What's the point of using half the power of your CPU?

Re:64 Bit

[Anonymous Coward]

64 bit referrers to the addressing space. If you have under 32 bit addressing of RAM, 64 bit will be slower.

Read up.

Re:64 Bit

[maeka]

Yet another reason people need to abandon 32-bit OSs. Seriously. What's the point of using half the power of your CPU?

Do you really believe a 32 bit OS uses half the power of your 64-bit CPU?

Re:64 Bit

[TeknoHog]

Yet another reason people need to abandon 32-bit OSs. Seriously. What's the point of using half the power of your CPU?

I only have 32-bit hardware, you insensitive clod!

Re:64 Bit

[0racle]

Bits are not a measure of power.

I have a Sun Ultra 10 (300MHz UltraSPARCIIi) and a MacBook (1.85 GHz CoreDuo), guess which one is more 'powerful.'

Re:64 Bit

[Anonymous Coward]

Oh, damn! I thought I was saving electricity by using a 32 bit OS.

Re:64 Bit

[Jugalator]

What's the point of using half the power of your CPU?

That's more like what a single-threaded app would do on a dual core system, and quite far from what a 32-bit app would do on a 64-bit capable CPU. It's not that simple. :-)

Re:64 Bit

[simcop2387]

While its true that there will be some overhead from the increased address size, there is however something significant to be said about the increase in the number of General Purpose Registers in the cpu that you get access to when using x86_64 rather than just x86. It is very important to realize that x86 being such a register starved architecture has significant gains from the doubling of the number of registers available to a program, this can mean that many more loops can have some or most of their main variables in the extremely fast registers rather than having to go out and fetch them from memory on each use. Even with a large fast cache next to the CPU you still cannot beat the performance gains from being able to have twice as many things in GPR.

Re:64 Bit

[maxume]

I'm going to play it safe and guess that the Sun is more powerful.

Re:64 Bit

[EvanED]

...64 bit will be slower.

That's not really true most of the time, from what I understand. The little I've seen said that the increased memory use and cache pressure that's caused by 64-bit pointers is canceled out by the increased register set of x86-64.

Re:64 Bit

[simcop2387]

In one aspect of it, yes, yes it does. x86 will only have half the number of general purpose registers available on a x86-64 processor that a 64bit operating system will be able to allow its programs to work. now you are right that its not the number of bits that are important there, its just that the new instructions are the only thing that allows you to access the extra registers.

Re:64 Bit

[Anonymous Coward]

You said the same thing above. Do you really think we're unable to read up?

Re:64 Bit

[TheRaven64]

The reason that this bug doesn't affect Win64 is that the virtual DOS mode is not supported at all on these platforms. If you upgrade to a 64-bit version of Windows, you lose compatibility with all DOS and Win16 apps, unless you use an emulator. For some people, especially people with business apps written for Win3.11, this is a show stopper.

Re:64 Bit

[Nadaka]

Um? what? the "bits" of an OS/CPU don't have much to do with "power". Most people still have less than 4 gigs of memory. And since the "bits" are the width of the memory address bus , they don't have a physical need for more than 32bit support in their OS.

Re:64 Bit

[JustOK]

try living in a two-bit town

Re:64 Bit

[Anonymous Coward]

i was responding to two different people with two similar but different questions. without responding to both of them it is unclear whether the other would ever get the information because it wasn't said to them.

Re:64 Bit

[captjc]

Personally, I wish the Microsoft would replace all the backwards compatibility cruft with a decent virtualization solution. I had hoped that Windows 7 would have done that with their Virtual PC application (Yes, I know about XP Mode, but it isn't the same). DOSbox has a pretty good emulation right now. I have used it to run old games and Windows 3.11 with applications. I hear that some have even gotten it to run Windows 95. Now that there are decent emulators and virtualization solutions, I think it would be the time for Microsoft to finally streamline Windows into the ultramodern OS it needs to be.

By the way, if using an emulator or a virtual appliance is not an option, I don't think they will be upgrading to a new computer anyway.

Re:64 Bit

[snemarch]

Most 32bit stuff runs with no perceptible speed difference (positive or negative) on 64bit Windows - there's a few corner cases, though. Foxit Reader (at least some versions) has/had extreme slowdown in PDF rendering, for some reason - we're talking bad enough that rendering a single page of a complex PDF takes 3+ seconds, with the elements gradually being drawn (Intel Quad6600@2.4GHz) - it was actually faster to render the PDF in a 32bit VM on the 64bit host :-) .

Some things seem slightly faster, though, and it's definitely nice being able to use a lot of memory - and 32bit apps compiled with large-address-aware can use almost full 4GB of memory space, they aren't limited by the 2:2 (or 3:1 with boot.ini option) split as on a 32bit host. And when you have a need for huge address spaces or lots of GPRs, 64bit apps are quite nice. Iirc context switches have less overhead under 64bit as well, even in face of the extra GPRs.

And then there's all the nice extra kernel improvements that Vista and Win7 have brought along - concerning security as well as speed. Too bad the usermode subsystem developers partially ruin that ;)

Re:64 Bit

[Archangel Michael]

You can't even get a shave and a haircut for that anymore.

Re:64 Bit

[jittles]

Sure it is. I can benchpress over 1024k bits! THat's powerful, right?

Re:64 Bit

[kalirion]

Yeah, just like having only one passenger is using 1/4 the power of your SUV.

Re:64 Bit

[thePowerOfGrayskull]

Yet another reason people need to abandon 32-bit OSs. Seriously. What's the point of using half the power of your CPU?

Do you really believe a 32 bit OS uses half the power of your 64-bit CPU?

THe other half of the CPU gets turned off doesn't it?

Re:64 Bit

[GogglesPisano]

Thank God someone posted a car analogy! Now it's all so clear!

Re:64 Bit

[Nakor BlueRider]

64-bit can also crunch larger numbers at once, which can reduce the number of equations running through the processor if a lot of math with huge values is being performed, but only if the code was written for 64-bit specifically, making it at best a really minor advantage.

Windows 7

[wwwillem]

From the RFA: "He said he informed Microsoft security employees of the vulnerability in June".

So, Microsoft could at least have fixed this in Windows 7 (according to Wikipedia: "released to manufacturing on July 22, 2009").

Re:Windows 7

[recoiledsnake]

Windows 7 64-bit is not vulnerable to this, and thats the version that is pushing heavily to OEMs and companies.

Re:Windows 7

[filesiteguy]

I just checked my Windows 7 installation. I don't see wowexec.exe in the process tree when running a cmd session.

Re:Windows 7

[Anonymous Coward]

I just checked my Windows 7 installation. I don't see wowexec.exe in the process tree when running a cmd session.

You need to run a 16-bit dos application as well...

Re:Windows 7

[snemarch]

cmd.exe has nothing to do with DOS or NTVDM - it's a native 32bit Windows console mode application.

Re:Windows 7

[TheNinjaroach]

thats the version that is pushing heavily to OEMs and companies.

I'd say so. I bought a refurb PC with a copy of Windows Vista 32-bit. It was eligible for the free upgrade to Windows 7, which to my surprise came in 64-bit. That was a pleasant surprise, although I'm pretty convinced that Windows 7 is really just Mojave 2.

Re:Windows 7

[Tim C]

How do you know they had enough time to fix it before going RTM?

Now, if it's not fixed in the service pack, then I think you can complain.

Re:Windows 7

[filesiteguy]

Ah, good point.

I fired up a 16-bit application I still have lying around (I worked on it back in '93-95.) and occasionally run in DOSBox for the fun of it.

I do see NTVDM running but not WOW. (I remember WOW being an NT thing.)

Re:Windows 7

[yuhong]

Yep, I wonder how many still call the Command Prompt in NT-series OSes the "DOS prompt", even though it is a misnomer. MS unfortunately did not help by naming the Start Menu item for cmd.exe the "MS-DOS Prompt" in NT 4.0 and below. MS was able to fix this in Win2K, but... In fact, I wonder how many still confuse Win32 console apps with DOS apps.

Re:Windows 7

[yuhong]

WOW is for 16-bit Windows apps, not DOS apps.

Re:Windows 7

[aztracker1]

Vista to Windows 7 had more than a few changes under the covers. Not to mention that the UI is a lot more well baked. I found a lot of the changes in Vista to be nice, but incomplete. I like Win7 quite a bit more than Vista, though the new taskbar would be #1 on my list of favored changes, I honestly liked the XP start menu better than either, exception to the search box.

Re:Windows 7

[drsmithy]

So, Microsoft could at least have fixed this in Windows 7 (according to Wikipedia: "released to manufacturing on July 22, 2009").

No, they could not have.

Re:Windows 7

[snemarch]

A lot of people confuse the two!

Even people who should know better... I kinda hope it's only the name that sticks, and they don't think they're actually running DOS programs.

Btw, while x64 Windows drops DOS support (no wonder since Long Mode doesn't support v86 tasks), it still has the ability to execute 16bit BIOS routines. That's right, MS included a (very limited, and with pretty stringent memory location write protection) 16bit x86 emulator :)

Re:Windows 7

[deniable]

WOW is still in XP. (NT 5.1) Not sure about Vista and 7. (NT 6 and 6.1)

Re:Windows 7

[deniable]

Get them to try CMD.EXE and COMMAND.COM and see if they spot the difference. The 'DOS prompt' is still there, at least in XP, and just as horrible.

32 bit?

[Ralz]

Good job I run W7 64-bit then I guess. I remember when I tried using XP64, what a pile of crap that was. I'm glad they have sorted the compatibility issues in newer releases.

Re:32 bit?

[the roAm]

XP64 is insane. How in the hell did they completely break hiding desktop icons to the point where it's no longer even an option? This and other lolwut stuff in XP64 is what made me switch back to 32. I refuse to use Vista or 7 until they, you know, work.

Re:32 bit?

[Ralz]

I used Vista 64 for about a year and had no major issues, other than the amount of resources it used, compatibility was pretty decent and I was overall happy with it.
When 7 came along it completely shadowed Vista, it was superior in every way. I've found my copy of 7 64bit to work very smoothly, I haven't had any issues at all with it if I'm honest. I've had no driver issues, all of my hardware and peripherals are supported, which is nice. Compare it to XP64 and its approx. 10^infinity times better.

Does it affect IE8?

[gmuslera]

A lot of people don't care about local vulnerabilities, until they can be turned into remote or turn "secure" browsers running everything with limited privileges into something that runs with administrative rights.

In particular, if that could be used to turn the "safe" IE8 into something unsafe could lead into more governments asking their citizens to stop using IE, any version of it.

Re:Does it affect IE8?

[TheRaven64]

It's a privilege escalation vulnerability, so if there is a hole in IE 8 then it becomes a remote root hole, rather than a remote unprivileged hole. I'm not certain about IE 8 in limited mode. It's possible that the ACL for this is configured to prevent starting VDM processes, but if it isn't then it becomes possible to escape from the sandbox after compromising IE 8 (that, at least, is easy to fix with a minor tweak).

Really though, VDM should be thrown away. It works less well than DOSBox and requires some quite ugly stuff in the kernel.

Re:Does it affect IE8?

[TheLink]

Privilege escalation isn't a big deal for "desktop users" in practice because:

1) The windows crowd are already running as admin, or they'll just click "OK" as many times as it takes to see the dancing pigs/bunnies.
2) The linux crowd if they are not running as admin, are often running unsandboxed browsers (e.g. firefox) using the same account they are logged in as. That means if the browser is exploited, the malware can access all their precious data, credentials, certs, emails on their local filesystems and on remote filesystems. The malware can make network connections through their VPN connections. The malware can do whatever their normal user account allows them to do - which is often a lot.
3) Only a few people should care about the OS files. The rest should care more about their data. There are usually plenty of copies of the OS available, and the O/S files aren't private files.

Re:Does it affect IE8?

[aztracker1]

Not to mention that other than running listening services bound to low ports (1024) you can do pretty much anything you'd want to in an exploit as the user anyhow. Mainly that a botnet node will run perfectly fine in user space. Where this would be a greater concern is in a corporate environment where you have access to the hardware, and have a lower privileged account. You can run software at an elevated level and inject a rootkit with say a keylogger, and more easily cover your tracks.

Re:Does it affect IE8?

[TheRaven64]

Did you somehow completely fail to read my post before replying to me? Privilege escalation is the difference between a compromised sandboxed IE instance being able to run a bit of code (but not access any of the user's files) and that same instance being able to get at all of the user's files and hide itself in the kernel or boot sector (or even the BIOS) where the user can't remove it short of a complete reinstall, and possibly not even then.

Re:Does it affect IE8?

[Anonymous Coward]

mmm it is because ie8 is sandboxed, but keep talking about things you reaaly don't know nothing about.... answering the original question I'm almost sure it doesn't affect it because you won't have enough privileges to call CreateRemoteThread, like it's needed in this exploit. Now mod me -1 Informative.

Only 32-bit Windows builds?

[Jugalator]

Ormandy said the security hole can easily be closed by turning off the MSDOS and WOWEXEC subsystems. The changes generally don't interfere with most tasks since they disable rarely-used 16-bit applications. He said he informed Microsoft security employees of the vulnerability in June.

So, to be clear, is this only about 32-bit Windows builds then?

64-bit Windows doesn't even support running 16-bit applications. And that's what WOWEXEC is all about. However, I'm less sure about this "MSDOS" subsystem in 64-bit builds? What's that for, anyway? The console emulation?

Re:Only 32-bit Windows builds?

[Jugalator]

Oh, fuck me for not even reading the summary properly. :p

Ignore the above, it's clearly not about 64-bit CPU's.

Re:Only 32-bit Windows builds?

[The Wild Norseman]

Oh, fuck me for not even reading the summary properly. :p

Nice try, dude. If that really worked, we'd all be getting laid like rock stars.

Re:Only 32-bit Windows builds?

[pclminion]

The Window console (cmd.exe) is a true-blue Windows program. It doesn't "emulate" anything. It is not DOS.

Re:Only 32-bit Windows builds?

[Slashcrap]

The Window console (cmd.exe) is a true-blue Windows program. It doesn't "emulate" anything. It is not DOS.

Yes it does. It emulates a proper terminal. Quite badly.

windows 7 64bit

[axor1337]

it looks Like one more reason to switch to 64bit to me. I have been using 64bit since Vista. Now I am glad I made the switch. and since the oem keys for vista and 7 are good for both the 32bit and 64bit versions the only excuse for not going 64bit is laziness (assuming you have a 64bit processor) I have yet to find a 32bit program that doesn't run on my 64bit machine.

Re:windows 7 64bit

[Chaos Incarnate]

OEM keys may be good for both, but they don't come with both media.

I haven't run across any programs, but my printer doesn't have a 64-bit driver. But that's what I use the Windows XP Mode for. :)

Just in time

[Anonymous Coward]

I guess windows 7 sales were a bit sluggish, so here comes a new bug they can fix in windows 8.

What about other NT archs?

[Anonymous Coward]

What about the PowerPC version of NT? That's 32-bit too. And of course the DEC Alpha version is 64-bit, so it can't have that exploit.

"OSs released since 1993"

[Dystopian Rebel]

Slashdot makes me sick. It's just not fair to go digging 14 years prior to the date when Microsoft finally starting taking security seriously.

Re:"OSs released since 1993"

[Anonymous Coward]

Why do you keep going back to something that'll make you sick? Maybe you should go see a doctor.

Re:"OSs released since 1993"

[arhhook]

It's just not fair to go digging 14 years prior to the date when Microsoft finally starting taking security seriously.

Yes, forget every system that may still be running these OS's! I stand they didn't start taking security seriously until "Cancel/Allow," so how dare you dig any further for vulnerabilities!

Re:"OSs released since 1993"

[querist]

I hope you're only kidding.

Pointing out that this bug dates back to 1993 is a very important part of the story, because it shows that even with their careful reviews of the code that things can still slip by.

Supposedly, Microsoft performed a review of all of the code used in Vista and Windows 7. This is not a slam against Microsoft, but an illustration that something as complex as Windows will always have security flaws no matter how hard you try to fix things after the fact. You cannot add security as a feature. It needs to be included from the initial design.

Re:"OSs released since 1993"

[Anonymous Coward]

Maybe that's a reason why UNIX systems are more secure? The UNIX philosophy, after all. Do one thing, and do it well. Why have the same people design the kernel and the firewall and the whatever it is?

Re:"OSs released since 1993"

[HotBits]

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

Re:"OSs released since 1993"

[bdrewery]

The same can be said about all projects. This is why OpenBSD is so secure. It's however lacking in performance and usability quite a bit :(

Re:"OSs released since 1993"

[Anpheus]

Because a rainbow table that included Password1 would have to store 13,537,086,546,263,552 ((26+26+10)^9) passwords, and assuming the developers were braindead and used 128-bit MD5 hashes with no salt, you'd have 1,732,747,077,921,734,656 (128*(26+26+10)^9) bits of hashes to store. That's two hundred thousand terabytes of data.

Now I understand that there are some time/memory tradeoffs that allow you to use much smaller tables and spend much more time, but even so, even the 8 character upper and lower case alphanumeric table from Project Rainbowcrack is 80GB and takes hours to crack.

So yeah, Password1 is actually not that bad. There are a lot worse! I'm a fan of pass-phrases myself.

Re:"OSs released since 1993"

[Anonymous Coward]

Password1 is actually not that bad.

Nonsense. It is too that bad. Password crackers frequently check for obvious/naive passwords first. Meaning this would be cracked in seconds.

Re:"OSs released since 1993"

[caubert]

I'll bet a lot of MS certified admins use Pa$$w0rd for their Contoso Domains

Re:"OSs released since 1993"

[Anpheus]

If you had used all lowercase, I'd say yes. I believe "password" and "password1" are among the most common, followed by "password123" and the like.

The only objective way to measure password strength is the number of character sets involved (uppercase, lowercase alphabetical, numeric, etc.) and the number of characters. Password1 is far, far stronger than "password1".

Re:"OSs released since 1993"

[WuphonsReach]

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?

And the old adage "Those who do not understand Unix are condemned to reinvent it, poorly" rings true.

How long until we see the NT4 patch?

[gimmebeer]

So much for 'nobody writes hacks for old stuff anymore, if we just keep running NT we'll never get hacked' Sounded good at the time.

WOWEXEC is still in use?

[filesiteguy]

Actually, I was just messing around. I'm kind of suprised it took someone this long to find a vulnerability in wowexec. I'm sure MS is not even thinking much about this, yet pretty much any program can have the possiblity of a buffer overrun or some sort of registry memory shift.

I found it funny that the Google ad displayed next to the article was for Microsoft forefront touting the security features.

http://www.perfectreign.com/stuff/2010/forefront.jpg

Many Eyes vs. Zero Eyes

[Anonymous Coward]

I've heard that coders at Microsoft don't code, and they don't go looking for bugs in old products especially. Afterall, that code is done and (to quote Blogovich) is F*ckin' golden! The only way MS code is checked is by reverse engineering by independent firms. BTW, that appears to be a violation of the EULA. How do they get ever away with this. F*ckin do gooder's, poking their nose into someone else's business!

Brought it on yourself

[zookeeperme]

Anyone still running only 32-bit Windows deserves the vulnerability. This is just one more reason why people should be upgrading to 64-bit.

Re:Brought it on yourself

[daveime]

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).

Re:Brought it on yourself

[dc29A]

Anyone still running only 32-bit Windows deserves the vulnerability.
This is just one more reason why people should be upgrading to 64-bit.

Yes because (insert computer illiterate person here) checking email, browsing Facebook or chatting on an IM needs a Quad Core CPU with 16 GB of Ram running Windows 7 Ultimate x64.

Not sure for you, but on the planet I live on, Earth, they don't. Most of my family members use Windows XP on 4+ year old machines, they are all happy.

Re:Brought it on yourself

[Anpheus]

64-bit has more improvements than just a larger address space.

Re:Brought it on yourself

[Anonymous Coward]

Tell the sysadmins and helpdesk staff responsible for millions of 32-bit XP workstations around the world at companies that make all the cool stuff you buy that they deserve this vulnerability.

Judging by your UID, aren't you going to be late to social studies class?

Re:Brought it on yourself

[daveime]

Support for 16 bit legacy apps ?

Wider range of driver support ?

Wider selection of applications / games ?

Honestly, for someone on purely 32 bit hardware and not needing massive amounts of RAM, is there any notable benefit to 64 bit ? Please, tell me about these improvements ?

Re:Brought it on yourself

[Johnno74]

Honestly, for someone on purely 32 bit hardware and not needing massive amounts of RAM, is there any notable benefit to 64 bit ? Please, tell me about these improvements ?

One thing I can think of is 64 bit windows prevents unsigned drivers, and also prevents even signed drivers from patching the in-memory kernel functions. This gives you a great deal of protection against rootkits.

Overall I don't think there are many benefits of going to an x64 OS with less than 3gb of ram (remember the 4gb limit of x32 inclides video ram etc.) but there aren't really any downsides either.

Also, as you say your CPU / MB only support 32bit, you'd need to upgrade your hardware to run a 64 bit OS....

Re:Brought it on yourself

[Anpheus]

http://en.wikipedia.org/wiki/AMD64#AMD64

Research it yourself?

Anyway, I think the biggest issue is that you're limited to 4GB without the hack that is PAE and the ensuing performance issues. Upgrade to 64-bit, do yourself a favor.

Old School

[GreenTom]

I always wondered by PEEK and POKE still worked in QBASIC.

Re:Old School

[idontgno]

I always wondered by PEEK and POKE still worked in QBASIC.

Dear $DIETY, that's a horrible thought. A Qbasic poke-script (with scores of DATA statements) that roots your Vista kernel. That's... sick, just sick.

Re:Old School

[daveime]

POKE 32768,16
POKE 32769,23
POKE 32770,14
POKE 32771,4

Re:Old School

[GreenTom]

All right, you out-old skooled me with that...what do those four POKEs do?

Re:Old School

[daveime]

Commodore screen addresses ... I just wrote PWND in the top left of the display.

Re:Old School

[bpsheen]

um the commodore 64's screen memory (the character one), was located at 1024-2023 decimal, so code would be. poke 1024,80 poke 1025,87 poke 1026,78 poke 1027,68 if you want to 6510 assembly version, i can provide that too. btw if i remember correctly, if you have paint shop, you could design a screen in it, reset your c64 and if you went into hires mode (320x200), and set the framebuffer to 32768, the screen you were composing in print shop, will be there. oh yeah, make your you are not on the bottom line of the screen otherwise the results will scroll away. Thought i add my 8-bit 2 cents.

Re:Old School

[bpsheen]

oh yeah, it's obivious you dont know ASCII either. can't spare another 2 cents for ya.

Re:Old School

[nschubach]

They get you into the Gibson.

Re:Old School

[daveime]

Please hand in your geek card on the way out !

We are talking old school here ... Commodore PET.

Screen buffer started at address 32768, and the character set used was NOT ASCII, but PETSCII. Go Google it.

Small, small world...

[Zocalo]

Interesting co-incidence that you should bring up that example. Tavis Ormandy, one of those who discovered the Linux kernel bug you mentioned, was also the one who posted the details on the Windows 16bit VDM bug that we're discussing here to Full Disclosure yesterday. I guess he must like his code to be covered in cobwebs or something...

Re:Small, small world...

[nschubach]

You should see his office. There's a certain ambiance that appeals to some people, like Steampunk. We'll call it Webpunk.

WARNING: Technical stuff follows

[idontgno]

Vulnerability applies to 32-bit Microsoft Windows operating systems with Windows NT 3.5 heritage.

Vulnerability arises from ancient coding or design flaws in the MS-DOS execution subsystem. This subsystem is not present in 64-bit Windows OSs.

The workaround is to disable the MS-DOS subsystem.

Great article at the SANS Institute Internet Storm Center: http://isc.sans.org/diary.html?storyid=8023. This includes links to Youtube videos on how to use Windows Group Policy tools to disable this subsystem.

However, once you do this, you won't be able to run 16-bit DOS-based software, so if you really need that you may have to wait for a patch. Or build a dedicated DOS machine, where at least you'll have no illusions of security. (Cynics would say this is true of any MS operating system, but I leave that debate to others.)

Re:WARNING: Technical stuff follows

[idontgno]

Correction: All 32-bit MS Windows OSs with Windows NT 3.1 heritage... i.e., from NT 3.1 to 32-bit Win 7.

Re:WARNING: Technical stuff follows

[Anonymous Coward]

Maybe Microsoft could replace their VDM with DosBox running OpenDos.

Re:WARNING: Technical stuff follows

[simcop2387]

Or build a dedicated DOS machine, where at least you'll have no illusions of security. (Cynics would say this is true of any MS operating system, but I leave that debate to others.)

Or instead use something like Dosbox to emulate the dos machine, would probably be significantly easier than trying to get an old dos box on a network and running.

Re:WARNING: Technical stuff follows

[jank1887]

DOSBox ftw?

Re:WARNING: Technical stuff follows

[adisakp]

However, once you do this, you won't be able to run 16-bit DOS-based software, so if you really need that you may have to wait for a patch. Or build a dedicated DOS machine, where at least you'll have no illusions of security. (Cynics would say this is true of any MS operating system, but I leave that debate to others.)

Or use VirtualBox / VMWare / VirtualPC to create a VM to run your DOS programs.

Re:WARNING: Technical stuff follows

[mantis2009]

does DOSbox require the MS-DOS subsystem?

Re:WARNING: Technical stuff follows

[KazW]

I don't think so, considering it runs on non-DOS OSes(linux, mac, etc)... Plus it runs on 64 bit windows, which doesn't have the subsystem.

The era of awesome 16-Bit gaming lives!!!

Re:WARNING: Technical stuff follows

[ignavus]

Vulnerability applies to 32-bit Microsoft Windows operating systems with Windows NT 3.5 heritage.

So it is still OK to use Windows 95? That's a relief.

Re:WARNING: Technical stuff follows

[deniable]

Yeah, the headline is a bit dumb, "since NT" is silly since Windows 7 is NT version 6.1 and last I heard is still shipping.

Hang on - Isn't this a well-known bug?

[Anonymous Coward]

I seem to recall demo-coders bragging about using a local priv. escalation bug in the VDM to "break out" of 16-bit DOS code at least 3-4 years back.. Anyone remember?

Warning: Clueless editor writes panic headline

[flerlerp]

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.

Re:Warning: Clueless editor writes panic headline

[idontgno]

Relative to a 17-year latency period, yeah, 7 months is new-found. And full disclosure was new as of yesterday. To everyone but the discoverer and the OS vendor, that makes it new.

To crib some TV network's advertisement, "It's a rerun, but it's new to you!"

Re:Warning: Clueless editor writes panic headline

[Anonymous Coward]

Welcome to slashdot.

Re:Warning: Clueless editor writes panic headline

[BlackPignouf]

I'm not exactly sure you know how to use "whom" :
http://web.ku.edu/~edit/whom.html

Just a matter of time before...

[robot256]

...the German and French governments advise their citizens against using Windows altogether, not just Internet Explorer.

Re:Just a matter of time before...

[hellraizer]

i hope they do i will change country the day that happens :)

FTFA

[Anonymous Coward]

"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."

So, er, why isn't there a link telling us punters how to disable the WOWEXEC and MSDOS subsystems off? Enquiring minds wish to know...

Re:FTFA

[Anonymous Coward]

For Windows XP, Vista, and Server 2003/2008 (someone please confirm on Vista and Server 2008 -- we've dumped them in favour of OSX)

Click Start->Run

Type in MMC.exe, click OK

Click File->Add/Remove Snap-in...

Click Add

Find Group Policy Object Editor, hightlight it, and click Add

If you are doing it for a whole domain, select the default domain policy here, otherwise, leave it as-is (or, if you're a purist, you can create a new policy object for it -- but if you know how to do that, then you probably don't need these instructions)

Click Finish, Close, then OK

Go to: Console Root->Local Computer Policy->Administrative Templates->Windows Components->Application Compatibility

Find the entry that says "Prevent access to 16-bit applications" and double-click it

Click Enabled and OK

Close the console. Done!

Feel free to correct me if I've missed a step or something.

Re:FTFA

[Anonymous Coward]

I guess I should correct a couple things in my own post:

Does NOT work on XP Home -- only Pro.

You can also run gpedit.msc instead of going through the rigamarole of adding snap-ins and all, but only if you're doing the fix for a single computer.

According to a few sources on the web, you can get gpedit to work on XP Home. You have to copy the DLLs over from XP Pro and register them with regsvr32.

Or, if you're brave and don't mind reloading your computer if you screw up, you can edit the registry to do it. Don't ask me where it is, though.

Not "Newly-Found"

[Len]

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

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.

Re:Not "Newly-Found"

[LordAzuzu]

Well, this should be appealed as "Newly-Disclosed".
Still, no way that a colossus (???) like MS keeps a hole like this open for months.
What if... they used it for something else? What if... someone else used it for something else?
What if... someone told'em NOT to fix it until released to the public to be able to... guess what?

Re:Not "Newly-Found"

[Blakey Rat]

Frankly, if the bad guys have the ability to place and execute a 16-bit application on your computer, you're probably already toast. This exploit is only effective if combined with another exploit, so it's really not nearly as big a deal as the Slashdot story implies.

Yes, it is a problem, and yes it wasn't noticed for a very long time. But it's not like viewing a .gif image on a website is going to pwn you.

Re:Not "Newly-Found"

[pclminion]

He gave them 10 days to find the problem, invent a correct fix for it, a fix that works on all supported releases of Windows, quality test it, compatibility test it on thousands of configurations and against all the major pieces of 16-bit software that are still in use, and release it, and he was surprised when that didn't happen? What a dick.

I'm not thinking "What a bunch of losers, they waited six months then busted the thing out in a single day when they got called on it." I'm thinking "Wow, I'm pretty impressed they were able to do that in only six months."

People like you (and Ormandy) seem to have NO FREAKING IDEA how something as enormous as Windows is developed. I suppose you'd prefer they slam out a rough-cut patch in 24 hours, only to discover later that it introduces ADDITIONAL problems and vulnerabilities, and well I guess that's awesome for you because then you get to bitch at them for that as well. Get a real job and write some real software.

Re:Not "Newly-Found"

[thisisntme]

Where does it say he only gave them 10 days to fix the problem?

You can review Windows OS code.

[140Mandak262Jamuna]

You will never be able to review the source code of your windows OS.

All you have to be is Chinese Government. That is all. You think the Google hack was found by relentless probing of defenses of the WinOS? Or did they have to just grep through the WinOS source code for things like strcpy()?

I told you!

[Yvan256]

Windows 98SE rules!

Re:I told you!

[Anonymous Coward]

Are.. are you telling me Windows ME is MORE secure than Vista/7 now? That's just.. wrong.

Re:I told you!

[Tim C]

It's less capable and exposes fewer services - yes, it's more secure. Almost all the old bugs will have been fixed, and none of the new ones will have been introduced (as the OS doesn't support the required software). Plus of course almost no-one is using it, so there's no point (beyond idle curiosity) to trying to find more exploits for it.

Good luck running it on modern hardware though.

And yet they ridiculed poor Donald Rumsfeld...

[mosel-saar-ruwer]

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?

The only public figure in American society who had anything remotely insightful to say in the last twenty years or so:
.

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don't know. But there are also unknown unknowns. These are things we do not know we don't know.

.

I'm *still* not going to upgrade

[petes_PoV]

My W2K and XP systems.

If this was a ruse to get me to dump them, spend money, go to the hassle of upgrading the O/S and very likely having to replace a whole load of hardware and applications, then sorry guys. You've failed.

Except for the few years it stuck in Ubuntu

[ccham]

No, ignore the problem after all there is plenty of randomness available in Ubuntu. Randomly qualified maintainers fiddling with other randomly qualified maintainer's fiddling of the original maintainer's code. Nothing wrong what so ever with packaging in meta Linux distros...

Let me fix this for you ;)

[davidwr]

I've always assumed any Windows PC I'm using could have been rooted long ago

Corrected version:

I've always assumed any device with a closed-source OS/BIOS/firmware/other code I'm using could have been rooted long ago

There, fixed that for you.

Re:Let me fix this for you ;)

[camperdave]

I highly doubt that my Atari 400 has been rooted.

Re:Let me fix this for you ;)

[The End Of Days]

you could drop the "closed source" part if you wanted to be honest.

Re:Let me fix this for you ;)

[Meski]

There's nothing wrong with having a good root. (slang aussie)

Virtualization to the rescue!

[gblues]

Certainly the best way to eliminate this threat is to do away with the NTVDM altogether and use virtualization, similar to how Windows 7 Pro has "XP Mode." Microsoft should create a virtual HD (*.vhd) file with MS-DOS 6.22 installed on it and then offer it as a free download. Users could either use Virtual PC or the virtualization solution of their choice (VirtualBox, VMWare, etc).

DOSBox is also a decent solution, although it is geared more towards DOS games than to completely and accurately emulating MS-DOS.

Re:Virtualization to the rescue!

[ServerIrv]

Unfortunately a lot of the hardware out there doesn't have VT technology which is a prerequisite for Virtual PC. MS would like to keep a 100% MS solution.

A friend of mine working for LargeCompany couldn't use the company's VPN tech because it only supported 32-bit versions of windows. Wanting to use Virtual PC on his brand new laptop, he purchased and installed Windows 7 Ultimate only to find Virtual PC wouldn't run without VT. After his struggles he asked for my help, and I simply installed VirtualBox and he's on his way. Thankfully he was able to get the student version of Windows 7 for only $25 and wasn't out too much. Well, he also lost his McAfee license due to the reinstall so he needs a new AV solution. Personally I think ridding another computer of McAfee is a bonus rather than a negative.

Re:Virtualization to the rescue!

[toddestan]

I don't see how virtualization eliminates the threat. Sure, your host OS should remain safe, but your virtual install of XP can be pwn3d by this just like if it was running on real hardware. Better not have anything important on your virtual machine.

Re:Virtualization to the rescue!

[gblues]

Reading comprehension: I'm not advocating Virtual XP. I'm suggesting running MS-DOS 6.22 as the guest OS--that is, applying the same methodology as Windows 7's "Virtual XP" mode to use a "Virtual DOS" mode rather than emulating it (poorly) in the kernel via NTVDM.

Excellent News : There is a Patch

[Anonymous Coward]

There is a patch for not only this new bug in Windows, but every other bug, known or unknown. This patch will also boost performance and even removes all of those pesky Windows bugs that is erroniously attributed to open source software such as Firefox, Openoffice.org, etc. Click here for more info about the patch.

Time to ditch legacy code

[derfla8]

Perhaps MS should finally grow some balls and ditch legacy code. Just do it. It's not about what the customer thinks they want, it's about progress. Do it like Jobs.

Oh Snap.

[Anonymous Coward]

That is all.

Wasn't rewritten?

[palmerj3]

So, you mean to tell me Microsoft lied all those times they claimed Windows was rewritten? Didn't see that one coming...

Re:Wasn't rewritten?

[nschubach]

I sometimes tell my boss I had to rewrite code so I can keep up on Slashdot. /joke

Don't understand the hate

[thelonious]

I'm not getting a lot of these posts. Microsoft is a software business, not a computer science business. I think some of you may be confusing one for the other. This is par for the course.

What still needs the Windows 16-bit subsystem?

[Animats]

Does any major software still need the 16-bit subsystem?

Amusingly, when I first installed Windows NT 3.51, back around 1996, the 16-bit subsystem was optional, like the OS/2 subsystem, and I had it turned off. Everything worked fine. In NT 4, they let the kode kiddies from the Windows 95 group put legacy code into NT, some of which still ran in 16-bit mode, and the 16-bit subsystem was always on.

Re:What still needs the Windows 16-bit subsystem?

[colonelxc]

The GRE test software. I wish I was kidding.

Re:What still needs the Windows 16-bit subsystem?

[Anonymous Coward]

You'd be amazed at how many Win32 programs came out in the last 15 years that used Win16 installers.

Re:What still needs the Windows 16-bit subsystem?

[Anonymous Coward]

"Does any major software still need the 16-bit subsystem?"

Games! Tomb Raider, Carmageddon, Blood, and System Shock come to mind. DOSBox's dynamic recompilation isn't as fast as native execution, which is significant if you play at high resolutions. You can those at very high resolutions (Tomb Raider and Carmageddon support 3d acceleration).

Re:What still needs the Windows 16-bit subsystem?

[snowgirl]

Does any major software still need the 16-bit subsystem?

Amusingly, when I first installed Windows NT 3.51, back around 1996, the 16-bit subsystem was optional, like the OS/2 subsystem, and I had it turned off. Everything worked fine. In NT 4, they let the kode kiddies from the Windows 95 group put legacy code into NT, some of which still ran in 16-bit mode, and the 16-bit subsystem was always on.

I've used DOSBox to handle my 16-bit apps on a 64-bit machine.

Re:What still needs the Windows 16-bit subsystem?

[yuhong]

In NT 4, they let the kode kiddies from the Windows 95 group put legacy code into NT, some of which still ran in 16-bit mode, and the 16-bit subsystem was always on.

Nope, I use NT-based Windows a lot, and no I hasn't seen NTVDM pop up in the process list unless I deliberately run a 16-bit Windows or DOS app.

Re:What still needs the Windows 16-bit subsystem?

[SheeEttin]

Does any major software still need the 16-bit subsystem?

Assuming you're referring to Windows, I can tell you that 64-bit Windows XP, which was derived from Server 2003, I believe, has no 16-bit subsystem.
As for major 16-bit software programs, yes, there are still some in use, probably mostly old combinations of hardware and software in specialized fields, especially old control systems. There was one comment on a story a few days back describing such installations, which are still around either because of specialized hardware interfaces or an excessive upgrade cost.

Good thing

[Stan92057]

Good thing im running windows 7 64 bit then :)

Oy vey...yet another reason

[YankDownUnder]

...to run OS/2 Warp4. Yeppers.

MS-DOS 3.3 RULES!!!!!!

[Anonymous Coward]

I'm running MS-DOS right now so I'm really getting a kick out of these comments.

This is how it happens.

[Anonymous Coward]

I used to work for a large defense company. I won't say who, or what project, but think Raytheon (a good sized defense contractor) and set your sights a bit higher.

Our department had a product, and of all the arguments 'round the table about this and that, one that I tried to fight was a bug that could kernel panic the system, regardless of privileges (i.e. you can be any user on the system). Worse, this bug can be invoked on command line, locally. Worse, this command line was a simple derivative of a legit command given in the documentation for common use while using the system. Worse, this episode cemented and reinforced my perception of the evils of proprietary software production and allowing business rationale and management influence design decisions and implementations.

I lost, the bug was never fixed by the time I had left. Even with architecture changes with underlying hardware, the bug propagated through hardware and software product revisions.

Allow me to backtrack for one second. When I was starting out in software development, I got the greatest piece of advice from my then boss; who was and is a very adept engineer. I had to develop a domain whois CGI script, I chose to do it in C. (Follow me here, yeah perl/php/python/ada blah blah blah) Every time I submitted a revision, he broke it. Until one day he said, "If you are going to have an end-user give input, in any way, be prepared to parse and process anything. You can not assume the user even knows what domain syntax is." Basically, if you have the end-user type something on command line, into a input box, or some other text field, make no assumptions and be able to parse anything that might be managed to be inserted into that field.

My program grew thousands of lines once that sunk in. Error handling, string parsing, input validation and sanitation, is the input even ASCII...

So with this ingrained into my psyche, which I think is an extremely valuable concept when designing interactive software, now you can appreciate my frustration when I was told that the bug in question would not be dealt with because the command that invoked it wasn't verbatim with what the documentation said. In a nut shell, the following transpired:

Let's say I make 150 dollars an hour, and it takes me a day to investigate this bug, another day to fix it, and a few more hours to document this, and then we conduct regression testing to make sure changes don't have negative effects elsewhere in the program, that's quite a bit of money the company spends on this problem. If the change is found out by the government testers, then we stand a chance to have to face re-certification (or at least a long delay in current certification processes) which costs even more, not to mention potentially missing our mark for shipping to market resulting in irrecoverable and high lost opportunity costs (LOC). Now, let's say the help desk folks, who make 15 dollars an hour, simply guide the user to type the correct thing in (he spends five minutes doing this), or the end-user follows the documentation and does it himself. The bug never surfaces, and the company doesn't have to spend the extra money or face negative consequences.

They made their decision to ignore this problem using business rationale. I can not underestimate how pissed off I got over this issue, because our product was in use, in the field. It was a part of the military machine, and so lives are at stake as far as I'm concerned. Business rationale my ass, everyone there was salary and it's my opinion that the government get's shafted often by contractors as they attempt to recoup all costs by charging to a authorized project charge number for everything. So the company doesn't really pay the 150 dollars an hour to develop a broken feature, the taxpayer does. But this is how decisions are made when business philosophy interferes with logic, and while my bug won't likely cause an international tragedy, this exact same thing can be transposed over the events leading up to

exploit as published doesn't work

[chentiangemalc]

I've tested the exploit in virtual machine in Windows 7 x32 and Windows XP SP3 and it doesn't work. These are default installs of OS with no config changes. When run in Windows 7 x32 as Administrator it did cause BSOD. Running as standard user it did nothing, the process supposed to have escalated priviliges did not. anybody else found it working?

warning:car analogy ahead

[city]

Exactly. My POS '99 Ford Explorer has a cruise control recall due that apparently causes the car to explode in flames (their words). My point here is that I am sure Ford knew about the problem years in advance and finally broke out their profit/loss calculator after the law suits started piling up and decided it was time to fix it. Design flaws are here to stay, is this a surprise? A for profit company has different legal liabilities (both to the public and their shareholders) than an open source community has.

Are those 3D printers good enough that I can print off an Ubuntu 4-door hybrid yet?

china has forced this out in open

[Anonymous Coward]

haha suckers your backdoors are getting less and less every day

soon there will be only one

Well, you've changed my mind!

[Anonymous Coward]

I was just gonna say "Windows is insecure! Film at 11:00"

But your deeply insightful comment got me thinking and I've amended my response to "Windows sucks! Fuck off shill."

That you know of

[Anonymous Coward]

Just saying.

Windows 9X/ME is not affected by this

[Anonymous Coward]

This new bug does NOT affect ALL 32-bit versions of windows.

Windows 9x/ME systems are not vulnerable to this latest security issue. Again we see how poorly designed the NT-based versions of Windows really is compared to the 9X/ME versions. NT - The emperor has no clothes.

Ur, people using Windows are logged in

[anti-NAT]

and sitting in front of it. Windows is therefore vulernable to every user of Windows. So what makes you trust that everybody whos using Windows can be trusted not to exploit it? Why do they need to lock down desktops in corporate environments if everybody who uses Windows is trustworthy?

As if...

[Simulant]

. 'Using code written for the VDM, an unprivileged user can inject code of his choosing directly into the system's kernel,

As if 99% of all Windows users aren't already running as root.

Workaround for WinXP

[xyu]

Summary of workaround for WinXP:

start->run->gpedit.msc

Navigate to:

Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Application Compatibility -> Prevent access to 16-bit applications

Select "enable".

But how do I secure my PC?

[IceFoot]

The real question is, how do I secure my PC? And don't give me those Policy Groups buzzwords -- how many PC owners know what they mean? Criminy, tell us which files to rename, which registry keys to change, or which services to turn off -- give us something simple and effective.

x64 all the way ! ;) :)

[Anonymous Coward]

I am using x64 so I am ok ;)

You age is showing.

[Anonymous Coward]

People who laughed at your comment also enjoyed the Jack Benny article on todays's front page.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro

[Anonymous Coward]

"How long will we have to wait for MS to do anything about this one? Will they simply suggest people use 64-bit Windows?" - by aztektum (170569) on Wednesday January 20, @11:58AM (#30833872)

You've got a point on THAT much, this is certain (licensed Windows 7 64-bit user here)... Microsoft would do well by doing that, & probably spur/usher-in MORE "64-bit computing" on Personal Computers in doing so.

HOWEVER: This is all that users on Windows need to "adjust" (i.e.-> Simply "rip out" the DOS/Win16 subsystem basically) -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems

(Iirc, that's where any "emulated" subsystems, such as POSIX, exist on ANY form of Windows NT-based OS'...)

APK

P.S.=> It's often suggested for security to do so for the POSIX subsystem, so, this is probably going to shortly be another such suggestion is my guess, for better security (assuming that using some old "legacy app" is not mandatory by a user or company that utilizes Windows)... apk

reason I said closed source

[davidwr]

given enough eyeballs, all bugs are shallow

-Eric S. Raymond, The Cathedral and the Bazaar

test

[Anonymous Coward]

great, I'll test this virus ASAP :-)