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.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/14/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 New Cybersecurity Vulnerabilities That Could Put Your Enterprise at Risk
In this Dark Reading Tech Digest, we look at the ways security researchers and ethical hackers find critical vulnerabilities and offer insights into how you can fix them before attackers can exploit them.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17475
PUBLISHED: 2020-08-14
Lack of authentication in the network relays used in MEGVII Koala 2.9.1-c3s allows attackers to grant physical access to anyone by sending packet data to UDP port 5000.
CVE-2020-0255
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2020-10751. Reason: This candidate is a duplicate of CVE-2020-10751. Notes: All CVE users should reference CVE-2020-10751 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-14353
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2017-18270. Reason: This candidate is a duplicate of CVE-2017-18270. Notes: All CVE users should reference CVE-2017-18270 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidenta...
CVE-2020-17464
PUBLISHED: 2020-08-14
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2020-17473
PUBLISHED: 2020-08-14
Lack of mutual authentication in ZKTeco FaceDepot 7B 1.0.213 and ZKBiosecurity Server 1.0.0_20190723 allows an attacker to obtain a long-lasting token by impersonating the server.