James Thew - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Java vulnerability report strains responsible disclosure

A security researcher reports Oracle's 30-month-old failed patch for a Java vulnerability, and experts suggest it was an irresponsible disclosure, despite frustration with Oracle's patching process.

In what appears to be a violation of standard practices for responsible disclosure of vulnerabilities by security researchers, a researcher last week posted an exploit for a Java vulnerability that Oracle reported as patched in 2013, without giving Oracle any advance warning of the still-open flaw. Experts mostly agreed this type of disclosure was irresponsible.

The vulnerability is still exploitable, with only minor modifications, according to Adam Gowdiak, CEO and founder of Security Explorations, based in Poland, who presented his research at the 2016 JavaLand conference last week in Bruhl, Germany.

Tracked as CVE-2013-5838, the vulnerability was originally discovered by Security Explorations in 2012 to 2013. The security research firm released details of the original Java vulnerability after Oracle released its patch in October 2013. At the time, the vulnerability was assigned a severity rating of 9.3 out of 10.0, because it could be exploited remotely, without authentication to control vulnerable systems.

In February 2016, while preparing for his Java security talk at the JavaLand conference, Gowdiak accidentally discovered the patch did not fix the flaw. Gowdiak then publicly disclosed in his conference presentation that the patch was broken and included proof-of-concept (PoC) code.

"We implemented a PoC code that illustrates the impact of the broken fix," Gowdiak wrote in a Security Vulnerability Notice posted last week, also noting that the exploit had been tested for Java SE 7 Update 97, Java SE 8 Update 74 and Java SE 9 Early Access Build 108. "In all cases, a complete Java security sandbox escape could be achieved."

Responsible disclosure?

Experts agreed, for the most part, that Gowdiak had gone too far by disclosing the vulnerability without giving any warning to Oracle.

"Researchers tend to vary in their approach to handling releases, and there is a great temptation to release publicly to generate headlines," said John Bambenek, manager of threat systems for Fidelis Cybersecurity, based in Waltham, Mass.

"What is atypical in this particular case is that, days prior, the company changed [its] disclosure policy before publishing PoC code to exploit the vulnerability. It is generally believed to be unreasonable to release PoC code to any vulnerability without giving prior warning to the vendor. Such a move puts the public at large at risk, and in this case, it very much looks like a publicity move by the company in question."

Gowdiak told SearchSecurity that the change to his firm's policy on disclosure of vulnerabilities, made just prior to his presentation in Germany, "reflects our higher expectations regarding security processes used by software vendors." The modified policy states: "Issues already reported to the vendor, which were improperly fixed, are not a subject to this policy. They are publicly disclosed, without any prior notice."

"Oracle received information about the vulnerability in 2013," Gowdiak said, defending the release without notifying Oracle. "If anyone is putting users at risk, this is Oracle. The company did fail -- not for the first time -- to produce a patch for a security vulnerability for which they received both a detailed technical report and a PoC code illustrating it."

The change in Security Explorations' responsible disclosure policy may have been due to frustration, suggested Trey Ford, formerly global security strategist at Rapid7, based in Boston. "Oracle is notoriously slow in [its] patching cycle," Ford said. "It's very frustrating" for researchers -- especially when a vulnerability has been identified, but not fully patched -- "to go back through and restart the timer on what Oracle is probably going to treat as a new notification. That's not going to solve any problems."

"Every major software vendor has security issues, and it is always a problem when they learn about issues from the media instead of a controlled process by which the researcher and security company can sit down and have a conversation. Both sides have a responsibility to handle security issues responsibly," Bambenek said.

"Any software vendor can produce patches that contain extra, or 'unfixed,' bugs [or] vulnerabilities. Patches are code, and code cannot be guaranteed to be bug-free," said Lane Thames, security researcher at Tripwire Inc., based in Portland, Ore. "Responsible disclosure versus irresponsible disclosure always seems to be debated. Largely, it is unreasonable for researchers to not work with vendors before disclosing, even if it is due to a broken patch. Patches are pieces of software that can also contain bugs. Hence, they should not be viewed differently than other bugs and vulnerabilities. At the end of the day, it is the consumer who will suffer from the irresponsible disclosure of this Java vulnerability."

Oracle is scheduled to release its next Critical Patch Update on April 19, 2016. Oracle has not responded to requests for information about this issue.

Oracle's responsibility on vulnerability patching?

"This isn't just Oracle; this is every development shop that deals with vulnerability notifications," Ford said. "This is something that everyone [who] produces software wrestles with."

"Oracle, SAP, IBM and other large enterprise vendors have the same problems," according to Alexander Polyakov, CTO at ERPScan, based in Palo Alto, Calif. "One thing that they [as well as other big vendors] definitely should do is to provide public access to all patches. Now, even if it was you who discovered a vulnerability, you can't check whether or not they have properly fixed it."

Part of the problem is that for some enterprise applications, access to patches is available only to paying customers, Polyakov said. "Even in this case, they won't give you this patch to test. So, currently, it's fully vendors' responsibility, and nobody can help them to test patches, even if she or he wants. And this is quite annoying."

"I would like to say that if they gave researchers an opportunity to test patches, it would not be bad. But in the current situation, just recall that Oracle said that they didn't need any help from external researchers; it's quite a shame."

Oracle's CSO, Mary Ann Davidson, last year dismissed bug bounty programs and security researchers in a post on her official Oracle blog -- though the post was immediately disavowed and removed by Oracle executives -- it is still available on the Internet archive. In it, she wrote that Oracle finds "87% of security vulnerabilities ourselves, security researchers find about 3% and the rest are found by customers."

"When working with researchers with software or firmware, it's always possible to reach out to the researcher to ask them to test the fix to ensure it resolves the issue before publishing the patch," said Tyler Reguly, manager of Tripwire's security research team. "Many vendors already take this approach, and it has two benefits: It provides additional [quality-assurance] resources that may think differently from your internal team, and it allows the researcher to further contribute, acknowledging that they are an expert in this area."

Oracle has eschewed bug bounty programs to date, while tolerating vulnerability reports by security researchers. "Oracle values the members of the independent security research community who find security vulnerabilities and work with Oracle so that security fixes can be issued to all customers," the company stated on its page for reporting security vulnerabilities. The reward offered to researchers is minimal: "Oracle's policy is to credit all researchers in the Critical Patch Update Advisory document when a fix for the reported security bug is issued." The security researchers' acknowledgment is dependent on the researcher following Oracle's standards for responsible disclosure, which include notifying Oracle prior to publishing, and not publishing "exact details of the issue, for example, through exploits or proof-of-concept code."

Irresponsible disclosure?

"In this case, the blame lays squarely on the researcher for publicly releasing this code," Bambenek said. "Oracle, for [its] part, needs to fully patch the vulnerability and take care that future patches can fully handle any future exploits." However, Bambenek said, "Oracle is under criticism for not fully fixing the hole the first time, and now they must get the job done."

"It's impossible to say that a vendor messed up when a patch doesn't work as expected," Reguly said. "Companies are always making a best-effort attempt."

Ford said vendors should be responsible for certifying their patches. "You're shipping code, and the code is going through quality-assurance testing to make sure the code does what it says it does, and if the firm building these products doesn't care enough to do anything beyond, 'All right, he gave us this one conditional set of code, we checked the box, yeah, we managed to break that exploit, we must have fixed it,' doesn't strike me as very meaningful."

"I want to believe that the code is going to do what it says it's going to do," Ford said. "And when they tell me I have reasonable assurance that it's going to be secure in these configurations, I'd like to believe that when they say they've fixed something, I want to believe they've fixed it."

Next Steps

Read more about flaws in the concept of bug bounty programs.

Learn about the U.S. Department of Defense's 'Hack the Pentagon' bug bounty program.

Find out why Oracle plans to deprecate the Java browser plug-in.

Dig Deeper on Microsoft Patch Tuesday and patch management