JavaFX security

I had some concerns regarding JavaFX security. You know, if you go to JavaFX samples page, most of them are self-signed and you have to give them all permissions to be able to run them. I didn’t like it at all. On Devoxx I asked few guys from Sun about it and their responses were not clear. So I have decided to do few experiments to find out how it works. It’s nothing new, it’s similar to the way applets have worked all the time. But who remembers how applet security works?

I took InterestingPhotos sample application from JavaFX pages and added following code to onNext function (behold, my very first JavaFX code).

try {
	var writer = new FileWriter(new File(System.getProperty("user.home"),"javafx_infection.txt"));
	writer.append("I have escaped the browser. {new Date()}");
} catch (e:Exception) {

Now every time user clicks on the “next” button, the applet attempts to write to a file in user home directory. It can be both a malicious code or a legitimate action. There is no way to tell them apart. That’s the reason why we need some security mechanism.

Unsigned application
You can choose not to sign the application at all. Usually it is the best choice. This way the application will run in a sandbox and will not be able to execute any potentially dangerous code. On the other hand it will be safe for user to run it and he will not be troubled by any security alert. If the application attempts to execute dangerous code, the JRE will throw a security exception. In our case it will throw access denied (java.util.PropertyPermission user.home read)
at Source)
at Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at interesting.Main.hackIt(Main.fx:406)
at interesting.Main.onNext(Main.fx:133)

So if you don’t need to do anything dangerous and you are happy to play in the sandbox, unsigned application is the best choice.

Selfsigned application
Most of the samples on JavaFX page are self-signed. It means that the JAR is signed by a certificate that is not verified by any certification authority. In my opinion, that’s the worst option you can choose. You force the user to answer following security dialog.

Security Warning

Basically it’s the same as executing EXE (or binary) file only more dangerous. Some users already know that they should not execute EXE files from unknown sources, but they don’t know that they shouldn’t execute Java applications from unknown sources. I am afraid that we will hear about this issue more in the future.

If the user clicks on Run, the application can do whatever it want, if the user clicks on Cancel, the application will not run at all.

Signed application
We can sign the application by a certificate that is validated by a CA. I have used Thawte Freemail Certificate. Sounds trustworthy, doesn’t it? If you open the example, you will see following security warning.

Security Warning

It looks less threatening than with the selfsigned certificate. It looks less dangerous. The “Always trust” check-box is even checked by default. But in fact, it’s not much safer. It is more complicated to generate such certificate but anyone (even me) can do it. It might be even more dangerous. Everyone who is able to generate a certificate that is validated by the same CA will be allowed to execute the code (if you leave the check box checked). And again, it is all or nothing choice. User can either give the application all permissions or do not run it at all.

Unsigned application with signed JAR
In case you really need to do something potentially dangerous and you do not want to scare the user at the start of the application, you can use signed JAR in an unsigned application. Basically you can put all the dangerous stuff into a jar and sign only this jar. Most of the code can live in the main application which is unsigned. This way the application will start as unsigned and when you attempt to execute the dangerous parts the signed jar will be loaded and the security warning will be shown. In our example the application will start and the security warning will be shown when user clicks on the “next” button. At least that’s how it works on my machine. And I like it. This way user can use my application and is notified only when the application needs to do something insecure. And even if he decides that he doesn’t trust me, he can still use the application. (This idea came from a guy from Sun, unfortunately I don’t remember his name, thanks anyway)

To reiterate, the most secure choice is to write a JavaFX application that does not need any security permissions. If you do not sign it, it runs in the sandbox and everything is fine. If you need to execute some dangerous code, you have to ask user for a permission. Which is good, but users should be instructed that they shouldn’t execute any Java(FX) code if they are not sure what it does. So there is a possibility that they will not execute your applications because they will be afraid to do so. I can imagine that in the next versions of JavaFX there will be a signed library provided by Sun that will contain operations that are potentially dangerous but that are in fact safe. Like opening a file using “Open File dialog” etc.

Disclaimer: I am server-side developer, I know nothing about client-side Java, so do not be surprised if something I have written here turns up being wrong. Just correct it in the comments. Thanks.

11 thoughts on “JavaFX security

  1. v6ak

    Well, if I write an unsigned application with signed library and user check the Always trust checkbox, anybody would can make an unsigned application with my signed library. The application will be able to use library’s API, won’t it? Id the application can use the trusted API and the trusted API can do some dangerous operation, the application can do an dangerous operation limited by the API, can’t it?

  2. Lukáš Křečan Post author

    To v6ak: That’s an interesting idea and I think it is possible. You can even take a signed applet and use it as a library in your applet. Sounds dangerous.

  3. Martin Rubeš

    The trusted library should be trusted only in the context of the application which the library uses otherwise it’s serious security issue.

  4. v6ak

    The problem is maybe worse than I thought: IMHO You can use also whole applications. Reflection API enables to access more than I thought.
    BTW Is there any default trusted publisher in default settings? E.g. Sun?

  5. Lukáš Křečan Post author

    To Martin: How do you bind application to its library? An application is just bunch of JARs. That could be solved by a modular system. But it is impossible to solve it now (unless you include a jar into other jar).

  6. Lukáš Křečan Post author

    To v6ak: First of all, I think (I am not sure) that you cann’t use the reflection API in the sandbox.
    And I am not sure how it works with trusted CAs. They are listed in Java Control Panel, in the security tab. But even when I delete all of them, “Object Signing CA” is apparently trusted automatically. I will be glad if someone explain it to me.

  7. v6ak

    To Lukáš Křečan: I have no experience with Java Reflection API. I have never used it. I know what can I do only. I do not know these restrictions in Java Reflection API.

  8. Martin Rubeš

    to Lukas: I guess that the platform can somehow remember that the user approved usage of a signed jar for a certain applet. So this binding must be implemented by browser plug-in. I think that it’s quite reasonable to do so. I suppose that it’s done this way. Anyway, we can try it…

  9. Lukáš Křečan Post author

    Just small update, I have found this page about partner object signing and this bug that explains how “Object Signing CA” works.

  10. Lukáš Křečan Post author

    I don’t know what’s going on in Sun, but I assume that for Sun it’s not a bug but a feature.

Comments are closed.