4 ms·

What else did they find? That DOS has problems with memory management? Advances in technology are bound to expose flaws in older products, so what's the news h

by nanijoe 17y ago

What else did they find? That DOS has problems with memory management? Advances in technology are bound to expose flaws in older products, so what's the news here?

btilly 17y ago
Did you read the article? The hole exists in all 32-bit versions of Windows, up to and including Windows 7. So this affects current products. And affects virtually every Windows machine in use on virtually any corporate network. The only good thing about it from the description is that it is a local privilege escalation only.
mfukar 17y ago
It's a flaw that affects recent products.
ams6110 17y ago
I don't think this is a bad observation. My slant on it is, if you are maintaining backwards compatibility to a point in time where these things just didn't matter, because only one person used the machine, there were no multiple user accounts, and the machine was not on a network... it's unsurprising that such an environment would be rife with security holes. Not saying it'a acceptable, just that it's not surprising. Edit: and it appears there's an effective way to mitigate this, disable the 16-bit support in group policy.
- tptacek 17y ago
  In that sense Unix retains compatibility with the '70s. Operating systems are rife with security flaws. Uniformly.
  - rbanffy 17y ago
    Maybe, but the kind of backwards compatibility Windows offers is very unique. It's like being able to run Apple III software natively on a modern Macintosh. ;-) I think IBM can provide a mainframe fresh off the assembly line that can run 70's software. Most amazingly, many do.
- rbanffy 17y ago
  A common PC is a layered monstrosity that can still run nearly every desktop OS made since the early 80's. I would not surprised if every modern chipset had a vestigial cassette port lurking in there for when you wrote "CLOAD" on GWBASIC. I see no reason for a modern x86 (Oh God... What am I saying) to be able to faithfully run code targeted for the 8088. Heck... I am not sure if there is any reason to even support 487 instructions...

by nanijoe 17y ago

What else did they find? That DOS has problems with memory management? Advances in technology are bound to expose flaws in older products, so what's the news here?

btilly 17y ago

Did you read the article? The hole exists in all 32-bit versions of Windows, up to and including Windows 7. So this affects current products. And affects virtually every Windows machine in use on virtually any corporate network. The only good thing about it from the description is that it is a local privilege escalation only.

mfukar 17y ago

It's a flaw that affects recent products.

ams6110 17y ago

I don't think this is a bad observation. My slant on it is, if you are maintaining backwards compatibility to a point in time where these things just didn't matter, because only one person used the machine, there were no multiple user accounts, and the machine was not on a network... it's unsurprising that such an environment would be rife with security holes. Not saying it'a acceptable, just that it's not surprising. Edit: and it appears there's an effective way to mitigate this, disable the 16-bit support in group policy.

tptacek 17y ago
In that sense Unix retains compatibility with the '70s. Operating systems are rife with security flaws. Uniformly.
- rbanffy 17y ago
  Maybe, but the kind of backwards compatibility Windows offers is very unique. It's like being able to run Apple III software natively on a modern Macintosh. ;-) I think IBM can provide a mainframe fresh off the assembly line that can run 70's software. Most amazingly, many do.
rbanffy 17y ago
A common PC is a layered monstrosity that can still run nearly every desktop OS made since the early 80's. I would not surprised if every modern chipset had a vestigial cassette port lurking in there for when you wrote "CLOAD" on GWBASIC. I see no reason for a modern x86 (Oh God... What am I saying) to be able to faithfully run code targeted for the 8088. Heck... I am not sure if there is any reason to even support 487 instructions...