LWN: Comments on "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)

wookey — Wed, 16 Oct 2013 16:08:43 +0000

The (arguably misnamed) quickjava plugin gives you a row of buttons to quickly enable/disable any of javascript, java, silverlight, images, flash, cookies, animations and styles/css. I find this exceedingly useful.

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

gnu_andrew — Sat, 21 Sep 2013 19:40:34 +0000

It should be noted that this is implicitly referring to the proprietary Oracle JDK 6. OpenJDK 6 still gets updates from us at Red Hat.

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

luto — Sat, 21 Sep 2013 10:57:17 +0000

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)

Per_Bothner — Sat, 21 Sep 2013 07:27:54 +0000

Of course it's not literally impossible to implement full tail-call optimization on the JVM - it's just harder. Kawa has long done so. It uses a special calling convention, using a thread-specific CallContext object. This calling convention is optional, because it is slower, and doesn't interoperate with "native" Java as directly - you enable it using an optional --full-tailcalls flag. (Note you can mix code compiled with --full-tailcalls and --no-full-tailcalls.) (Also note that Kawa even with full tailcalls enabled is still generally faster than Clojure.)

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

ThinkRob — Thu, 19 Sep 2013 15:27:50 +0000

Apparently simply writing in a language makes me a fanboy. Who knew?

Yes, C# requires fewer lines. I wasn't playing code golf though; I was responding to the claim that it was hard to write an iterator. It's not. It may not be as few lines as you'd like, but it's not hard -- or at least it shouldn't be for anyone who knows the language well enough to be writing more than Hello World in it.

It's worth noting that C# isn't burdened by the same backwards-compatibility requirements that Java is. There's a *lot* of parts of Java that could be better if they were allowed to introduce breaking changes (the Collections API comes to mind), but that's the curse of being first I suppose.

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

Arker — Wed, 18 Sep 2013 16:14:33 +0000

They should really look at Nordea's system and borrow it somehow instead of reinventing the wheel, badly.

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

Arker — Wed, 18 Sep 2013 12:10:16 +0000

For the best bank interface I have seen look at nordea.se. Very secure logins and works fine with plain old html - www - browser technology requiring neither plugins nor ecmascript.

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

dlang — Tue, 17 Sep 2013 19:12:34 +0000

oops, wrong thread, sorry

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

dlang — Tue, 17 Sep 2013 19:11:50 +0000

hmm, I've been running modified tivos for over a decade.

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

jonabbey — Tue, 17 Sep 2013 18:56:50 +0000

The StackOverflow link does a good job talking about the problem. Clojure gets around this by having explicit loop and recur statements that the Clojure compiler uses to set up trampolines as needed for recursion.

Without having JVM-level support, though, you do lose some tooling support and flexibility. It would make a very nice addition to the JVM, albeit more work to do than the invokedynamic feature that was added in Java 7 to support dynamic languages on the JVM.

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

HelloWorld — Tue, 17 Sep 2013 12:04:32 +0000

That's the kind of workaround I was referring to, it breaks for non-trivial cases, for example when it's not known at compile time which function implementation a call will end up in.

scala> import scala.annotation.tailrec
import scala.annotation.tailrec

scala> class Test {
     |   @tailrec def apply { apply }
     | }
<console>:9: warning: method apply in class Test does nothing other than call itself recursively
         @tailrec def apply { apply }
                              ^
<console>:9: error: could not optimize @tailrec annotated method apply: it is neither private nor final so can be overridden
         @tailrec def apply { apply }
                      ^

It fails even for simple mutually recursive definitions:

scala> @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)
<console>:10: error: @tailrec annotated method contains no recursive calls
       @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)
                    ^
<console>:10: error: @tailrec annotated method contains no recursive calls
       @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)

It's not just about tail *recursion* optimization, it's about general tail *call* optimization. JVM modifications are needed to make this kind of thing work.

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

peter-b — Tue, 17 Sep 2013 11:50:09 +0000

There's an interesting question on Stack Overflow that covers this:

http://stackoverflow.com/questions/105834/does-the-jvm-pr...

Don't forget that "true" tail call optimization implies that *any* tail call can be optimized, not just the self-recursion<->loop case.

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

eru — Tue, 17 Sep 2013 10:34:45 +0000

Makes it literally impossible to implement a Scheme on top of the JVM, for example (the Scheme spec *requires* tail call optimization).

Now I'm curious: How can the JVM prevent tail call optimization? After all, it is just a matter of updating the variables that correspond to the parameters of the function, and then executing a goto to its start. And the JVM (being a low level language) has a goto.

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

jezuch — Tue, 17 Sep 2013 08:40:23 +0000

> I'm sorry, you Java fanboys are just pathetic. Here's the C# source code to do the same thing:

Giving an example that is easier does not mean that the original example is not easy.

Now, the *real* problem with the original example is that it's a simple adapter. If the iterator is supposed to do some filtering, then it becomes significantly less easy. That's when I long for yield in Java :) But the upcoming lambda support in Java 8 is supposed to make this much, much easier and effectively eliminate the need for implementing iterators thus making yield insignificant.

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

peter-b — Tue, 17 Sep 2013 05:15:38 +0000

> No tail call optimization, so compiler authors need to work around that, which is basically impossible except for simple cases

Makes it literally impossible to implement a Scheme on top of the JVM, for example (the Scheme spec *requires* tail call optimization).

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

HelloWorld — Mon, 16 Sep 2013 23:25:24 +0000

The problem with Scala and Clojure is that they are hampered by the inadequacies of the JVM.

Structural types in Scala are slow (use introspection because the JVM doesn't allow for a class to retroactively implement an interface (Sun's "fix" for that is java.lang.reflect.Proxy, which is really just an ugly hack))
generics on the JVM suck
- introspection is broken, something like foo instanceof Bar<Baz> doesn't work)
- crazy inefficiencies due to boxing (an ArrayList<Byte> requires around 4 machine words per byte of payload) leading to hacks like GNU Trove or Scala's
no support for value types, so crazy inefficient if your objects are small (and let's not talk about the fact that every object carries around a lock, even if it's never accessed concurrently)
the type system is fucked up (covariant mutable arrays, wtf? And they have covariant return types, but no contravariant argument types (except if the argument happens to be this, yeah, that makes sense. Not.))
No tail call optimization, so compiler authors need to work around that, which is basically impossible except for simple cases

And that list isn't even exhaustive.

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

HelloWorld — Mon, 16 Sep 2013 22:51:09 +0000

I'm sorry, you Java fanboys are just pathetic. Here's the C# source code to do the same thing:

public static IEnumerator<T> foo<T>(T[] bar) {
  foreach(var x in bar)
    yield return bar;
}

And of course it's easy to write this if all you're doing is iterating over an array. But things become much harder if you actually write an iterator that does something interesting. The C# (or Python) compiler actually helps you to get the control flow right, while Java is just in the way.

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

ThinkRob — Mon, 16 Sep 2013 16:51:21 +0000

It's not using iterators that's hard, it's writing one.

It's not hard. It's three methods, and one of those (#remove()) is optional. Here's an implementation of an array iterator. Works for any array:

public class ArrayIterator<T>
implements Iterator<T>
{
	private int index = 0;
	private final T[] array;
	
	public ArrayIterator(T[] array)
	{
		this.array = array;
	}
	
	@Override
	public boolean
	hasNext()
	{
		return this.index < this.array.length;
	}
	
	@Override
	public T 
	next()
	{
		if (this.index < this.array.length)
		{
			return this.array[this.index++];
		}
		
		throw new NoSuchElementException();
	}
	
	@Override
	public void
	remove()
	{
		throw new UnsupportedOperationException();
	}
}

Not too difficult. Wordy, perhaps, but certainly not hard to write.

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

marcH — Sat, 14 Sep 2013 19:55:52 +0000

Excellent news (to me), thanks!

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

alankila — Sat, 14 Sep 2013 10:25:22 +0000

Here's a stupid anecdote against Python I ran into recently. Last thursday, I thought to write a little TCP server in Python. Unix command output was to be sent over tcp socket. It boiled down to something like this:

>>> import subprocess, gzip; subprocess.Popen(args="/bin/ls", stdout=gzip.GzipFile("testfile", "wb")).communicate()
(None, None)

The intent of code is hopefully clear. I should have a gzipped output 'testfile' of the command of /bin/ls. Unfortunately to me, Popen() calls fileno() on GzipFile and steals the handle from it, and writes uncompressed data bracketed by gzip gunk for 0-byte file. So, GzipFile shouldn't implement fileno(), or someone shouldn't play fast and loose with Popen and should rather read from the stdout/stderr pipes during communicate() and use the correct abstraction of file.write to write when a file object is passed in.

At least java's abstractions generally work correctly...

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

Fowl — Sat, 14 Sep 2013 02:19:50 +0000

Click to play is on by default for many plugins and configurable for all in current versions of Firefox.

https://blog.mozilla.org/security/2013/01/29/putting-user...

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

marcH — Sat, 14 Sep 2013 01:17:54 +0000

> Unless one has a click-to-activate policy...

I only recently found the "click to play" feature in Chrome. I heard about it by chance. Whereas this perfect feature should be enabled by default it's completely buried way down in the settings: ridiculous.

On Firefox it's much worse since you have install the FlashBlock plugin. Is there even a "JavaBlock" Firefox plugin or better, a generic "click to play" plugin?

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

jonabbey — Fri, 13 Sep 2013 18:34:56 +0000

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)

jonabbey — Fri, 13 Sep 2013 18:32:59 +0000

Wow. What do you prefer?

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

jonabbey — Fri, 13 Sep 2013 18:32:24 +0000

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

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

jonabbey — Fri, 13 Sep 2013 18:25:41 +0000

I hear a lot of great things about Scala, including from some of my co-workers who are developing with it.

For myself, I'd preferentially choose to work with Clojure, but most of my Java work is in Ganymede, an open source network directory management framework, and I don't want to scare away the few people that seem inclined to adopt it by making them grok Lisp.

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

smurf — Fri, 13 Sep 2013 14:47:51 +0000

> The German tax administration has it in their online services

Happily, for the most common uses this Java thing can be avoided; there is an implementation of the Elster protocol (which for the most part is actually documented(!!!)) which does the same thing in HTML5 and JS, as a Firefox app ("Geierlein").

Aside: "Elster" is supposed to be an acronym. It is also the German name for the magpie, a bird _not_ known for leaving your belongings alone, esp. small shiny valuable ones. It's a mystery how the IT people at the (normally quite humor-challenged) German tax office got away with that.

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

Lennie — Fri, 13 Sep 2013 10:24:49 +0000

Just be glad you don't live in South Korean, I believe banks still use ActiveX there.

Here is an article from 2008 that described what it was like:
http://asia.cnet.com/blogs/google-chrome-will-support-act...

I don't know if it has been solved, but the problem still existed at the end of 2012:
http://en.wikinews.org/wiki/South_Korean_presidential_can...

It might even be one of the reasons WebCrypto workgroup exists:
http://www.w3.org/2012/webcrypto/

http://www.w3.org/community/webcryptoapi/2012/03/28/a-dra...

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

ibukanov — Fri, 13 Sep 2013 06:50:05 +0000

> Sounds surprisingly complex, is that really needed?

It is useless... Successful attacks against Norwegian banks often involved malware that just replaced the HTML on the login page with own form that sends the login credentials to a remote server. There an operator manually enter the login information into own browser window and do the payment. Then, to confirm a payment, they tricked the user to enter an extra credentials claiming a security check.

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

eru — Fri, 13 Sep 2013 06:24:02 +0000

BankId implementation uses that to check for common malware infections and to fingerprint the computer. Also, for malware it is harder to subvert their code. Banks do not want to give up on that yet.

Sounds surprisingly complex, is that really needed?

The Finnish bank I use (Nordea) has used for decades an authentication that can be implemented with a bare HTML form (or with a TTY for that matter, it actually started that way): For login, a userid, and a single-use 4-digit code stored offline (you pick the next one from a piece of paper the bank sends you now and then). Transactions also require a final confirmation code, which is not single-use, but chosen from a set of 18 (the bank sends you a single letter as a challenge, you respond with the corresponding 4-digit code from the aforementioned piece of paper). Pretty low-tech, no applets needed. Most other Finnish banks also use something similar.

I have not yet heard of any attack against this that did not involve social engineering. A few years ago, a phishing mail managed to persuade some people to send their id, the next 10 or so login codes and the confirmation codes (this has always surprised me, because it is a lot of work to enter that much data, one would have expected warning bells to start ringing in the mind of the "mark" around entering the 5. code or so).

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

khim — Thu, 12 Sep 2013 22:47:54 +0000

Well, if you use Java6 with recent version of Firefox then Java applets are permanently disabled but you can enable them on specific website if you notice red lock in the location bar. This actually makes Java6 safer choice then Java7 for the users who only need Java for banks :-)

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

khim — Thu, 12 Sep 2013 22:43:09 +0000

Still, given how bad the situation with Java, I would not be surprised that after few successful fraud attempts against big customers, banks change their mind.

A few banks already did that and now instead of Java applet offer… regular .exe binary which must be installed with Admin privileges because it basically stops everything else on a system while it's running (it disables most network interfaces, removes all routes except routes needed to reach the server, freezes “suspicious programs”, etc).

This looks onerous, but I can kind of understand why they are doing this: my sister is accountant and she sometimes enlist my help in fixing the computers of her fellow accountants. Usually they are infected by literally dozens of viruses and trojans which, of course, makes them somewhat slower. AV software is installed and usually even tries to complain but is silenced “because it's popups make work impossible”.

Frankly this picture makes me sad: we are talking about backdoors and weaknesses in cryptographic standards but what does it change if people are this ignorant?

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

luto — Thu, 12 Sep 2013 21:17:39 +0000

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)

juhah — Thu, 12 Sep 2013 21:12:44 +0000

I'd like to point out that Java 8 will improve syntax little in some cases:
Arrays.asList(1,2,3,4,5,6).stream().map(n -> n * n);

That said, Java syntax will still be far from python elegance, in general.

What is perhaps more interesting is JVM, not Java. Go checkout Clojure and Scala if you haven't heard of them yet. And how they all compare:
http://benchmarksgame.alioth.debian.org/

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

luya — Thu, 12 Sep 2013 20:44:33 +0000

Which version of Firefox? On Windows version, Java is automatically disabled due to its vulnerability. I don't know about Linux version because my system only runs openjdk based Java.

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

dps — Thu, 12 Sep 2013 17:50:53 +0000

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)

pboddie — Thu, 12 Sep 2013 16:54:23 +0000

The "check for common malware infections and to fingerprint the computer" is one reason why I always run BankID in some kind of sandbox. I presume that as an implementer one can always make an argument for sniffing around on a person's computer for "security" reasons and to "look after them" in this way, but it's obviously intrusive especially when the actual operations being performed are kept secret (reverse engineering notwithstanding).

The dialogue that gets shown when one has to accept the elevated privileges of the signed applet under certain versions of the Java VM says it all when it tells you that the applet needs access to your system including your webcam. Naturally, the webcam thing is an artefact of Java's "cool" multimedia past, but in this situation it just underlines the creepy nature of a banking login mechanism wanting to poke around on a user's computer.

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

luto — Thu, 12 Sep 2013 16:01:26 +0000

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)

drag — Thu, 12 Sep 2013 15:08:33 +0000

Nowadays when I see something like this I think of this quote:

"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
-- C.A.R Hoare

Therefore if you want to have a secure login or something like that for a bank the goal is to avoid javascript, java, html5, etc etc.. as much as possible. I don't think there is a way to make these sorts of technologies actually secure.

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

jhhaller — Thu, 12 Sep 2013 14:20:40 +0000

The real problem with applets is that if one needs to use an applet, Java needs to be enabled in the browser, which subjects one to drive-by-downloads. Unless one has a click-to-activate policy which is always enforced, unlike the Firefox approach of "we don't know of any vulnerabilities in this version of Java yet, so lets run the applet from trojanhorsespyware.com", drive-by downloads are still a problem. It's too much to expect people to only enable Java applets just for the sites that need it, then to immediately disable them.