‘Crypto Bug of the Year’ Fixed — Update Java NOW
A ridiculously dumb flaw in Java’s signature checking code is now patched. The Elliptic Curve Digital Signature Algorithm (ECDSA) allowed a “blank” signature to be waved through. Doctor Who fans will recognize the reference in the “Psychic Signatures” moniker.
It affects every supported version of Java. Ironically, most unsupported versions are OK—it was introduced in Java 15 when Oracle sloppily ported some C++ code to native Java. So it isn’t some crufty legacy Sun code, but actual garbage Oracle sloppiness that’s causing IT people to chase their tails yet again. What’s worse, Oracle is trying to downplay the bug’s severity.
Duke isn’t looking so chipper recently. In today’s SB Blogwatch, we wonder what other nasties are lurking in Java.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Psychic whatnow?
Thumbs Down for Oracle
What’s the craic? Dan Goodin reports—“Major cryptography blunder in Java”:
“Place a high priority on patching”
A critical vulnerability can make it easy for adversaries to forge TLS certificates and signatures, two-factor authentication messages, and authorization credentials generated by a range of widely used open standards. [It] affects … the [ECDSA] in Java versions 15 and above.
…
The bug, tracked as CVE-2022-21449, carries a severity rating of 7.5 out of a possible 10, but … Neil Madden, the researcher at security firm ForgeRock who discovered the vulnerability [said] he’d rate the severity at a perfect 10. … In its grimmest form, the bug could be exploited by someone outside a vulnerable network with no verification at all.
…
Organizations … using any of the affected versions of Java to validate signatures should place a high priority on patching. [And] monitor for advisories from app and product makers to see if any of their wares are made vulnerable.
And Liam Proven correctly uses the C-word—“Oracle already wins ‘crypto bug of the year’”:
“The new Java code didn’t check”
The scope of the damage that could be done is wide: Encrypted communications, authentication tokens, code updates, and more, built on Oracle’s flawed code could be subverted, and as far as vulnerable Java-written programs are concerned, the data looks legitimate and trustworthy. … And this is on top of the gazillon remote-code execution flaws … in Oracle’s other products. … So, as always, update early and update often.
…
What’s particularly interesting about this issue is that it’s incredibly easy to exploit, and an obvious programming error. The bug was introduced when part of Java 15’s signature-verification code was rewritten from its native C++. … An ECDSA signature consists of a pair of numbers, referred to as (r, s). … For a signature to be valid, (r, s) cannot be (0, 0) because some of the math involves multiplying these numbers with other values.
…
The original C++ code checked that both r and s are non-zero [but] the new Java code didn’t check. … The upshot is that … anyone who presents a blank signature will be accepted.
Liam was quoting Thomas H. Ptacek—@tqbf:
“Don’t use asymmetric cryptography unless you absolutely need it”
Welp. It’s the crypto bug of the year. Mark it down for April. Java 15-18 ECDSA doesn’t sanity check that the random x coordinate and signature proof are nonzero; a (0,0) signature validates any message. Breaks JWT, SAML, &c.
…
The broader issue here [is] people use ECDSA … without extremely compelling reasons to. … People get mad at me for saying [it, but] it’s true: … Don’t use asymmetric cryptography unless you absolutely need it. [It’s] just a basic cryptographic risk management principle.
u mad bro? smegsicle explainifies:
If people were getting mad at him, he must have been pretty obnoxious about it because I don’t think there’s much controversy—asymmetric encryption is pretty much just used for things like sharing the symmetric key that will be used for the rest of the session. Of course, it would be more secure to have private physical key exchange, but that’s not a practical option, so we rely on RSA or whatever.
Who found it? Neil Madden—“CVE-2022-21449: Psychic Signatures”:
“I am not at all confident that other bugs aren’t lurking in this code”
The long-running BBC sci-fi show Doctor Who has a recurring plot device … “psychic paper“, which causes the person looking at it to see whatever the Doctor wants them to see: a security pass, a warrant, or whatever. … It turns out that some recent releases of Java were vulnerable to a similar kind of trick.
…
It’s hard to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update. … Note that 15 and 16 are no longer supported, so [the CVE] will only list 17 and 18 as impacted. … For context, almost all WebAuthn/FIDO devices in the real world … use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs. … If you have deployed Java 15 [to] 18 in production then you should stop what you are doing and immediately update.
…
It would obviously be a really bad thing if r and s were both 0, because then you’d be checking that 0 = 0 ⨉ [a bunch of stuff], which will be true regardless of the value of [a bunch of stuff]! … Even the most cursory reading of the ECDSA spec would surely suggest testing that invalid r and s values are rejected. I am not at all confident that other bugs aren’t lurking in this code.
So every supported version of Java is affected? cesarb offers a Modest Proposal:
And once again, you’d be saved if you stayed on an older release. This is the third time this has happened recently in the Java world: the Spring4Shell vulnerability only applies to Java 9 and later (that vulnerability depends on the existence of a method introduced by Java 9, since all older methods were properly blacklisted by Spring), and the Log4Shell vulnerability only applies to log4j 2.x (so if you stayed with log4j 1.x, and didn’t explicitly configure it to use a vulnerable appender, you were safe). What’s going on with Java?
Kids today, eh? vogon00 stops short of typing, “Get off my lawn”:
Speaking as a former testing professional, I’d have to say I’m not surprised. ‘Testing’ stuff used to mean actually testing it, with the software equivalent of hammers and a proper test plan, rather than just waving a damp dishrag at it to see what happens.
…
I’d say the team/individual that ported this from C++ to Java have just [discovered] how ***** they are! Back in the day, any test exercised the low and high limits of any parameter/setting, and especially out-of-range values. … Crass stupidity.
It’s worse than that, opines Nikolai(km):
That is a huge miss. It seems like the parameter assertions r!=0, s!=0 is fundamental.
…
Anyone unit testing this stuff? … Even on Wikipedia, it’s the first step, SMH.
Meanwhile, where else might Oracle have made the same error? Paul Herber knows:
There is a similar bug in all of Oracle’s customer compliance tools. Even if the number of users=0 and the amount of usage by these users=0, then the compliance tool shows that the customer has got to pay Oracle some more money.
And Finally:
Still confused? Dr. Mike Pound explains
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Hartmann Studios, via Oracle PR (cc:by; leveled and cropped)
