Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Posted Sep 12, 2013 8:32 UTC (Thu) by skitching (guest, #36856)In reply to: Security of Java takes a dangerous turn for the worse, experts say (ars technica) by eru
Parent article: Security of Java takes a dangerous turn for the worse, experts say (ars technica)
A server-side app can *potentially* use the sandbox to isolate possibly hostile code running within the same process (eg an app running plugins provided by customers, which might try to mess with the app's internals). Oracle's database allows stored procedures to be implemented in Java; I wouldn't be too surprised to find that the database uses a sandbox to prevent such stored procedures from messing with too much. However the vulnerability linked to in the article (related to the 2D graphics API) is unlikely to be available ;-)
The sandbox is used extensively for applets, and this is where users can be bitten by these issues. However very few mainstream language even *attempt* to provide a sandbox environment in which totally untrusted code can be run; javascript in a browser is one - and that also has a regular stream of problems.
ActiveX doesn't bother with a sandbox at all. ActiveX relies on users "trusting" the publisher of the signed plugin; Java supports this model too : *plus* a sandbox.
Re the "banking applets" discussion below: presumably these applets are all *signed* by the bank that provides them. There is therefore no real issue; the user can trust the bank, and the sandbox is actually irrelevant. If a bank customer doesn't trust their bank sufficiently to install software signed by them, they should move to a different bank.
So in short: these security issues only bite people who install applets which are unsigned or signed by untrustworthy providers which *then* exploit a sandbox hole.
Having said that, I am partially guilty of the above from time to time. In particular, some concert/theatre ticket selling companies and airlines use graphical Java applets for seat-selection. Not all these applets are properly signed, and the providers aren't "high trust" companies like banks. However even then, I mostly trust these companies.
Posted Sep 12, 2013 16:01 UTC (Thu)
by luto (guest, #39314)
[Link]
Posted Sep 12, 2013 17:50 UTC (Thu)
by dps (guest, #5725)
[Link] (3 responses)
Instead Java allows you to decide which privileges on a small list the signature should confer: you could allow a signed applet to use your printer but not access your hard disc, modulo UI designers deeming this too complex for normal users and only supporting something simpler. This might mean that even a signed applet can print but can't find your M$ money installation and bill your credit card.
In terms of seat booking and similar application I can't see the need to do anything not permitted inside the sandbox. What beyond communicating with the originating server and drawing a pretty picture, which is activity allowed inside the sandbox, do these applications need? Most banking applications probably should not be doing much beyond that too.
Posted Sep 12, 2013 21:17 UTC (Thu)
by luto (guest, #39314)
[Link] (2 responses)
(I'm talking about JNLP apps here, which are more common in my industry. Actual applets are probably better.)
Posted Sep 13, 2013 18:34 UTC (Fri)
by jonabbey (guest, #2736)
[Link] (1 responses)
Posted Sep 21, 2013 10:57 UTC (Sat)
by luto (guest, #39314)
[Link]
Posted Sep 13, 2013 18:32 UTC (Fri)
by jonabbey (guest, #2736)
[Link]
The same dialog warns that in a future release of Java, non-signed / self-signed JNLP apps will just not work anymore. We've been self-signing our Ganymede client and admin console JNLP apps all along in the lab, but that's not going to be enough going forward.
It seems that Oracle has had enough bad press about Java, and are getting serious about tightening things up.
It'll be a hassle for us, having to get a code-signing cert, but maybe folks will change their mind about the safety / reliability of Java?
(spoiler: I don't really believe those who like to slam Java will change their minds ever at this point).
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)
Security of Java takes a dangerous turn for the worse, experts say (ars technica)