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

[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

[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?

[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?

[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?

[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?

[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?

[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?

[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]

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?

[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?

[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?

[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]

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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 ;)

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

[nedlohs]

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

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

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

[nschubach]

To get dates?

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.

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

[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

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

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

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.

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

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:Windows 7

[recoiledsnake]

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

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

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

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

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

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

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

Re:But does it run on Linux?

[bmecoli]

Last I checked WINE doesn't virtualize DOS.

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

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

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.

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.

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.

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

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

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?

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

[BlackPignouf]

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

Re:But does it run on Linux?

[ClosedSource]

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

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

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!

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

.

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

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)

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

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.

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

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.

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?

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?

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

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/

Oy vey...yet another reason

[YankDownUnder]

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

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.

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?

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

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.

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

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.

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.

reason I said closed source

[davidwr]

given enough eyeballs, all bugs are shallow

-Eric S. Raymond, The Cathedral and the Bazaar