Already, Ramani said Oracle's Java developers have been practicing better secure development practices, including using more automated security testing tools, using better source code analysis tools, as well as hammering code with homegrown analysis tools designed to eliminate vulnerabilities that might be targeted using code-fuzzing techniques. She also noted that Oracle has refocused resources to help release Java security updates more quickly.

Veteran Java bug hunter Adam Gowdiak, CEO and founder of Poland-based Security Explorations, confirmed via email that Oracle has been responding to bug reports in just days -- instead of the weeks it used to take. Gowdiak also rated Oracle's Java patching speed as "slightly improved," saying that after Oracle receives a vulnerability report, it's been issuing a fix about two months later.

Going forward, Oracle's Ramani promised further Java security improvements, starting with better controls for managing Java clients in the enterprise. "Local Security Policy features will soon be added to Java and system administrators will gain additional control over security policy settings during Java installation and deployment of Java in their organization," she said. For example, IT administrators will be able to restrict Java clients to only execute Java applications located on designated servers, which would make it more difficult for attackers to make PCs execute malicious Java applications located on remote servers.

Server-based Java will also get more locked down. Already, Oracle in April 2013 released an all-new Server Java Runtime Environment (Server JRE), which was a Java distribution designed "to reduce attack surface but also to reduce customer confusion when evaluating server exploitation risk factors," according to Ramani. Going forward, expect Oracle to refine Server JRE, "including the removal of certain libraries typically unnecessary for server operation," she said.

But Ramani said that tweaking Java 7 in this manner "would violate current Java specifications," meaning related changes won't happen until Oracle releases Java 8, which was originally set for September 2013, but has been delayed in the wake of Oracle now taking more time to fix Java 7 flaws.

The final previewed change concerns Java applications (aka JAR files) signed with digital certificates, which Oracle had been urging developers to do. Then, as of Java 7 update 21, released in April 2013, the Java client began prohibiting any unsigned application from automatically executing, and warned users to beware allowing the application to run. To date, however, that system has relied on a static list of known-bad certificates and applications -- a restriction that Ramani said resulted from performance concerns. Soon, however, Oracle will introduce "a dynamic blacklisting mechanism including daily updates for both blacklisted JAR files and certificates," she said.

But Ramani didn't address criticism of the Java 7 warning system on information security and usability grounds. On the security front, notably, "obtaining a code-signing certificate has not been a barrier for malware in the past and there is little chance it will become one in the future," Metasploit creator HD Moore told Threatpost.

On the usability front, meanwhile, the warning system's success is predicated on end users taking the time to read, understand -- and care -- about the new Java warning messages. As Paul Ducklin, head of technology for Sophos in the Asia Pacific region, said in April: "These dialogs end up asking the very questions that you might reasonably expect Java to answer."

Furthermore, Gowdiak at Security Explorations said that, with the exception of the new Local Security Policy features, Ramani's preview of upcoming improvements failed to address ongoing Java browser plug-in security shortcomings. "Seeing yet another Oracle VP speaking out about Java security only confirms our fears that the company prefers to hide a more systemic problem behind various security prompts and policies than to address it at the core," said Gowdiak via email.

"The core issue is about [the] poor quality and security of Oracle's code," he said. "We will get impressed if, and only if, Oracle makes it harder to break [the] Java security model. From our point of view the company hasn't made much [of a move] in that direction."

Published: 2015-03-31The build_index_from_tree function in index.py in Dulwich before 0.9.9 allows remote attackers to execute arbitrary code via a commit with a directory path starting with .git/, which is not properly handled when checking out a working tree.