Nasty ECDSA asymmetric cryptographic bug in Java.

Effects Java 15, 16, and 17, and 18, and a whole lot of dependent
products from Oracle and elsewhere.

The fix is reportedly included in the Oracle April 2022 critical update
for Java.

Seven other cryptographic flaws effecting Java 7, 8, and 11, and which
might (does?) mean that OpenVMS users of Java (VSI OpenJDK V8.0 u222,
HP/HPE Java JDK) are also vulnerable to remote exploitation.

https://www.oracle.com/security-alerts/cpuapr2022.html

Given what all has been happening in aggregate and more generally,
y'all really don't want to be down-revision on your critical patches.

--
Pure Personal Opinion | HoffmanLabs LLC

On 4/20/2022 2:36 PM, Stephen Hoffman wrote:
> Nasty ECDSA asymmetric cryptographic bug in Java.

CVE-2022-0778 is indeed a nasty bug - some bad data
during SSL handshake will cause an infinite loop.

But it is a bug in OpenSSL.

It does impact GraalVM but not the Java part - the node.js part
as it apparently use OpenSSL.

(GraalVM is a rather weird bundle of products)

> Effects Java 15, 16, and 17, and 18, and a whole lot of dependent
> products from Oracle and elsewhere.

No Java at all.

> Seven other cryptographic flaws effecting Java 7, 8, and 11, and which
> might (does?) mean that OpenVMS users of Java (VSI OpenJDK V8.0 u222,
> HP/HPE Java JDK) are also vulnerable to remote exploitation.
>
> https://www.oracle.com/security-alerts/cpuapr2022.html

A bunch of bugs CVE-2022-21449, CVE-2022-21476,
CVE-2022-21426, CVE-2022-21496, CVE-2022-21434 and CVE-2022-21443
impacts Java 7, 8, 11, 17 and 18. They may very likely also
impact 9, 10, 12, 13, 14, 15 and 16 - but those are non-LTS versions
are out of support. It also impacts the GraalVM versions that
use those Java versions.

There is every reason to believe that the problematic code
is also in VMS I64 Java 8.

But per the note at Oracle and the similar notes at Redhat then
all these CVE's relate to running untrusted code in a sandbox
(under security manager) - that means Java applets, Java Web Start
and similar custom solutions.

It are serious bugs as it allows the code to break out of the sandbox
and access files.

But my best guess is that zero VMS sites are using any of this.

> Given what all has been happening in aggregate and more generally, y'all
> really don't want to be down-revision on your critical patches.

That is always good advice.

Arne

On 4/20/2022 3:10 PM, Arne Vajhøj wrote:
> On 4/20/2022 2:36 PM, Stephen Hoffman wrote:
>> Seven other cryptographic flaws effecting Java 7, 8, and 11, and which
>> might (does?) mean that OpenVMS users of Java (VSI OpenJDK V8.0 u222,
>> HP/HPE Java JDK) are also vulnerable to remote exploitation.
>>
>> https://www.oracle.com/security-alerts/cpuapr2022.html
>
> A bunch of bugs CVE-2022-21449, CVE-2022-21476,
> CVE-2022-21426, CVE-2022-21496, CVE-2022-21434 and CVE-2022-21443
> impacts Java 7, 8, 11, 17 and 18. They may very likely also
> impact 9, 10, 12, 13, 14, 15 and 16 - but those are non-LTS versions
> are out of support. It also impacts the GraalVM versions that
> use those Java versions.
>
> There is every reason to believe that the problematic code
> is also in VMS I64 Java 8.
>
> But per the note at Oracle and the similar notes at Redhat then
> all these CVE's relate to running untrusted code in a sandbox
> (under security manager) - that means Java applets, Java Web Start
> and similar custom solutions.
>
> It are serious bugs as it allows the code to break out of the sandbox
> and access files.
>
> But my best guess is that zero VMS sites are using any of this.

Two additions:

1) some sources say that CVE-2022-21449 is not limited to sandboxed
environments, so it could apply to typical VMS scenarios

2) some sources say that CVE-2022-21449 only applies to Java 15 and
newer (which is not available for VMS)

Arne

On 4/21/2022 7:32 AM, Arne Vajhøj wrote:
> On 4/20/2022 3:10 PM, Arne Vajhøj wrote:
>> On 4/20/2022 2:36 PM, Stephen Hoffman wrote:
>>> Seven other cryptographic flaws effecting Java 7, 8, and 11, and
>>> which might (does?) mean that OpenVMS users of Java (VSI OpenJDK V8.0
>>> u222, HP/HPE Java JDK) are also vulnerable to remote exploitation.
>>>
>>> https://www.oracle.com/security-alerts/cpuapr2022.html
>>
>> A bunch of bugs CVE-2022-21449, CVE-2022-21476,
>> CVE-2022-21426, CVE-2022-21496, CVE-2022-21434 and CVE-2022-21443
>> impacts Java 7, 8, 11, 17 and 18. They may very likely also
>> impact 9, 10, 12, 13, 14, 15 and 16 - but those are non-LTS versions
>> are out of support. It also impacts the GraalVM versions that
>> use those Java versions.
>>
>> There is every reason to believe that the problematic code
>> is also in VMS I64 Java 8.
>>
>> But per the note at Oracle and the similar notes at Redhat then
>> all these CVE's relate to running untrusted code in a sandbox
>> (under security manager) - that means Java applets, Java Web Start
>> and similar custom solutions.
>>
>> It are serious bugs as it allows the code to break out of the sandbox
>> and access files.
>>
>> But my best guess is that zero VMS sites are using any of this.
>
> Two additions:
>
> 1) some sources say that CVE-2022-21449 is not limited to sandboxed
>    environments, so it could apply to typical VMS scenarios
>
> 2) some sources say that CVE-2022-21449 only applies to Java 15 and
>    newer (which is not available for VMS)

CVE-2022-21449 is totally crazy BTW:

<quote>
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.
....
But, as Madden discovered, a totally blank “psychic signature”, if
presented to Java’s Elliptic Curve verification code, would be flagged
as valid when “verified” against any public key.

In other words, an attacker would need either to hack into your network
and steal your private keys in order to masquerade as you…

…or simply to present a blank signature to pass muster every time!
</quote>

Arne

On 2022-04-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> CVE-2022-21449 is totally crazy BTW:
>
><quote>
> 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.
> ...
> But, as Madden discovered, a totally blank ?psychic signature?, if
> presented to Java?s Elliptic Curve verification code, would be flagged
> as valid when ?verified? against any public key.
>
> In other words, an attacker would need either to hack into your network
> and steal your private keys in order to masquerade as you?
>
> ?or simply to present a blank signature to pass muster every time!
></quote>
>

It reminds me of this:

https://www.theregister.com/2017/05/05/intel_amt_remote_exploit/

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.