| |||||||||||||
The new Java 0Day examined (The H)The new Java 0Day examined (The H)Posted Aug 31, 2012 17:02 UTC (Fri) by smurf (subscriber, #17840)In reply to: The new Java 0Day examined (The H) by HenrikH Parent article: The new Java 0Day examined (The H)
Reverse Sandboxing would help. I.e. you don't park the plugin into a sandbox (though that's also a good idea, albeit harder to implement), but the part of the browser that stores options and handles authorization. (Frankly, what would also help is to learn about the difference between "its" and "it's". Just sayin'.)
(Log in to post comments)
The new Java 0Day examined (The H) Posted Sep 17, 2012 15:41 UTC (Mon) by HenrikH (guest, #31152) [Link]
No it doesn't, since the plugin author has complete control of the computer he can bypass whatever Firefox does, if Firefox implement reverse sandboxing then the plugin will simply do all the steps that Firefox would do when the user clicks the "click OK to really intstall this plugin".
There is _nothing_ that Firefox can do to protect itself from this. _Nothing_.
The new Java 0Day examined (The H) Posted Sep 17, 2012 15:53 UTC (Mon) by khim (subscriber, #9252) [Link] No it doesn't, since the plugin author has complete control of the computer he can bypass whatever Firefox does, if Firefox implement reverse sandboxing then the plugin will simply do all the steps that Firefox would do when the user clicks the "click OK to really intstall this plugin". At this point said plugin is in clear violation of DMCA anti-circumvention provision and should be treated as malware: added to AV-databases (which will block it's installation and will be quickly be updated if new version of plugin will be released), etc. There is _nothing_ that Firefox can do to protect itself from this. _Nothing_. Firefox can not, Mozilla foundation can. I'm not sure if they have enough guts to try, but yes, they can prevent that for most plugins.
|
|||||||||||||