Coffeehouse Thread

53 posts

Vista's Security Rendered Completely Useless By New Exploit

Back to Forum: Coffeehouse
  • User profile image
    evildictait​or


    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

  • User profile image
    stevo_

    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! Wink

  • User profile image
    blowdart

    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
    Come now, SSL isn't part of the kernel per se, it was a distro problem. This is more serious in that it seems to attack the kernel protection methods. Getting around DEP is very interesting; but address randomisation is a problem for every OS if it proves to be portable.

  • User profile image
    evildictait​or

    stevo_ said:
    evildictaitor said:
    *snip*
    32,767 private keys is enough for anybody phht! Wink
    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).

  • User profile image
    blowdart

    evildictaitor said:
    stevo_ said:
    *snip*
    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).
    Ah it's calling it a linux hack I object to; it was a single distro and its children that had the problem

  • User profile image
    blowdart

    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)

  • User profile image
    MasterPi

    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)

  • User profile image
    Maddus Mattus

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

  • User profile image
    Bas

    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?

  • User profile image
    Sven Groot

    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.

  • User profile image
    AndyC

    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.

  • User profile image
    stevo_

    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?

  • User profile image
    wisemx

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

  • User profile image
    evildictait​or

    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.

  • User profile image
    Sven Groot

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

  • User profile image
    Bas

    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.

  • User profile image
    stevo_

    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?

  • User profile image
    littleguru

    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).
    Why don't I expect IE8 to ship with support for .NET addins... hmmm...

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.