Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

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
Comments
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/5/2020
How AI and Automation Can Help Bridge the Cybersecurity Talent Gap
Peter Barker, Chief Product Officer at ForgeRock,  6/1/2020
Cybersecurity Spending Hits 'Temporary Pause' Amid Pandemic
Kelly Jackson Higgins, Executive Editor at Dark Reading,  6/2/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: What? IT said I needed virus protection!
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13864
PUBLISHED: 2020-06-05
The Elementor Page Builder plugin before 2.9.9 for WordPress suffers from a stored XSS vulnerability. An author user can create posts that result in a stored XSS by using a crafted payload in custom links.
CVE-2020-13865
PUBLISHED: 2020-06-05
The Elementor Page Builder plugin before 2.9.9 for WordPress suffers from multiple stored XSS vulnerabilities. An author user can create posts that result in stored XSS vulnerabilities, by using a crafted link in the custom URL or by applying custom attributes.
CVE-2020-11696
PUBLISHED: 2020-06-05
In Combodo iTop a menu shortcut name can be exploited with a stored XSS payload. This is fixed in all iTop packages (community, essential, professional) in version 2.7.0 and iTop essential and iTop professional in version 2.6.4.
CVE-2020-11697
PUBLISHED: 2020-06-05
In Combodo iTop, dashboard ids can be exploited with a reflective XSS payload. This is fixed in all iTop packages (community, essential, professional) for version 2.7.0 and in iTop essential and iTop professional packages for version 2.6.4.
CVE-2020-13646
PUBLISHED: 2020-06-05
In the cheetah free wifi 5.1 driver file liebaonat.sys, local users are allowed to cause a denial of service (BSOD) or other unknown impact due to failure to verify the value of a specific IOCTL.