[flagged]
Psychic Signatures in Java
91–100 of 128 posts
Re: Psychic Signatures in Java
#92Earlier quoted context omitted.
Azul published updated packages yesterday, including for some older non-LTS Java versions: https://www.azul.com/downloads/?package=jdk#download-openjdk
Thanks for the info! That's very interesting since they usually only provide out-of-cycle critical fixes for their paid tiers. On the other hand - this only proves that it's actually possible to provide a hot-fixed OpenJDK in time. Unfortunately, I assume that a very common case is just using the distribution provided openjdk-package and configuring the system for auto updates. So the main issue here is that a seriou…
I wouldn't use your distros version of OpenJdk. If you want fast updates, you need to be using Azul or some other provider who is dedicated to it.
Re: Psychic Signatures in Java
#93The title of the blogpost is now updated to "CVE-2022-21449: Psychic Signatures in Java" - maybe this HN post could too?
Agreed (@dang)
Re: Psychic Signatures in Java
#94The fix for OpenJDK (authored on Jan. 4th 22): https://github.com/openjdk/jdk/blob/e2f8ce9c3ff4518e070960ba...
I spot no test or comment in the code on why this assertion is important.
It's literally what the whole bug is about. From OP's article:
>This is why the very first check in the ECDSA verification algorithm is to ensure that r and s are both >= 1. Guess which check Java forgot?
Re: Psychic Signatures in Java
#95Earlier quoted context omitted.
Thanks for the info! That's very interesting since they usually only provide out-of-cycle critical fixes for their paid tiers. On the other hand - this only proves that it's actually possible to provide a hot-fixed OpenJDK in time. Unfortunately, I assume that a very common case is just using the distribution provided openjdk-package and configuring the system for auto updates. So the main issue here is that a seriou…
I wouldn't use your distros version of OpenJdk. If you want fast updates, you need to be using Azul or some other provider who is dedicated to it.
I can see how this would have helped in this case.
As I see it, the distributions are mostly relying on the upstream provisioning of the openJDK project. So if they fix this issue, it shouldn't take long until we see updated packages in all major distributions. This might be a problem specific to the openJDK build process, so a different package source would help in that case.
But as mentioned above, Azul usually doesn't provide out-of-cycle critical fixes without a paid plan. And most people will still use whatever the distribution provides - so this is still an issue regardless of alternative package sources.
And since I assume that many or most running JDK instances actually are coming from the distributions repository rather than an alternative source, and there is literally no outcry regarding the missing packages whatsoever - I fear that there are a lot of vulnerable software systems of people not knowing about it right now.
Re: Psychic Signatures in Java
#96Earlier quoted context omitted.
That’s all true, but fuzz testing is very effective at checking boundary conditions (near 0, near max/mins) and would have caught this particular problem easily.
Do you mean fuzz testing does not use even distributions? There’s a bias towards extrema, or at least some guarantee to test zero and MAX? I guess that would work. Also, would you consider the following to be fuzz testing? https://github.com/LoupVaillant/Monocypher/blob/master/tests...
The usual trick is coverage-guided fuzzing. https://google.github.io/clusterfuzz/reference/coverage-guid...
Re: Psychic Signatures in Java
#97Earlier quoted context omitted.
> It will use some kind of symmetric algo (generally AES). AES-GCM, you mean. Let's not forget the authentication in "authenticated encryption" . I'm nitpicking, but if a beginner comes here it's better to make it clear that in general, encryption alone is not enough. Ciphertext malleability and all that.
Plenty of stuff still uses CBC (or other modes) with another authentication method. AES-GCM is nice in that it combines both explicitly, but a lot of stuff just combines other methods and it’s fine. AES-GCM has the annoying property of output size > input size for instance.
All secure encryption has an output size greater than its input size.
Re: Psychic Signatures in Java
#98And 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…
Was Spring4Shell Java's fault, or Spring's fault? Log4Shell was obviously (mostly) log4j's fault. This one, I gather, is actually Java's fault. It sounds like three unrelated security bugs from totally different teams of developers.
Spring4Shell is entirely a flaw in Spring, however is somewhat understandable because it was only exploitable due to a new feature in Java (modules) that added new methods to java.lang.Class, which is a very significant change. You could argue the very existence and nature of Java object serialization deserves blame as well, but that gets nuanced quickly.
Modules are also part of the reason why so many folks got "stuck" on java 8.
It is definitely an interesting study in the challenges of trying to make advances in a platform when a lot of the ecosystem is very much in maintenance mode and may not have a lot of eyes on the combination of existing libraries vs new versions of Java.
Re: Psychic Signatures in Java
#99What puzzles me most is that two days after the announcement of the vulnerability and the release of the patched Oracle JDK, there is still no patched version of OpenJDK for most distributions. We're running some production services on OpenJDK and CentOS and until now there are only two options to be safe: shutdown the services or change the crypto provider to BouncyCastle or something else. The official OpenJDK proj…
Amazon had releases of Corretto available on April 19th, Corretto 17 was released before 10am PDT, less than one hour after the announcement
Re: Psychic Signatures in Java
#100Earlier quoted context omitted.
> It will use some kind of symmetric algo (generally AES). AES-GCM, you mean. Let's not forget the authentication in "authenticated encryption" . I'm nitpicking, but if a beginner comes here it's better to make it clear that in general, encryption alone is not enough. Ciphertext malleability and all that.
Plenty of stuff still uses CBC (or other modes) with another authentication method. AES-GCM is nice in that it combines both explicitly, but a lot of stuff just combines other methods and it’s fine. AES-GCM has the annoying property of output size > input size for instance.
I was just trying to mention the most widespread method. Sure you can use AES-CBC or AES-CTR, and combine it with HMAC or keyed BLAKE2…
but as tptaceck pointed out, all authentication methods are going to increase your message size. It's unavoidable: to get authentication you need some redundancy, and the only general way to get that redundancy is to have a message bigger than the plaintext. We do have attempts at length preserving authenticated encryption, but as far as I know they're not as well studied as the classical "encrypt-then-mac" methods such as AES-CBC + HMAC or AES-GCM. https://security.googleblog.com/2019/02/introducing-adiantum...