×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Newly-Found Windows Bug Affects All Versions Since NT

Soulskill posted more than 4 years ago | from the staying-power dept.

Windows 393

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

393 comments

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

Anonymous Coward | more than 4 years ago | (#30832200)

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

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

Attack DAWWG (997171) | more than 4 years ago | (#30832294)

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

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

yakumo.unr (833476) | more than 4 years ago | (#30832316)

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

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

jbezorg (1263978) | more than 4 years ago | (#30832330)

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

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

Anonymous Coward | more than 4 years ago | (#30832452)

Windows Sucks. But then you obviously knew that already.

How do we know it's not already in use? (5, Interesting)

jollyreaper (513215) | more than 4 years ago | (#30832206)

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? (5, Interesting)

Skratchez (1304839) | more than 4 years ago | (#30832262)

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? (0)

Anonymous Coward | more than 4 years ago | (#30832320)

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

Re:How do we know it's not already in use? (4, Informative)

clarkn0va (807617) | more than 4 years ago | (#30832504)

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? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30832534)

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

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

Re:How do we know it's not already in use? (5, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30832606)

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 [kerneltrap.org]. 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? (0)

Anonymous Coward | more than 4 years ago | (#30832928)

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

Re:How do we know it's not already in use? (2, Informative)

TheCycoONE (913189) | more than 4 years ago | (#30833002)

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? (2, Insightful)

plague3106 (71849) | more than 4 years ago | (#30832890)

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? (2, Informative)

Nadaka (224565) | more than 4 years ago | (#30832716)

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? (2, Insightful)

Jesterace (914041) | more than 4 years ago | (#30832276)

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? (3, Insightful)

clarkn0va (807617) | more than 4 years ago | (#30832364)

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? (0)

Anonymous Coward | more than 4 years ago | (#30832474)

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

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

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

Anonymous Coward | more than 4 years ago | (#30832704)

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

Re:How do we know it's not already in use? (3, Informative)

John Hasler (414242) | more than 4 years ago | (#30832932)

> 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? (1)

Frans Faase (648933) | more than 4 years ago | (#30833008)

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? (2, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#30832302)

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? (2, Insightful)

Dynedain (141758) | more than 4 years ago | (#30832318)

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? (1)

timeOday (582209) | more than 4 years ago | (#30832462)

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? (1)

think_nix (1467471) | more than 4 years ago | (#30832486)

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? (5, Interesting)

think_nix (1467471) | more than 4 years ago | (#30832392)

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? (4, Interesting)

Xest (935314) | more than 4 years ago | (#30832742)

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? (2, Interesting)

maxume (22995) | more than 4 years ago | (#30832422)

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? (2, Funny)

John Hasler (414242) | more than 4 years ago | (#30833004)

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? (0)

Anonymous Coward | more than 4 years ago | (#30832598)

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

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

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

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

But does it run on Linux? (-1, Redundant)

oodaloop (1229816) | more than 4 years ago | (#30832220)

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

Someone had to say it though.

Re:But does it run on Linux? (1)

0racle (667029) | more than 4 years ago | (#30832350)

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

Re:But does it run on Linux? (0)

Anonymous Coward | more than 4 years ago | (#30832508)

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

Don't be a twit

Re:But does it run on Linux? (1)

psbrogna (611644) | more than 4 years ago | (#30832538)

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

Re:But does it run on Linux? (1)

plague3106 (71849) | more than 4 years ago | (#30832966)

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? (3, Informative)

recoiledsnake (879048) | more than 4 years ago | (#30832402)

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 [zdnet.com]

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

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

Re:But does it run on Linux? (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30832656)

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

Re:But does it run on Linux? (3, Insightful)

PitaBred (632671) | more than 4 years ago | (#30832880)

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

Re:But does it run on Linux? (1)

jetxee (940811) | more than 4 years ago | (#30832984)

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?

Small, small world... (2, Interesting)

Zocalo (252965) | more than 4 years ago | (#30832894)

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

I was RIGHT ! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30832222)

Don't just dump IE.

Dump MicroSLOP [microsoft.com]
completely !

Yours In Novosibirsk,
K. Trout

Re:I was RIGHT ! (1, Funny)

Anonymous Coward | more than 4 years ago | (#30832662)

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.

Doesn't affect 64-bit? (1)

Anonymous Coward | more than 4 years ago | (#30832308)

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

Backward compatibility (5, Insightful)

recoiledsnake (879048) | more than 4 years ago | (#30832338)

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

Re:Backward compatibility (2, Insightful)

sys.stdout.write (1551563) | more than 4 years ago | (#30832396)

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

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

Re:Backward compatibility (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30832558)

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

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

That's the "what made Microsoft" part.

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

Re:Backward compatibility (1)

Taevin (850923) | more than 4 years ago | (#30832658)

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 (2, Interesting)

NJRoadfan (1254248) | more than 4 years ago | (#30832874)

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 (2, Funny)

sacrilicious (316896) | more than 4 years ago | (#30832700)

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

There, fixed that for ya. :)

Re:Backward compatibility (1)

JustOK (667959) | more than 4 years ago | (#30832814)

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

64 Bit (1, Funny)

ZeroSerenity (923363) | more than 4 years ago | (#30832358)

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 (1, Informative)

Anonymous Coward | more than 4 years ago | (#30832394)

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 (3, Informative)

simcop2387 (703011) | more than 4 years ago | (#30832544)

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 (1)

EvanED (569694) | more than 4 years ago | (#30832576)

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

maeka (518272) | more than 4 years ago | (#30832408)

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 (1, Funny)

Anonymous Coward | more than 4 years ago | (#30832512)

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

Re:64 Bit (1)

simcop2387 (703011) | more than 4 years ago | (#30832604)

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 (0)

Anonymous Coward | more than 4 years ago | (#30832682)

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

Re:64 Bit (0)

Anonymous Coward | more than 4 years ago | (#30832980)

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

Re:64 Bit (4, Informative)

TeknoHog (164938) | more than 4 years ago | (#30832414)

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 (1)

0racle (667029) | more than 4 years ago | (#30832472)

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 (1)

Jugalator (259273) | more than 4 years ago | (#30832516)

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 (1)

TheRaven64 (641858) | more than 4 years ago | (#30832696)

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 (1)

Nadaka (224565) | more than 4 years ago | (#30832784)

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.

Windows 7 (0)

wwwillem (253720) | more than 4 years ago | (#30832400)

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

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

Re:Windows 7 (2, Informative)

recoiledsnake (879048) | more than 4 years ago | (#30832556)

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

Re:Windows 7 (1)

filesiteguy (695431) | more than 4 years ago | (#30832802)

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

Re:Windows 7 (0)

Anonymous Coward | more than 4 years ago | (#30832942)

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

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

32 bit? (1)

Ralz (1634999) | more than 4 years ago | (#30832420)

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

Does it affect IE8? (1)

gmuslera (3436) | more than 4 years ago | (#30832436)

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? (1)

TheRaven64 (641858) | more than 4 years ago | (#30832734)

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.

Only 32-bit Windows builds? (1)

Jugalator (259273) | more than 4 years ago | (#30832484)

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? (1)

Jugalator (259273) | more than 4 years ago | (#30832542)

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

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

windows 7 64bit (2, Informative)

axor1337 (1278448) | more than 4 years ago | (#30832518)

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 (1)

Chaos Incarnate (772793) | more than 4 years ago | (#30832660)

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

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

Just in time (0)

Anonymous Coward | more than 4 years ago | (#30832526)

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

What about other NT archs? (0)

Anonymous Coward | more than 4 years ago | (#30832618)

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

"OSs released since 1993" (3, Funny)

Dystopian Rebel (714995) | more than 4 years ago | (#30832632)

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" (0)

Anonymous Coward | more than 4 years ago | (#30832822)

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

Re:"OSs released since 1993" (1)

arhhook (995275) | more than 4 years ago | (#30832998)

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!

How long until we see the NT4 patch? (2, Interesting)

gimmebeer (1648629) | more than 4 years ago | (#30832636)

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

WOWEXEC is still in use? (2, Funny)

filesiteguy (695431) | more than 4 years ago | (#30832670)

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

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

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

Many Eyes vs. Zero Eyes (0)

Anonymous Coward | more than 4 years ago | (#30832774)

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

Brought it on yourself (1, Insightful)

zookeeperme (1722156) | more than 4 years ago | (#30832776)

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

Old School (1)

GreenTom (1352587) | more than 4 years ago | (#30832852)

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

Re:Old School (1)

idontgno (624372) | more than 4 years ago | (#30832968)

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.

WARNING: Technical stuff follows (4, Informative)

idontgno (624372) | more than 4 years ago | (#30832908)

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 [sans.org]. 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 (1)

idontgno (624372) | more than 4 years ago | (#30833070)

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

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

Anonymous Coward | more than 4 years ago | (#30833000)

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

Warning: Clueless editor writes panic headline (2, Insightful)

flerlerp (447410) | more than 4 years ago | (#30833038)

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

Just a matter of time before... (1)

robot256 (1635039) | more than 4 years ago | (#30833062)

...the German and French governments advise their citizens against using Windows altogether, not just Internet Explorer.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...