Vista's Security Rendered Completely Useless By New Exploit

Computer security? Linux is better? Have you forgotten the whole debacle where two lines of the SSL code were removed reducing cryptographic security for the entire operating system to 32,767 possible private keys?

Yeah, I really want these people to be designing my operating system. When utter freaktards comment out bits of subtle and carefully constructed code because they don't know what it does, leading to total security vunerability to all network traffic.

And you have the cheek to call Vista insecure...

http://www.darkreading.com/document.asp?doc_id=154746

evildictaitor said:

Computer security? Linux is better? Have you forgotten the whole debacle where two lines of the SSL code were removed reducing cryptographic security for the entire operating system to 32,767 possible private keys?

Yeah, I really want these people to be designing my operating system. When utter freaktards comment out bits of subtle and carefully constructed code because they don't know what it does, leading to total security vunerability to all network traffic.

And you have the cheek to call Vista insecure...

http://www.darkreading.com/document.asp?doc_id=154746

32,767 private keys is enough for anybody phht!

stevo_ said:

evildictaitor said:

*snip*

32,767 private keys is enough for anybody phht!

But not enough for everybody.

@blowdart - I'm not disputing that this is an interesting Vista exploit. I'm just utterly perplexed as to why corona can harp on about Vista's total flaws in security and gloss over the SSL flaw.

While the flaw in Windows Vista could potentially allow a malicious attacker to compromise your computer when you're browsing the internet, the SSL flaw allowed any encrypted traffic (including traffic with your bank) to be inspected by any computer along the network chain simply by brute forcing your private key against one of their 32,767 pre-computable variants.

Put another way, the Vista hack allows bad guys to install bad software on your machine when you visit their site. The Linux hack allows bad guys to get at your bank account when you visit someone else's site (namely your bank's).

blowdart said:

An interesting analysis

One of the key mechanisms used is the fact that the protections are not always applied. Internet Explorer 7 and Firefox 2 both opt out of DEP, and many third-party libraries such as the Flash plugin opt out of ASLR (and other protection mechanisms). Plugins can also do things that can deliberately defeat the OS's countermeasures; Java, for example, marks all of its memory as executable, meaning that a Java applet can place into memory executable code that's immune to DEP protection. The final trick is to use scripting or plugins to file large amounts of memory with the malicious executable code, so that even when ASLR is in effect, an attacker can still be sure that the malicious code is where he needs it to be. Together, these techniques allow all of the protections found in Vista to be defeated.

So two open source ("Many eyes make it more secure") applications opt out of DEP. Naughty. (Oh and under Vista you can turn DEP on for IE - I have it set that way)

So, basically, it's because the plugins themselves haven't been coded right that these attacks can be carried out? (sorry, the paper wont load for me)

mVPstar said:

blowdart said:

*snip*

So, basically, it's because the plugins themselves haven't been coded right that these attacks can be carried out? (sorry, the paper wont load for me)

A chain is as strong as it's weakest link,....

blowdart said:

An interesting analysis

One of the key mechanisms used is the fact that the protections are not always applied. Internet Explorer 7 and Firefox 2 both opt out of DEP, and many third-party libraries such as the Flash plugin opt out of ASLR (and other protection mechanisms). Plugins can also do things that can deliberately defeat the OS's countermeasures; Java, for example, marks all of its memory as executable, meaning that a Java applet can place into memory executable code that's immune to DEP protection. The final trick is to use scripting or plugins to file large amounts of memory with the malicious executable code, so that even when ASLR is in effect, an attacker can still be sure that the malicious code is where he needs it to be. Together, these techniques allow all of the protections found in Vista to be defeated.

So two open source ("Many eyes make it more secure") applications opt out of DEP. Naughty. (Oh and under Vista you can turn DEP on for IE - I have it set that way)

Are there any drawbacks to turning on DEP for IE? Why is it off by default, anyway?

Bas said:

blowdart said:

*snip*

Are there any drawbacks to turning on DEP for IE? Why is it off by default, anyway?

Because some IE add-ons don't work properly when it's on. Particularly plugins compiled with older versions of ATL will have trouble.

Bas said:

blowdart said:

*snip*

Are there any drawbacks to turning on DEP for IE? Why is it off by default, anyway?

It crashes a lot of third party plug-ins that aren't DEP-compatible.

AndyC said:

Bas said:

*snip*

It crashes a lot of third party plug-ins that aren't DEP-compatible.

So a plugin takes down the entire process for IE? and this exploit it based not on getting around the protection, but literally because the protection is being turned off for arguable legacy reasons in some areas.. or bad design of 3rd party developers?

These silly MAC is more secure comments remind of of the old saying. . .

A man can't stand in a bucket grab the handle and lift himself up.

blowdart said:

evildictaitor said:

*snip*

Ah it's calling it a linux hack I object to; it was a single distro and its children that had the problem

True. The fault was with Debian and all of it's lower distributions.

stevo_ said:

AndyC said:

*snip*

So a plugin takes down the entire process for IE? and this exploit it based not on getting around the protection, but literally because the protection is being turned off for arguable legacy reasons in some areas.. or bad design of 3rd party developers?

It does. An IE plugin is an unmanaged DLL, it gets all privileges IE itself has. It has full access to IE's object model, and could also run all over IE's address space if it wanted to. Detecting faults in a plugin like that and recovering from them in such a way that it leaves the host process (IE) in a consistent state is impossible (it's pretty much a variant of the halting problem, not exactly but similar). Crashing the host process if the plugin faults is the only reasonable thing to do.

Now if IE would natively support .Net plugins that wouldn't always need to be the case (that'd be really nice to have for IE8, for more reasons than just that one).

Sven Groot said:

stevo_ said:

*snip*

It does. An IE plugin is an unmanaged DLL, it gets all privileges IE itself has. It has full access to IE's object model, and could also run all over IE's address space if it wanted to. Detecting faults in a plugin like that and recovering from them in such a way that it leaves the host process (IE) in a consistent state is impossible (it's pretty much a variant of the halting problem, not exactly but similar). Crashing the host process if the plugin faults is the only reasonable thing to do.

Now if IE would natively support .Net plugins that wouldn't always need to be the case (that'd be really nice to have for IE8, for more reasons than just that one).

Now if IE would natively support .Net plugins that wouldn't always need to be the case (that'd be really nice to have for IE8, for more reasons than just that one).

Definitely. I'd be all over writing IE plugins if they were possible to do in .NET. Probably never going to happen, though.

Same thing goes for shell extensions by the way.

Sven Groot said:

stevo_ said:

*snip*

It does. An IE plugin is an unmanaged DLL, it gets all privileges IE itself has. It has full access to IE's object model, and could also run all over IE's address space if it wanted to. Detecting faults in a plugin like that and recovering from them in such a way that it leaves the host process (IE) in a consistent state is impossible (it's pretty much a variant of the halting problem, not exactly but similar). Crashing the host process if the plugin faults is the only reasonable thing to do.

Now if IE would natively support .Net plugins that wouldn't always need to be the case (that'd be really nice to have for IE8, for more reasons than just that one).

Alright makes sense.. surely its possible to write a modular unmanaged process where the hardware manages the memory access rights of each "module"? or is the smallest unit of hardware security guarentee a windows process?