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 137.254.4.13 / inet-aumc10-o.oracle.com
(traces to Dallas, TX) who entered "give a flying fuck"
into my test web page
— all recorded in my web server log file.
Visit
whois.arin.net
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 www.java.com
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 oracle.com: 148.87.19.194, 148.87.13.7, 148.87.19.210, 148.87.19.206, 148.87.19.198.
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 java.com is signed to only work
on www.java.com (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 duckware.com 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 www.java.com, 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.
|
|
