Faced with an onslaught of malware attacks that leverage vulnerabilities and design weaknesses in Java, Oracle Corp. recently tweaked things so that Java now warns users about the security risks of running Java content. But new research suggests that the integrity and accuracy of these warning messages can be subverted easily in any number of ways, and that Oracle’s new security scheme actually punishes Java application developers who adhere to it.
Java’s security dialog box.
Running a Java applet now pops up a security dialog box that presents users with information about the name, publisher and source of the application. Oracle says this pop-up is designed to warn users of potential security risks, such as using old versions of Java or running applet code that is not signed from a trusted Certificate Authority.
Security experts differ over whether regular users pay any mind whatsoever to these warnings. But to make matters worse, new research suggests most of the information contained in the pop-ups can be forged by malware writers.
In a series of scathing blog posts, longtime Java developer Jerry Jongerius details the various ways that attackers can subvert the usefulness of these dialog boxes. To illustrate his point, Jongerius uses an applet obtained from Oracle’s own Web site — javadetection.jar — and shows that the information in two out of three of its file descriptors (the “Name” and “Location” fields) can be changed, even if the applet is already cryptographically signed.
“The bottom line in all of this is not the security risk of the errors but that Oracle made such incredibly basic ’101′ type errors — in allowing ‘unsigned information’ into their security dialogs,” Jongerius wrote in an email exchange. “The magnitude of that ‘fail’ is huge.”
Jongerius presents the following scenario in which an attacker might use the dialog boxes to trick users into running unsafe applets:
“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.”
Oracle has not responded to requests for comment. But Jongerius is hardly the only software expert crying foul about the company’s security prompts. Will Dormann, writing for theCarnegie Mellon University’s Software Engineering Institute, actually warns Java developers against adopting a key tenet of Oracle’s new security guidelines.
Oracle recommends that all Java applets be cryptographically signed regardless of the privileges required by the program. Unsigned Java applets will run within a web page with a scary red warning that, “Running this application may be a security risk.” One of Java’s most-touted features is a “sandbox” security mechanism that is supposed to prevent certain functions when the applet is sent as part of a Web page. But according to both Jongerius and Dormann, Oracle made the default behavior for signed code to be full access to the computer (essentially, negating the usefulness of the sandbox).
“What about Oracle’s vision of a Java future where every Java applet is signed?,” asks Dormann, a longtime security research with the Department of Homeland Security’s US Computer Emergency Readiness Team (US-CERT). “What this vision means is that every Java applet, which would be signed, would also now be in a state where it could be repurposed because it is now no longer restricted by the sandbox. A poorly designed sandboxed Java applet can’t do much of anything. However, a poorly designed signed Java applet can do pretty much anything that native code can.”
Both Dormann and Jongerius offer a number of ideas that Oracle could use to remedy the situation. Only time will tell if the company will take notice of the recommendations. In the meantime, I’ll continue to urge regular Internet users to get rid of Java completely, or at least to disconnect the Java plugin from any Web browsers (obligatory disclaimer: this advice does not scale for business users, whose computers may rely on Java for specific applications). !!! use our blog for more specification i.e.
www.inventorykit.blogspot.in
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
