Thirty-four vulnerabilities patched in the newly released Java 7 Update 25 (Java 7u25) version affect only client deployments of Java. Another four affect both client and server deployments, one affects the Java installer and one the Javadoc tool that's used to create HTML documentation files.

Many of the client-only vulnerabilities received the maximum score on the vulnerability severity scale used by Oracle. These flaws can be exploited by attackers to take control of computers by hosting malicious Java applets -- Java Web applications -- on remote servers and tricking users to load them in their browsers.

The large number of Web-based attacks that targeted Java users this year by exploiting vulnerabilities in the Java browser plug-in prompted concern about the security worthiness of the Java platform among home users and in enterprise environments, where Java is also frequently used on servers.

In order to clearly differentiate between the security risks to Java client and server deployments, Oracle started shipping a separate Server JRE (Java Runtime Environment) package in April that doesn't include the browser plug-in.

The Javadoc issue could affect users who visit HTML pages generated with the tool that are hosted on Web servers.

"Some HTML pages that were created by any 1.5 or later versions of the Javadoc tool are vulnerable to frame injection," said Eric Maurice, Oracle's director of software assurance, in a blog post Tuesday. "If exploited, this vulnerability can result in granting a malicious attacker the ability to inject frames into a vulnerable web page, thus allowing the attacker to direct unsuspecting users to malicious web pages through their web browsers."

Java 7u25 includes a patched version of the Javadoc tool that no longer generates vulnerable Web pages. In addition, Oracle released a separate tool called the Java API Documentation Updater Tool, that can be used to fix previously generated and vulnerable pages.

The new update also makes some other security-related changes, including enabling the certificate revocation checking feature by default.

As part of its efforts to fight Java exploits, Oracle changed Java's default behavior earlier this year to prevent the execution of unsigned applets without user interaction, therefore encouraging developers to digitally sign their Java Web applications with valid certificates.

However, in order for this to work properly as a defense mechanism, Java needs to be able to check in real time if the certificates used to sign applets have been revoked by their issuing certificate authorities (CAs). Otherwise, an attacker could sign a malicious applet with a stolen certificate and there would be no way for Java to detect that, even if the CA later revoked the certificate for abuse.

While support for two methods of certificate revocation checking -- by using certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) -- have existed in Java for a long time, the feature was turned off by default. In May, Oracle promised to change that in a future release.

The change was made in Java 7 Update 25 which now uses both CRL and OCSP to check for certificate revocations by default.

"Under normal circumstances revocation checking will have a slight impact on startup performance for applets and web start applications," Oracle said in its release notes for Java 7u25. "Enterprises with managed networks and without access to the Internet (resulting in no access to the revocation services provided by Certificate Authorities) will see a significant delay in startup times."

To avoid such delays, certificate revocation checking can be disabled through options available in the Java Control Panel. However, this "should only be considered in managed environments as it decreases security protections," Oracle said.

The number of vulnerabilities found and fixed in Java has increased significantly this year compared to the past two years, Amol Sarwate, director of Qualys Vulnerability Labs, said Wednesday in an emailed statement. "This year we had 137 vulnerabilities as compared to just 28 and 38 during the same period for the last two years."

Copyright 2016 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.