Hehe. That’s the major attack vector since Januari. Lot’s of bugs allow escalation of privileges, like the buffer overflow in the native code of the MIDI playback.
The vulnerability here isn’t fully Java’s fault and its just Mozilla dumping the blame to avoid any pressure on themselves. The vulnerability is in the SSL/TLS protocol. Basically the Java Applet is getting access to cookies which it shouldn’t have access to (which the browser is happily giving to Java). They could just block the browser from giving the cookies to Java but for whatever reason they want to block the whole Java plugin. Alternatively blocking javascript (or use NoScript) also closes the vulnerability.
A better explanation is found here http://my.opera.com/securitygroup/blog/2011/09/28/the-beast-ssl-tls-issue
IMO WebStart provides a pretty poor end user experience and not really suitable for mass distribution (although its fine for techy/dev ppl). Probably the reason why most popular Java Games/Apps don’t use it.
'Srite - we abandoned it a while ago.
Cas 
That is half true. It is user code, inside the applet, which should not have access to all cookies (depending on restrictions, it is ok to have access to some of them). There are legitimate reasons why JDK libraries, should have access, such as making requests to the websites domain as that user.
Have you talked about that more deeply on IRC security channel with Mozilla guys? Some of them seem to be very motivated to find excuses to block the Java plugin, one of them claim that it would be an answer to some other vulnerabilities. I suspect Mozilla to have already made the decision.
Java applets have been under the radar for a long time and have escaped most of the attention and focus, however they’ve now become a popular attack vector (like activex once became) alot of people are gonna want them dead. Also Oracles slow responses (if any at all) and general bad rep with the open source communities doesn’t help much. As for the Mozilla devs do remember they are mostly old school native code programmers (C/C++) so don’t think you’ll find many Java fans there.
It is insane for the browser to have web sockets and activeX yet try to remove java. It is purely political.
Firefox will just lose more market share. To many companies depend on Applets.
Why not remove MS ActiveX instead since it crashes more than applets.
Also, what happens with Web Sockets if you remove Java Plugins? If they don’t remove ActiveX and Web Sockets then what is the point?
Firefox doesn’t and has never supported activeX. Also web sockets are disabled by default/do not exist because it’s still a buggy unsecure protocol.
ActiveX is only supported in IE, and it has been blocked by default, for a very long.
I’ve also had far more Java plugins crash then VBScripts using ActiveX. The stuff you can do is actually pretty good, it’s just the total lack of security which is the issue with it.
They as in browsers developers.
ActiveX crashes a bunch. Yes it is only IE, but they should remove it since it poses the same issues.
Applets still run in Chrome. I am betting that Firefox won’t remove the plugin and will just do the same thing.
Firefox is not the only browser so Web Sockets is still the same issue.
We’rent we talking about Firefox here :clue:
It doesn’t matter which way you cut it, the Java plugin has become a very large attack vector in browsers. Until this changes, then it should rightly be blocked by browsers.
Ironic considering the massive effort that went into Java security design, sandboxes, permissions, code signing, yadda yadda. And still they fail! I wonder why this hasn’t yet happened to Flash? Or maybe it has.
Cas
An entirely unscientific google for “flash security vulnerability” yields ~7,700,00 hits. It’s been the attack vector of choice for years from what I remember, and only recently seems to have got reasonably secure. And now that all of it’s low-hanging security holes are closed, hackers have moved on to the low-hanging java holes.
Personally I’d blame this on Oracle bolting new stuff onto java too fast, not doing robust security testing, and then dragging it’s feet to actually fix critical vulnerabilities. Sun had a better track record of not letting as many holes into the wild in the first place, and then at least patching them up at a reasonable speed.
If I was a browser developer, I’d be looking at ways to sandbox all browser plugins (java, flash, activeX, silverlight, etc.) in some generic way. Chrome half does this by running everything in different processes, but I’m not sure how you’d lock things down tighter and stop the plugins calling any native api calls they want. Maybe if you proxied all the native calls so they actually go via your browser sandbox via some kind of dll redirection shenanigans? I suspect this would be a huge amount of work though. A more practical way on a *nix box would be to run the plugins in separate processes under a restricted user account, but I suspect this doesn’t work on windows so it’d be a bit pointless since 90% of hacks target windows.
Or maybe as a browser developer I’d be thinking “I already have a language that’s sandboxed in a vm I control - it’s called javascript, why don’t I disable all native plugins and get everyone to migrate to that”. And while theoretically a good move it’s not really very pragmatic given the state of the web.
Ultimately browser developers are in a tough bind IMHO. They’re stuck between several opposed goals (security, functionality, backwards compatibility), and choosing any option is going to leave a large amount of people unhappy.
It’s not only supported on Windows, IE installs a shortcut to run it precisely like that. It’s not the one the average end-user runs by default, because it’s really quite annoying unless you’ve set up the environment to support it (as you might with a kiosk).
The permissions model of operating systems is really a poor fit in today’s environment. To wit: why can’t I easily run apps with a subset of my own permissions? Even stuff like SELinux is about very static contexts without any controls for anyone but system integrators like vendors.
That is what I tried to explain to Mozilla guys. They seem to be pleased to plan to remove the Java plugin, maybe there is something to do to drive such a removal legally harder if we do not succeed in convincing them technically.
With so many security problems with browsers it amazes me that they would blame Java of all things.
Again I think it is mainly politics. I don’t think they will actually do it anymore than chrome has.
There isn’t. They could decide to stop supporting Javascript tomorrow if they felt like it.
It’s not as clear cut as just saying “block access to x”, because often want to allow access under certain conditions.
For example if an applet is to be integrated into the webpage, it should be allowed to make calls to the same domain. This should include all of the cookies that the browser would use, including the HTTP only ones, which are blocked from user access. This means the applet needs access to those cookies under certain circumstances (to make the request), but shouldn’t allow the user to have access. This extends to things like SSL, which where to the current issue also applies.
Same is also true with running plugins in a separate process. You want to more the plugin out, so that it’s more stable and secure, however you also want the plugin to be able to use assets owned by the browser, such as the screen where it is drawn. On MacOS there is currently a bug where the Java applet flickers, because it is unable to get full rights to where it is being drawn, because the security model on Mac OS is much more strict. You want to allow some access, but not all.
All I’m saying is, if it was as simple as “block access to x feature”, then all these security issues would have been solved about 10 years ago. For that reason, it might be more tempting to say “HTML5 is the future” and just block Java, rather then trying to fix these issues.