IBM SDK, Java 2 Technology Edition, Version 5.0: Current news

News


Abstract

Support information for IBM SDK, Java 2 Technology Edition, Version 5.0 that is not available in the user documentation.

Content

The documentation to support this release is available in an IBM Information Center. However, these guides apply to IBM SDK, Java 2 Technology Edition, Version 5.0 Service Refresh 12 and earlier releases, and are no longer maintained.

For important changes to this documentation level, read these sections:


Supplementary information is also available for the following service refresh levels:
For information about security fixes, see Security Alerts.
For information about IBM fixes, see IBM fixes for IBM SDK, Java 2 Technology Edition, Version 5.0.

For information about the daylight saving time changes included in service refreshes and fix pack levels, see Olson time zone updates. Later updates can by applied using the IBM Time Zone Update Utility for Java (JTZU).



Service refresh 16 fix pack 4:

Securing Java API for XML (JAXP) processing against malformed input

If your application takes untrusted XML, XSD or XSL files as input, you can enforce specific limits during Java API for XML (JAXP) processing to protect your application from malformed data. These limits can be set on the command line by using these system properties:

    -Djdk.xml.entityExpansionLimit=value
  • Where value is a positive integer. The default value is 64,000.
  • A value of 0 or a negative number sets no limits.
  • Use this option to limit the number of entity expansions in an XML document.
    -Djdk.xml.maxOccur=value
  • Where value is a positive integer. The default value is 5,000.
  • A value of 0 or a negative number sets no limits.
  • This option defines the maximum number of content model nodes that can be created in a grammar. When building a grammar for a W3C XML schema, use this option to limit the number of content model nodes that can be created when the schema defines attributes that can occur multiple times.
    -Djdk.xml.totalEntitySizeLimit=value
  • Where value is the collective size of all entities. The default value is 5x10^7.
  • A value of 0 or a negative number sets no limits.
  • This option limits the total size of all entities that include general and parameter entities.
    -Djdk.xml.maxParameterEntitySizeLimit=value
  • Where value is the maximum size that is allowed for a parameter entity. The default value is 0.
  • A value of 0 or a negative number sets no limits.
  • This option limits the maximum size of a parameter entity. To protect an application from malformed XML, set this value to the minimum size possible.
    -Djdk.xml.maxGeneralEntitySizeLimit=value
  • Where value is the maximum size that is allowed for a general entity. The default value is 0.
  • A value of 0 or a negative number sets no limits.
  • This option limits the maximum size of a general entity. To protect an application from malformed XML, set this value to the minimum size possible.

Alternatively, you can specify these properties and values in your jaxp.properties file. For example, you can set the general entity size limit by specifying the following line in your jaxp.properties file:

    jdk.xml.maxGeneralEntitySizeLimit=5000

For the limits to take effect you must also override the default XML parser configuration with a custom configuration that allows these secure processing limits. To override the default XML parser configuration, set the org.apache.xerces.parsers.SecureProcessingConfiguration custom configuration by specifying the following system property on the command line:

    -Dorg.apache.xerces.xni.parser.XMLParserConfiguration=
    org.apache.xerces.parsers.SecureProcessingConfiguration

For more information about the full override mechanism, see http://xerces.apache.org/xerces2-j/faq-xni.html#faq-2.

Support for Windows releases

Support is now included for Windows 8.1 and Windows Server 2012 R2 from service refresh 16 fix pack 4.



Service refresh 16 fix pack 3:

Unexpected XSLT error on extension elements or extension functions when Java security is enabled

Any attempt to use extension elements or extension functions when Java security is enabled, results in a javax.xml.transform.TransformerException error during XSLT processing. This change in behavior is introduced to enhance security.

The following XSLT message is generated when extension functions are used:
Use of the extension function '<method name>' is not allowed when Java security is enabled. To override this, set the  com.ibm.xtq.processor.overrideSecureProcessing property to true. This override only affects XSLT processing.

The following XSLT message is generated when extension elements are used:
Use of the extension element '<element name>' is not allowed when Java security is enabled. To override this, set the com.ibm.xtq.processor.overrideSecureProcessing property to true. This override only affects XSLT processing.

To allow extensions when Java security is enabled, set the com.ibm.xtq.processor.overrideSecureProcessing system property to true.

IBM PKCS11 security provider

In previous releases, when you used the KeyGenerator class to generate DESede keys by using the IBMPKCS11Impl provider, the IBMPKCS11Impl provider supported only a DESede key size of 192. The IBMPKCS11Impl provider now also accepts a DESede key size of 168, to be consistent with the IBM JCE security provider, which accepts a DESede key size of 168. 168 and 192 actually represent the same DESede key size; 192 includes the DESede parity bits, but 168 does not.

Usage tip

The IBMPKCS11Impl configuration file supports either a "slotListIndex" attribute or a "slot" attribute, with the following intended definitions:

  • slot attribute: This attribute identifies the absolute slot number of the adapter, for example: 1, 2, 3, and so on.
  • slotListIndex attribute: This attribute identifies an index into the list of available slot numbers, for example: 0, 1, 2, and so on.

However, the "slot" attribute incorrectly expects a "slotListIndex" value to be supplied. To avoid causing problems for customers who might be using the "slot" attribute, this issue is documented, but will not be fixed.


Go back to the top


Service refresh 16 fix pack 2:

This fix pack includes a change to the default value for the RMI property java.rmi.server.useCodebaseOnly from false to true, which might cause unexpected errors for applications that use RMI. For more information, see http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html.

On Windows, improvements are made to the way that Runtime.exec decodes command strings. However, applications specifying commands that contain spaces in the program name, or that use quotation marks incorrectly, might fail to start. For more information, including guidance on resolving problems, see http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jaruntime.

This fix pack also contains a security fix for the Oracle security vulnerability, CVE-2013-0169, which affects Transport Layer Services (TLS) 1.1 and 1.2.


Go back to the top



Service refresh 16:

A new set of unlimited jurisdiction policy files are available for download. Although the old policy files continue to work with all current releases, after installing service refresh 16, you should plan to update to the new policy files before 2014. This activity is necessary ahead of the expiry of the certificates that sign these policy files. For more information, see IBM SDK Policy files.


Go back to the top


Service refresh 15:
The following hardware and operating systems are tested with service refresh 15:

  • IBM zEnterprise EC12
  • Microsoft Windows 8
  • Microsoft Windows Server 2012

PKCS11 security provider

A new library is available that allows the IBMPKCS11Impl provider to run on the Linux AMD64 platform.


Go back to the top


Service refresh 14:


The following changes are made for service refresh 14:

  • There are performance improvements to hashing algorithms for hashed data structures.
  • The IBM GBK converter can use Unicode 2.0 standards.
  • The IBM PKCS11 security provider supports additional cryptographic adapters.


Improved hashing algorithm
Improvements are made to hashing algorithms for IBM SDK for Java V5.0.
An improved hashing algorithm is available for string keys stored in hashed data structures. You can adjust the threshold that invokes the algorithm with the following system property:
-Djdk.map.althashing.threshold=value
where value defines the capacity of the hashed data structure. This algorithm can change the iteration order of items returned from hashed maps. Before enabling this property in a production environment you should test your applications thoroughly.
A value of 1 ensures that this algorithm is always used, regardless of the hashed map capacity. A value of -1 prevents the use of this algorithm, which is the default.
The hashed map structures affected by this threshold are: java.util.HashMap, java.util.Hashtable,  java.util.LinkedHashMap, java.util.WeakHashMap, and  java.util.concurrent.ConcurrentHashMap.
The capacity of a hashed map is related to the number of entries in the map, multiplied by the load factor. Because the capacity of a hashed map is rounded up to the next power of two, setting the threshold to intermediate values has no affect on behavior. For example, threshold values of 600, 700, and 1000 have the same effect. However, values of 1023 and 1024 cause a difference in behavior. For a more detailed description of the capacity and load factor, see http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html.
When entries are removed from a hashed map the capacity does not shrink. Therefore, if the map ever exceeds the threshold to use alternative hashing for Strings, the map always uses alternative hashing for Strings. This behavior does not change, even if entries are later removed or the map is emptied using clear().

An enhanced hashing algorithm is also used for  javax.xml.namespace.QName.hashCode(). This algorithm can change the iteration order of items returned from hashed maps. For compatibility, you can restore the earlier hashing algorithm by setting the system property

-Djavax.xml.namespace.QName.useCompatibleHashCodeAlgorithm=1.0


IBM GBK converter
By default the IBM GBK converter follows Unicode 3.0 standards. A new system property value is available to force the IBM GBK converter to follow Unicode 2.0 standards.
To force the IBM GBK converter to follow Unicode 2.0 standards, use:
-Dfile.encoding=bestfit396


IBM PKCS11 supported devices
The following cryptographic adapters are now supported by the IBM PKCS#11 security provider:

  • SafeNet Luna 4.0
  • SafeNet Luna 5.0
  • Thales nShield Edge
  • Thales nShield Connect 1500.

The following cards are also supported:
  • Thales nShield Connect 500
  • Thales nShield Connect 6000
These models have not been tested by IBM, but support is assumed because other cards in the same family have been tested successfully.

The SafeNet Luna 3.0 is no longer supported.

The SafeNet Luna 4.0 and 5.0 adapters have the following observations:
  • Private software keys cannot be translated using this card. Set publickeyimportonly = true in the PKCS#11 configuration file to ensure that the provider does not attempt to translate private software keys.
  • Key wrapping does not work with the default configuration of the device.
  • Setting a seed for the random number generator is not allowed.
  • This device throws a ShortBufferException for buffers that are too small.
  • The Blowfish and MD5 mechanisms are not supported.

The Thales nShield Edge and nShield Connect adapters have the following observations:
  • RSA keys can wrap a DES or DESede key, but DES and DESede key cannot wrap an RSA key.
  • Public keys cannot be wrapped.
  • Translation of plain RSA keys is not supported. RSA CRT keys can be translated.
  • Random number seeding is not supported.
  • Hardware private key, the DERIVE, and SIGN value cannot be configured to true at the same time. Therefore, one private key cannot be used for both signing and key agreement.
  • The Thales nShield Connect 1500 was tested with version 2.38.7 of the firmware, and with version 2.47.13 of the Thales client software. These version numbers can be found by running the enquiry command, which is part of the Thales client software. Users of the Thales nShield Connect 500 and Thales nShield Connect 6000 should ensure that the same, or later, firmware and client software versions are being used.


Go back to the top



Service refresh 13 fix pack 1:


The following significant changes are included with fix pack 1:

Browser Exploit Against SSL/TLS (BEAST)
This change relates to Oracle security vulnerability CVE-2011-3389, which describes a potential security vulnerability with Secure Socket Layer (SSL) 3.0 and Transport Layer Security (TLS) 1.0 protocols.
IBM's Java Secure Socket Extension (IBMJSSE2) has been modified. A JVM system property can be specified on the client side software that adds sufficient randomness to the TLS 1.0 and SSL 3.0 Cipher in Cipher-Block Chaining (CBC) mode to remediate a threat like BEAST. For more information about these changes see Security vulnerability fixes: IBM Java Secure Socket Extension (IBMJSSE2).

SocketFactory
This change relates to Oracle security vulnerability CVE-2011-3560.
If you have Java applications or applets with a legitimate need to set a particular SSLSocketFactory, you must make the following change after applying the fix:

  • Update the Java security java.policy file to include the "setFactory" permission, if it is not already there. Use java.lang.RuntimePermission("setFactory").

KeyboardFocusManager implementation
This change relates to Oracle security vulnerability CVE-2012-0502.
The KeyboardFocusManager specification explicitly allows a single, global KeyboardFocusManager for all applets. Some public methods are unsafe for such implementations.
As a result of the fix, the following methods now throw a java.lang.SecurityException if they are invoked on a java.awt.KeyboardFocusManager that is not the current java.awt.KeyboardFocusManager for the calling thread's context:
  • java.awt.KeyboardFocusManager.setGlobalFocusOwner(Component focusOwner)
  • java.awt.KeyboardFocusManager.clearGlobalFocusOwner()
  • java.awt.KeyboardFocusManager.setGlobalPermanentFocusOwner(Component permanentFocusOwner)
  • java.awt.KeyboardFocusManager.setGlobalFocusedWindow(Window focusedWindow)
  • java.awt.KeyboardFocusManager.setGlobalActiveWindow(Window activeWindow)
  • java.awt.KeyboardFocusManager.setGlobalCurrentFocusCycleRoot(Container newFocusCycleRoot)


Go back to the top


Service refresh 13:

IBM zEnterprise 196 toleration
For Service Refresh 13, IBM SDK for Java version 5.0 is supported on the IBM zEnterprise 196 System z platform.

Browser support
Mozilla Firefox 3.6 or newer, on any platform, is not supported.
Microsoft Internet Explorer 9 is not supported.

z/OS 1.13 support
For Service Refresh 13, z/OS 1.13 is supported.

Chinese characters or symbols encoded with GBK are incorrectly stored as ?
A problem was identified with an Oracle database created with ZHS16GBK (GBK) encoding. If you used a character defined in the Unicode Private Use Area (PUA), you might see some characters converted to "?" in the database, even when using GBK encoding.
From Service Refresh 13, a new codepage MS936A has been added. This solves the problem.

Prevent dumps being written to /tmp
When a dump is requested or forced, and the primary and secondary dump locations are unavailable, the JVM defaults to writing to /tmp.
From Service Refresh 13, this default behavior is prevented by using the option:

    -Xdump:nofailover

Hardware cryptographic provider configuration files must use a fully qualified path
Hardware cryptographic providers can be specified using a configuration file. Here is an example:
    name = HWtype_x
    library=C:/WINNT/system32/HWtype_x.dll
    description=the HWType_x hardware device config.
    slotListIndex = 0
From Service Refresh 13, you must use a fully qualified path in the configuration file.
For more information about using the IBM hardware cryptographic providers, see https://www.ibm.com/developerworks/java/jdk/security/50/.

Go back to the top


PKCS11 security provider

There are a number of changes to cryptographic cards supported on this release
The following cards are supported on Microsoft Windows (32-bit), AIX®, Solaris (32-bit and 64-bit, Sparc only), Linux:


Cryptographic card Support information
nCipher nForce 4000 PCI(OB4033P-4K0) No longer available but still supported. Compatible with the Thales nShield Solo 4000 PCI (NC4033P-4KO)
Thales nShield Solo 500 PCI(nC4033P-500) This card has been rebranded and was formerly known as the nCipher nShield 500 PCI(nC4033P-500)
Thales nShield Solo 2000 PCI(nC4033P-2k0) This card has been rebranded and was formerly known as the nCipher nShield 2000 PCI(nC4033P-2k0)
Thales nShield Solo 4000 PCI (NC4033P-4K0) This card has been rebranded and was formerly known as the nCipher nShield 4000 PCI (nC4033P-4000)
Eracom Orange (CSA8000)
SafeNet Luna SA 4.0 Supported from service refresh 14 onwards
SafeNet Luna SA 4.5 Supported from service refresh 14 onwards
SafeNet Luna SA 5.0 Thales nShield Edge Supported from service refresh 14 onwards
Thales nShield Edge Supported from service refresh 14 onwards (Windows only)
Thales nShield Connect 1500 Supported from service refresh 14 onwards

The following cards are no longer available or supported:
  • nCipher nForce 1600 PCI(nC3033P-1k6)
  • nCipher nForce 150 PCI(nc3033P-150)
  • nCipher nShield 800 PCI(nC4033P-800)
  • nCipher nShield 150 SCSI(nc4032W-150)
  • nCipher nShield 150 SCSI(nF300KM-1c)
  • nCipher nForce 300 PCI
  • nCipher nForce 400 PCI
  • nCipher nForce 400 SCSI
  • nCipher nShield 400 SCSI
  • nCipher nShield 150 PCI
  • nCipher nShield 300 PCI
  • nCipher netHSM 300 PCI
  • nCipher netHSM 800 PCI
  • nCipher netHSM 1600 (nH1956)
  • SafeNet Luna SA 3.0


The following cards are supported on Microsoft Windows (32-bit), AIX, Solaris
(32-bit and 64-bit, Sparc only), Linux. These specific models have not been tested by IBM, but support is assumed because other cards in the same family have been tested successfully:


Cryptographic card Support information
Thales nShield Solo 4000 PCI (NC4033P-4K0) This card has been rebranded and was formerly known as the nCipher nShield 4000 PCI (nC4033P-4000)
nCipher netHSM 500 (nC4333N-500)
nCipher netHSM 2000 (nC4333N-2K0)
Thales nShield Connect 500 Supported from service refresh 14 onwards
Thales nShield Connect 6000 Supported from service refresh 14 onwards


The following card is supported in a limited fashion on the AIX platform, in both 32-bit and 64-bit modes:
  • The IBM 4765 PCIe Cryptographic Coprocessor is supported for use only by Tivoli Key Lifecycle Manager (TKLM) release 2.0.1, and follow-on releases.

Note: For TKLM, only the following PKCS#11 crypto operations are supported:
  • Translate an AES 128-bit or 256-bit software key to an AES hardware (PKCS#11) key
  • Generate an AES 128-bit or 256-bit key
  • Encrypt and decrypt data using an AES key and an AES/ECB/NoPadding cipher
  • Store and retrieve an AES key to/from a PKCS11IMPLKS (PKCS#11) key store

Go back to the top


Corrections to Information Center documentation:

The following command-line option is available from service refresh 9:

-Xloaminimum
You can use the following command-line option to manage the size of the large object area:
-Xloaminimum<percentage>

  • Specifies the minimum percentage (between 0 and 0.95) of the current tenure space allocated to the large object area (LOA). The LOA does not shrink below this value. The default value is 0, which is 0%.
The following command-line options are incorrectly documented for Java 5.0 and cannot be used for tuning:
  • -XlockReservation
  • -XtlhPrefetch


Go back to the top

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Runtimes for Java Technology
General

Software version:

5.0

Operating system(s):

AIX, HP-UX, Linux, Linux zSeries, Solaris, Windows, z/OS

Reference #:

1567199

Modified date:

2013-07-03

Translate my page

Machine Translation

Content navigation