So says programmer Jerry Jongerius, who has released a "Java Code Signing Failure" alert detailing how app names displayed by Java security dialog boxes can be arbitrarily changed.
Java first unveiled its malicious app warning system in April -- to mixed reviews -- with the release of Java 7 update 21. The system is designed to warn users not to execute any Java app that hasn't been signed with a digital certificate. For signed apps, the warning system asks users if they want to proceed, and relays information to help them make their decision, including the name of the signed app, source and publisher.
[ Digital forensics is a growing field. Read New Security Trend: Bring Your Own Attorney. ]
But Jongerius, who runs a software development firm called Duckware, found flaws in that warning system that allowed him to not only rename digitally signed apps, but also serve apps from unapproved domains. He published an interactive test that demonstrates how the flaws can be exploited, using Oracle's own "Java Detection" applet, which is available via java.com.
"You can enter the name that you want to appear in the Java security dialog popup," he said via email. For example, the test's default name is set to "Credit Card Information Stealer," and if the test is run, an up-to-date version of the Java browser plug-in will display a security warning, asking the user if he wants to execute the "Credit Card Information Stealer," which the Java plug-in certifies is from "www.java.com" and signed by publisher "Oracle America, Inc." Again, no matter the name change, the applet is still Oracle's "Java Detection" applet.
Call it "basic failure by Oracle in code signing 101 rules," said Jongerius, who noted that any such system should "only present information to the end user that was actually signed by the publisher" -- no more, no less.
An Oracle spokeswoman didn't immediately respond to an email asking if the company had confirmed the vulnerability or was readying a fix. But Jongerius said that the U.S. Computer Emergency Response Team -- with which he shared details of the vulnerability -- emailed him that "Oracle is aware of the issue and is targeting a fix for a future update." Jongerius also noted that "my Web logs show that Oracle has hit that page a lot," referring to the proof-of-concept test page he created.
What's the threat to Java users from this vulnerability? Jongerius said that although "the risk is very small," attackers might take a legitimate tool, such as a remote-control utility that most users would never run, and package it as a more innocuous utility, titled for example as a Java version detector. "The user then runs it, seeing only 'Java Detection,' the hacker then outputs some 'Java information' and the user thinks it works and is done -- but they are now running remote control software," he said.
"The larger issue is that Oracle is presenting an application name to the user that the publisher never even signed, that anyone can change -- is crazy," he said.
Veteran Java bug hunter Adam Gowdiak, CEO of Security Explorations, also downplayed any risks to users from the vulnerability. "Alone, it does not pose a direct security risk," he said via email. "It could, however, cause unnecessary confusion for Java users [and] undermine their trust in [the] security warning shown or credibility of a digital signature verification process."
Fixing the problem should be simple. "The application 'Name' presented to the end user must come from the signed application" -- for example, by storing that name value inside a signed JAR (Java archive) file, said Jongerius.
Gowdiak agreed with that fix suggestion. "Oracle should consider adding a new attribute to the JAR Manifest file that would stand for the signed application name and could be digitally signed as well," he said. But the current JAR manifest specification doesn't include an attribute for an application name. "This could be the reason for the use of applet tag parameters -- such as 'name' -- that are not part of a digital signature verification process," he said, and which Jongerius was thus able to spoof.