You are here: Duckware » Technology » Java Code Signing   Contact us  
Java Code Signing Failures
(August 27, 2013; VU#492297; S0390447; other vulnerabilities)

The application "Name" presented in Java security "code signing" dialogs can be forged.

UPDATE 2013/09/04: I received an (indirect) reply on this issue from an Oracle employee at / (traces to Dallas, TX) who entered "give a flying fuck" into my test web page — all recorded in my web server log file. Visit to confirm that this IP address belongs to Oracle.

Background: Oracle (Sun) in Java 7 update 25 (1.7.0_25) requires Java applets to be cryptographically "signed" in order to run within a web page without a nasty red "Running this application may be a security risk" warning message (example far below).
UPDATE 2013/09/18: In Java 7u40 the warning message is now: "Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk"
But even after code signing, you still get an annoying security popup dialog. Seen right is an example from Java's own web site (note that this popup is presented by the Java VM itself --and not the applet).

And notice what Oracle has bolded in this security popup, as if it is the most important informational component -- not the Publisher, but the Name of the application.

UPDATE: It appears that Java 7 update 51 fixes this security hole.

FAILURE ONE: The "Name" can be forged: Look at the Java security popup to the right. Do you trust what it says?

The problem is that the "Name" in this 'security' dialog contains an unsigned application name that can be easily forged (it comes from the unsigned web page) -- at will -- by anyone -- a basic failure by Oracle in code signing '101' rules -- only present information to the end user in security popups that was actually signed by the Publisher

The interactive proof: To prove how incredibly easy the "Name" is to forge, visit javafailure.html to see the popup dialog (above right) live yourself, with a forged name that you enter.

Misplaced trust: Now Oracle says that this new security dialog establishes trust, and shows that the application is "identified by a valid certificate from a trusted Certificate Authority". If true, the security warning dialog immediately above proves that is running a "credit card information stealer" on it that was signed by Oracle. And if not true, the new Java security dialogs can simply not even be trusted to provide accurate information about what was actually signed.

The security risk: The security risk is very low, but there. Imagine a hacker taking a real signed Java application for remote desktop control / assistance, and placing it on a gaming site, renaming it "Chess". An unsuspecting end user would get a security popup from Java asking if they want to run 'Chess', and because they do, answer yes -- but behind the scenes, the end user's computer is now under the remote control of a hacker (and maybe to throw off suspicion, implemented a basic 'Chess' in HTML5 so it looks like that applet worked). -- all because Oracle allowed the "Name" in security dialogs to be forged to something innocent and incorrect.

SOLUTION: The solution that Oracle must implement ASAP is incredibly simple. The application "Name" presented to the end user MUST come from the signed application -- via a new 'Application-Name' tag inside the MANIFEST.MF file inside the signed JAR. And if the new tag is not present, the only reasonable fallback is to use the signed applet class name (which is inside the signed JAR). Using anything non-signed just will not do.
If Oracle is really serious about security, Oracle will immediately (1) require an 'Application-Name' tag, and (2) make use of a Timestamping Authority mandatory — as of a date that Oracle selects. And that can be enforced by the Java VM by using the code-signed time stamp. Any signed jar with a date after the deadline date must have an 'Application-Name' tag present, or the JAR will be blocked from running.
Oracle knows about this: The first day this web page was published, this web page received hits from,,,,

FAILURE TWO: Signed JARs can be renamed: Another security failure is that after a Publisher "code signs" a JAR file, Oracle allows that JAR file to be renamed (eg: RemoteDesktopControl.jar to Chess.jar). And that renamed JAR filename is displayed inside the security dialogs. That is yet another security hole -- unsigned information making its way into the security dialog.

When combined with failure one above, a hacker can now manipulate/change the 'Name' as well as the JAR filename in the 'Location' displayed in security popups (example seen right).

Once a Publisher signs a JAR file, there is NO legitimate reason (other than hacker activity) for Oracle to allow the JAR to be renamed to something else in the security popup dialogs.

SOLUTION: As part of the JAR code signing process, Oracle must place the original signed JAR filename into the MANIFEST.MF. It is that signed JAR name that MUST be displayed inside security dialogs. And if there is a name mismatch (signed jar name to current jar filename), maybe that causes a warning message inside the security dialogs.

FAILURE THREE: The new MANIFEST.MF 'codebase' attribute does not work as intended: Oracle introduced a new 'codebase' attribute into the MANIFEST.MF file, that prevents an application "from being repurposed". The only problem. It does not work (as intended).

Oracle's "Java Detection" applet on is signed to only work on (seen right) -- and yet, it runs just fine (is being repurposed) from the javafailure.html web page on this website. And Oracle's applet is gladly calling JavaScript on my web page -- a huge security failure.

SOLUTION: Oracle needs to get serious about security, and until Oracle understands that there are TWO bases (not ONE) in Java applets (a document base and a code base), the added security to just one of the two code bases is a big security failure.

ISSUE: Oracle admits the Java 'sandbox' is a failure and unsafe: The Java sandbox (that prevents applets from accessing your local computer) does not work, and Oracle fully admits that inside security popup dialogs...

Try to run the most simple 'do nothing' applet inside of a web browser under Java 7u40 today, and you will get the worst nasty popup from Java (example seen right) -- telling you that running the sandboxed applet is unsafe and a security risk.

And here is the ENTIRE applet source code, that Oracle says may harm your computer:
public class DoNothing extends java.applet.Applet { }
No end user in their right mind would run any applet with that warning message. In effect, Oracle is killing off the Java security sandbox for unsigned applets! Because Oracle wants you to sign your code, and obtain full access to the computer -- and then you get a much nicer security popup!

That is not security -- that is a failure in security.

And if you try to create a sandboxed code-signed applet, it is not easy. Read the next section...

ISSUE: Java will block you if you try to sandbox your signed applet.

Now, if you try to be a very conscientious software developer, and code-sign your Java applet to be run in the Java security sandbox (so you can NOT access the local computer) by placing a "Permissions: sandbox" line in the MANIFEST.MF, the Java VM will erroneously BLOCK your applet from even running (see popup right).
The workaround/fix is to also specify the sandbox permission as a param in the unsigned HTML applet tag, which is crazy, because the Java VM could and should have done that automatically by applying the permissions value inside the MANIFEST.MF.

Oracle has no common sense. Oracle states that JavaScript calls into an applet with full permissions will be "sandboxed", but Oracle REFUSES to run a signed applet that requested to be sandboxed (in the signed JAR), and requires a duplicate 'sandbox' decision/param to be declared in unsigned HTML in order to actually run the applet sandboxed.

The sandbox param that Oracle requires in the applet tag is superfluous. The signed applet has already declared that it MUST be sandboxed (inside the code-signed MANIFEST.MF file), and Java refuses to honor/implement that. The permissions applet param was a huge security mistake. Remove it.
Here is an interesting Will Dormann blog entry from CERT.ORG that is a fascinating read: Don't Sign that Applet!

Further proof that Oracle does not fully understand security. Oracle makes a software developer jump through hoops to run an applet inside the security sandbox, because Oracle made the default behavior for signed code to be full access to the local computer (no sandbox).
Oracle, in their "Java Detection" applet on, expressly asks for FULL ACCESS to your computer, when the code runs just fine in a sandbox!! Has Oracle lost their mind? A fundamental rule in security is that code must only ask for the minimum permissions needed to run, and no more.

Oracle is ignoring their own deployment best practices advice!

Maybe Oracle's developers ran into the same 'block' issue trying to sandbox their own applet, and gave up?
SOLUTION: Oracle got it backwards! The default must be 'sandbox' regardless of the signed (or not) nature of the code. Signed should only affect level of trust, not level of access to the computer. A developer must expressly ASK for full access (via Permissions) in signed code, not be granted full access for simply signing code. Oracle needs to get serious about security, break with the past, and implement common sense security.
Oracle has no problem breaking Java's Runtime.exec() on Windows, which will disable countless Java applications (it did all of mine) -- But Oracle has a problem fixing the Java security issues? Oracle's priorities are seriously mixed up.

It is incredibly EASY to implement. Any applet signed after a deadline date that Oracle selects (all JARs should be time stamped as part of the signing process) will have new stricter behavior (be sandboxed by default and require a Permissions MANIFEST.MF setting).

ISSUE: Security is an after-thought: During the testing phases of debugging my signed and sandboxed applet, I once forgot to uncheck the "Do not show this again for apps from the publisher and location above" in the "Do you want to run this application?" security popup (seen right).

However, I needed that popup for testing validation. But the popup was gone. I flushed the browser and java caches, but the popup was still gone. The trusted certificate was not in Java's control panel. After hours of Google searches, nothing. I found lots of information online (from Oracle, and elsewhere) about the certificate being inside the Java Control Panel, but no, it was not. The popup was gone.

Sleuthed the registry, nothing. Finally after some sleuthing of what Java left behind in the file system, and a targeted Google search on keywords found, it turned out that Oracle knew about this issue all along!!
Oracle provides no GUI to undo that trust choice, and Oracle knows this! Here is a release note from the Java 7 update 21 release:

"With the new sandbox security dialog box changes in JDK 7u21, user (sic) can now trust signed sandbox apps, and optionally trust all apps signed by the same certificate from the same URL. However, there is no way to remove the trusted sandbox certificates through the Control Panel, as one can for other trusted certificates. The workaround is to manually remove the sandbox.certs keystore from the security directory in user's deployment home directory or remove individual entries using keytool."

Oracle, if you don't resolve an issue like this from u21 to u25 to u40, republish the notice again in the u25 and u40 release notes! That would have saved me (and likely others) hours of research time.
There is no reason for Oracle to not implement a GUI for managing these certificates (like is done for all the other trusted certificates). I dare say that this should be no more than a couple of lines of code to add support for looking at a new 'certs' file (because the control panel already manages numerous other 'certs' files). Chaulk it up to Oracle laziness.

A final note: What is it going to take for Oracle to take Java security seriously? Maybe the Department of Homeland Security recommending that users disable Java? No, that already happened! It is almost as if Oracle is intentionally killing off the Java sandbox in the browser by ignoring security, or misimplementing it:
The entire Java code signing issue is one huge clusterf**k. In order to run under the lastest version of Java without 'this code may harm your computer', you MUST sign your applets. I have done so, requesting "sandbox" premissions. But by doing so, the security dialogs under earlier Java versions will now erroneously claim that my applet wants FULL UNRESTRICTED ACCESS to the computer, and then run my applet with full access to the computer. Crazy!
I guess time will tell -- Will Java even be around in five years in the browser? Don't get me wrong — I love Java. I founded multiple business upon Java. But, I am not counting on it. Will you?

UPDATE: At Duckware, we killed off all Java applets and switched to HTML5. It was the best thing we could have ever done! Every web browser on all platforms support HTML5.
Copyright © 2013-2024 Duckware