For context, Java will not run by default in any of the 3 major web browsers. In Firefox, it uses Click to Play, requiring you to click on the plugin to load it. In Chrome and IE, it will present a permissions box asking you for permission to run the applet that you can deny.
Does anyone know if this is the infamous 7u51 which will disable unsigned applets from running AT ALL in a browser? (Yes, I know about the whitelist jar)
Let's say this update does everything advertised and more, the perception remains that Java is just not usable in the browser--it's just too dangerous.
Away from testing purposes, the only reason we use IE in the office is so that we can use Webex without Java.
We really need to implement the missing functionality Java applets are providing in plain JS, so applets can die. The last time i absolutely had to implement an applet was to provide my client with this functionality that was not available with pure JS:
- direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fine grained printer control.
- serial/parallel/usb access: access to a POS for card processing, and we needed to write some data on a smartcard.
- plain TCP connections
- read/write files on the local filesystem.
I understand that all these features require more control of the underlying hardware and need to be somehow secured, but we did not want to write a desktop app just for these features, and applets gave us the means to implement what the user needed.
Once JS can do that, applets can die a quick dead.
You mean, what an utter mess the Java Applet Plugin is. And it is, but keep in mind that the Java team signed up for a world of hurt: they produced a design whose attack surface is an entire programming language, complete with networking and a user interface toolkit and all the timers, retention cycles, native code bindings, and other junk that comes with it.
Surely there are several bugs here that aren't specific to the Applet Plugin, but their impact is probably minimal outside of the plugin.
Please note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break. The only thing this allows you to do is to break out of the java sandbox, and keep in mind that most languages don't even pretend that sandbox isolates code (e.g. python/perl/go/... all openly say you can easily break out of the sandbox). So they're trying to solve a really hard problem.
They are indeed trying to solve a hard problem, and they're shackled to a 1990s design.
But I'm not sure I understand the rest of your comment. The threat model for a Java plugin vulnerability is, if your target has the Java plugin enabled, they can't safely browse the web; any page they visit could end up redirecting them to a page with a malicious applet. That's pretty bad.
[+] [-] JohnTHaller|12 years ago|reply
[+] [-] pudquick|12 years ago|reply
[+] [-] rickette|12 years ago|reply
[+] [-] jgalt212|12 years ago|reply
Away from testing purposes, the only reason we use IE in the office is so that we can use Webex without Java.
[+] [-] pjmlp|12 years ago|reply
Talk about security.
[+] [-] hershel|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] y0ghur7_xxx|12 years ago|reply
- direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fine grained printer control.
- serial/parallel/usb access: access to a POS for card processing, and we needed to write some data on a smartcard.
- plain TCP connections
- read/write files on the local filesystem.
I understand that all these features require more control of the underlying hardware and need to be somehow secured, but we did not want to write a desktop app just for these features, and applets gave us the means to implement what the user needed. Once JS can do that, applets can die a quick dead.
[+] [-] skybrian|12 years ago|reply
[+] [-] Joister|12 years ago|reply
[+] [-] beedogs|12 years ago|reply
[+] [-] tptacek|12 years ago|reply
Surely there are several bugs here that aren't specific to the Applet Plugin, but their impact is probably minimal outside of the plugin.
[+] [-] gojomo|12 years ago|reply
[+] [-] mragab|12 years ago|reply
It is all relative
[+] [-] waps|12 years ago|reply
[+] [-] tptacek|12 years ago|reply
But I'm not sure I understand the rest of your comment. The threat model for a Java plugin vulnerability is, if your target has the Java plugin enabled, they can't safely browse the web; any page they visit could end up redirecting them to a page with a malicious applet. That's pretty bad.
[+] [-] taspeotis|12 years ago|reply
[+] [-] InclinedPlane|12 years ago|reply