Vulnerabilities / Threats
9/5/2013
03:09 PM
50%
50%

Researcher Pokes Holes In Java 7 Security

Programmer questions Java 7 security model, details hacks that allow faked app locations and server redirects.

Is the design of Oracle's Java 7 security sandbox backwards?

That charge was leveled by programmer Jerry Jongerius, who last week released a Java Code Signing Failure alert detailing how Java security dialog boxes could be hacked to display arbitrary app names, even if the app had been digitally signed.

Jongerius, who programs in Java and runs a software development firm called Duckware, has been busy since then. In recent days, he's detailed a technique for tricking the Java security dialog box into displaying not only a fake app name, but also a false location, such as "www.java.com." He also found a way to redirect an app that's sandboxed -- meaning that its range of activities should be restricted -- to accept commands from an arbitrary server.

In addition, he found a way to trick Java 6 and Java 7 into allowing a sandboxed Java applet to retrieve any photo stored on a computer by using the "Applet.getImage()" command built into Java. "I leave it as an exercise for Oracle to determine if Applet.getAudioClip() is also vulnerable," he said.

[ For more on recent Java vulnerabilities, see Java Malicious App Alert System Tricked. ]

One mitigating factor for that image-retrieval vulnerability, however, is that anyone who might want to abuse the flaw must know the name of the file to be retrieved. Accordingly, he said, the real-world risk to users from the flaws that he's identified would be minimal.

Jongerius said he's reported all of the new vulnerabilities to the U.S. Computer Emergency Response Team (CERT), but not directly to Oracle. "No word from CERT or Oracle," he said Thursday via email.

But Jongerius' efforts apparently haven't gone unnoticed. For starters, he saw traffic come to his site from CERT -- as well as from a military domain -- after he filed his "getImage()" bug report. In addition, he reported receiving a rude message via his website's contact page from an IP address that traced to an Oracle facility in Dallas.

An Oracle spokeswoman, contacted by email, didn't immediately respond to a request for comment on that allegation, whether the company was aware of Jongerius' research and had verified the vulnerability reports, or if it had fixes in the works.

Beyond finding multiple vulnerabilities in Java 7, Jongerius also raised some bigger-picture questions about the efficacy and code quality behind the Java security model, which allows digitally signed apps to request permissions that are denied outright to sandboxed apps, such as accessing an image on the PC, accessing the clipboard or executing code.

"A fundamental rule in security is that code must ask for only the minimum permissions needed to run and no more," Jongerius said.

But Java 7 doesn't allow signed apps to be sandboxed. "If you try to be a very conscientious software developer and request that your Java applet be run in the Java security sandbox -- so you cannot access the local computer... the Java VM will erroneously block your applet from even running," he said.

Yet Oracle has been pushing Java users to use only signed Java applications. Notably, Java 7 update 21, released in April, added a warning system designed to deter people from running any unsigned app, backed by a stern caution for unsigned code that "running this application may be a security risk." Based on Jongerius' research, that warning message isn't triggered by any type of code scan but is based purely on whether the app has been signed.

But even signed apps can be malicious, CERT Coordination Center vulnerability analyst Will Dormann has long warned. Accordingly, Dormann has argued that Java 7 users would be best served by using only unsigned apps.

"A poorly designed sandboxed Java applet can't do much of anything," he said in an April "Don't Sign That Applet" blog post. "However, a poorly designed signed Java applet can do pretty much anything that native code can."

The underlying problem, Dormann explained, is that digitally signing an app is no guarantee that it's safe. "Java conflates authentication ("Who wrote this code?") with authorization ("What is this code allowed to do?"). When you sign an applet, it gets privileges automatically," he said.

What would be better, both Dormann and Jongerius argue, is that a Java applet should be signed only if it requests permissions that might have security repercussions, such as access to the local file system. Otherwise, all apps should be sandboxed by default. Furthermore, even signed apps should be restricted to receiving only requested permissions, rather than gaining all-you-can-eat access. Jongerius said that such restrictions are in place for Java apps run from Web servers, but they can be bypassed for apps that run locally.

That research aside, it's important to remember that numerous security experts have recommended disabling the Java Web browser plug-in altogether, whenever possible. "If you don't need Java in your Web browser, turn it off," said Dormann. "If you don't know if you need Java in your Web browser, turn it off anyway and see what breaks. You might find that it doesn't affect you at all."

For anyone who does need to use Java, the prevailing information security wisdom is to always update immediately to the latest version, since it will mitigate a number of well-known and widely exploited vulnerabilities.

But according to research published Wednesday by security firm Websense, while 84% of browsers today have Java enabled, last month only 19% of enterprise Windows PCs were running Java 7 update 25, which was released in June and remains the most recent version. Meanwhile, over 40% of Java traffic from enterprises came from Java 6 clients, which Oracle ceased patching in April and which is increasingly an attack magnet for hackers and crimeware kits.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-1793
Published: 2014-12-25
rendering/svg/RenderSVGResourceFilter.cpp in WebCore in WebKit in Google Chrome before 11.0.696.65 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted SVG document that leads to a "stale pointer."

CVE-2011-1794
Published: 2014-12-25
Integer overflow in the FilterEffect::copyImageBytes function in platform/graphics/filters/FilterEffect.cpp in the SVG filter implementation in WebCore in WebKit in Google Chrome before 11.0.696.65 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified ...

CVE-2011-1795
Published: 2014-12-25
Integer underflow in the HTMLFormElement::removeFormElement function in html/HTMLFormElement.cpp in WebCore in WebKit in Google Chrome before 11.0.696.65 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted HTML document con...

CVE-2011-1796
Published: 2014-12-25
Use-after-free vulnerability in the FrameView::calculateScrollbarModesForLayout function in page/FrameView.cpp in WebCore in WebKit in Google Chrome before 11.0.696.65 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via crafted JavaS...

CVE-2011-1798
Published: 2014-12-25
rendering/svg/RenderSVGText.cpp in WebCore in WebKit in Google Chrome before 11.0.696.65 does not properly perform a cast of an unspecified variable during an attempt to handle a block child, which allows remote attackers to cause a denial of service (application crash) or possibly have unknown othe...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.