|
|
Subscribe / Log in / New account

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)

These are all security issues related to the Java sandbox. Server-side Java applications don't usually bother with setting up a sandbox, so these issues are irrelevant for them.

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.


to post comments

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 16:01 UTC (Thu) by luto (guest, #39314) [Link]

This is, unfortunately, barely true. Did you know that, when you run a signed Java Web Start app, there's no sandbox at all? I didn't for quite a while, because the UI appears to have been designed by ActiveX engineers. (Why IcedTea isn't better is a mystery to me.)

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 17:50 UTC (Thu) by dps (guest, #5725) [Link] (3 responses)

The support for signed applets in Java is at least potentially better than what active X did. Active X always provided all privileges to the code, which was trusted by default if a company signed it.

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.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 21:17 UTC (Thu) by luto (guest, #39314) [Link] (2 responses)

Really? The *app* can decide on what privileges it wants, but (unlike Android, for example), the user doesn't seem to get any indication of what the app requested.

(I'm talking about JNLP apps here, which are more common in my industry. Actual applets are probably better.)

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 13, 2013 18:34 UTC (Fri) by jonabbey (guest, #2736) [Link] (1 responses)

Try running 'jcontrol' on your box, it's a seldom-noticed Java control panel that lets you adjust what kind of security permissions you're willing to give away to JNLP apps and etc.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 21, 2013 10:57 UTC (Sat) by luto (guest, #39314) [Link]

jcontrol appears to be part of a speech recognition package. There's itweb-settings.itweb, which is some combination of useless and incomprehensible.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 13, 2013 18:32 UTC (Fri) by jonabbey (guest, #2736) [Link]

Starting in the Java update that Oracle put out this week (Java 7.0_40), all JNLP apps that are not code-signed using a cert from a recognized CA get big scary warning dialogs whenever you run them, with no way to say that you accept the cert on an ongoing basis.

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


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