User: Password:
|
|
Subscribe / Log in / New account

The new Java 0Day examined (The H)

The new Java 0Day examined (The H)

Posted Aug 30, 2012 18:19 UTC (Thu) by dashesy (guest, #74652)
In reply to: The new Java 0Day examined (The H) by Kit
Parent article: The new Java 0Day examined (The H)

I agree it does not seem to be straight forward. However if the setting is something user visible in a menu (as opposed to some obscure about:config), and another setting warns about possible outsider intrusions, the user will notice it, and will require bolder plugin developers to sneak in with their installers (and subdue the warning).

As a rule of thumb, any plugin that does not have an easy "uninstall" or "update" should be blacklisted with a big warning (e.g. "Firefox is tainted by ...") somewhere visible (maybe in the caption title) until disabled by user, or fixed by developer.


(Log in to post comments)

The new Java 0Day examined (The H)

Posted Aug 30, 2012 22:29 UTC (Thu) by HenrikH (subscriber, #31152) [Link]

The problem is that these plugins installers are sneaky. Their developers have figured out how Firefox stores "this plugin is new" somewhere in it's profile and it changes that value to look like the user has OK:ed it so it goes in silently.

Not even crypto signing would work here since the private key must be found on the machine somewhere for Firefox to update it's own profile and the plugin installers would thus also find it.

The new Java 0Day examined (The H)

Posted Aug 31, 2012 7:48 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Right, what's going on here is a "blame the victim" mentality.

From the outset other applications have deliberately tried to sneak past Firefox's built-in restrictions.

That's because those applications are _malware_ and the technical community's failure to react correctly to that is our fault.

When Microsoft did this we got the victim blaming "Firefox should have better defences" as if the application developer can protect their app against the OS vendor. What we should have seen was an outcry until Microsoft put some heads on the block. "My predecessor lost their job for that" is a surprisingly powerful incentive not to behave unethically.

If you could name a handful of senior figures at Microsoft who had left the industry because of that "clever" but quite obviously unethical trick, this wouldn't now be so popular. But instead Windows programmers (for it's always Windows) know that whatever they do to Firefox the technical community will say "Well, Firefox deserved it" and the victim gets the cleanup bill.

The new Java 0Day examined (The H)

Posted Aug 31, 2012 17:02 UTC (Fri) by smurf (subscriber, #17840) [Link]

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

The new Java 0Day examined (The H)

Posted Sep 17, 2012 15:41 UTC (Mon) by HenrikH (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds