Oracle already wins 'crypto bug of the year' with Java digital signature bypass Java versions 15 to 18 contain a flaw in its ECDSA signature validation that makes it trivial for miscreants to digitally sign files and other data as if they were legit organizations. Cyber-criminals could therefore pass off cryptographically signed malicious downloads and bogus information as if it were real, and affected …
There are trusted CAs that have ECDSA root certificates trusted by all OSs and browsers.
With this vulnerability, anyone can create certificates allowing them to impersonate any TLS server they like. This allows an attacker who is able to intercept traffic, to view and change your communications with any TLS server.
Are you sure about that?
I'm trying to work out how to exploit this, not least because we do EC crypto in Java.
I can see that it would be possible to create an EC signature that's always be considered valid for any data, when verified in Java. And that EC could be used to sign another public key, as you've described, to effectively issue any certificate. But unless the all-signing EC key is in the list of trusted roots, it's still going to be treated as a valid chain from an unknown root.
Put another way: the signer can now sign something that can be modified but looks like it remains signed. At this point I'm struggling a bit to see how a third-party could capitalise on this. Anyone?
Read the writeup at https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ - it turns out it is kind of a big deal.
Well, when money becomes zero (unsigned integer overflow), then (all 0 in Oracle) is a good thing.
It gets even better if we assume an integer overflow because (all INT_MIN in Oracle) is a huge win for humanity because they will finally have redistributed the wealth back to us all. Keep incrementing!
The whole thing sounds like a lack of serious testing. I have written a fair bit of numerical code over the past few years and one of the things that I learned was that there is lots of room for all sorts of non-obvious errors. The only viable solution seemed to be testing. I just ran a check over one project and have roughly 5 times as much testing code as there is code which is being tested.
Since it isn't possible to test every possible numerical combination (although test values can be generated algorithmicly), a good sense of what sort of numbers can be problematic is necessary.
Testing for (0, 0) is one of those really obvious problematic value pairs if you are doing anything involving any numerical operations. There are so many errors associated with 0 that if you are going to test anything at all, it should be 0.
This really raises the question for me that if they didn't test (0, 0), do they have any systematic testing at all? Or did they just pick a few numbers at random and checked to see that they got the same answer as the C++ implementation and called it a day?
This is not exactly confidence inspiring if that's the case.
"if you are going to test anything at all, it should be 0."
Upvoted for that..
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.
They say zero must be discovered. I'd say the team/individual that ported this from CPP to Java have just made a different discovery - how shite they are!
Back in the day, any test exercised the low and high limits of any parameter/setting, and especially out-of-range values. Not being an Oracle user, I'm a bit meah about them, however I hope they get a hammering somehow for their crass stupidity.
Zero x Zero is acceptable....really?
"Testing for (0, 0) is one of those really obvious problematic value pairs if you are doing anything involving any numerical operations. There are so many errors associated with 0 that if you are going to test anything at all, it should be 0."
It's worth noting that this isn't simply a question of not thinking of some obvious code tests. r and s being positive integers is part of the definition of ECDSA. It's literally step 1 of the verification (from Wiki):
"1. Verify that r and s are integers in [ 1 , n − 1 ]. If not, the signature is invalid."
They didn't simply fail to parse inputs for an otherwise correct implementation, they clearly didn't bother actually reading the specification in the first place.
No. EC crypto is faster, both to sign and to verify, and _much_ faster than RSA for key generation (which matters if eg you generate an ephemeral key for each connection)
There is _no_ evidence that the NSA has found how to break EC in general. The dual-EC RBG back door was a very specific hack - and not applicable to EC in general. It's the difference between knowing the factors of a single large number (easy - because you generated it yourself from a couple of smaller primes), and being able to factor large numbers in general (hard).
Of course, I accept that if the NSA _had_ found how to break EC in general, they would do their damndest to keep that fact a secret - so absence of evidence is not proof of absence.
"In theory, 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 bug arose because the original C++ code checked that both r and s are non-zero, and wouldn't accept the signature if they were. The new Java code didn't check, it just went ahead and computed with the values."
Java needs to go!!!!!!!!!!
Too much impact from this poorly managed coding environment.
This just shows what I say about engineers and developers! (I work in an industry that hires both), there isn't a good idea they don't think needs fixing!
If the C++ code worked why fix it with JAVA! I find it hard to believe that JAVA would be faster! Or did they fire all their C++ devs!
A few years ago, before I retired, I was involved in a safety-critical exercise in code verification.
One of the modules involved a series of values and a quick-and-dirty checksum for integrity. The checksum was simply the sum of the values of the rest of the array (ignoring overflows).
Meanwhile, another procedure would, under certain circumstances, wipe the whole array by overwriting it with zeroes.
Somebody pointed out that the integrity checksum algorithm was so poor that the integrity check would still show "OK" even after the array had been zeroed out ...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
