Ola Lundqvist <o...@inguza.com> writes: > It is described as the Bleichenbacher-style attack. When I read the > changelog diffing the source I find that this is fixed by introducing a new > function and that new function is recommended by packages that use nettle. > Due to that I do not find it suitable to change neither jessie (and not > stretch either) since the application software using nettle must be changed > too. This applies to buster and sid too by the way, but there it is at > least possible that some software will be updated before the release. > > It could still be good to update using the patch, but there is a potential > 60% performance penalty as well so maybe it is not worth it. > > If nobody complains I will therefore mark this CVE as "ignored". > > Any opinions?
I was looking into this yesterday, and coming up with similar conclusions. I don't think we can really include any API changes in a LTS release, even if they are required to fix security issues (???). From https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007363.html: "For Nettle, the RSA code, which I wrote some 15 years ago, have seen an overhawl. Not only making the handling of PKCS#1 on decryption side-channel silent (the vulnerabilities that could be exploited by the methods of the above paper), but also ensuring that we use side-channel silent functions for the needed bignum arithmetic. "This has been a lot of work, and most of it not done by me, but by Simo Sorce, at Red Hat Inc. Without this help, it would have been difficult to get a good release out on time. "Testing of the release candidate is highly appreciated. I intend to make and announce the non-candidate release soon, possibly as early as tomorrow morning (i.e., December 1, in European timezone). A GnuTLS release, depending on the new rsa_sec_decrypt function in Nettle-3.4.1, is also being made about now. "My understanding is that there's no need to panic. The attack directly affects RSA decryption, not signatures. And it requires some resources to be pulled off. As far as I understand, a successful attack lets the attacker decrypt or sign a targeted message, e.g., compromising the TLS "premaster secret", corresponding session keys, and any transmitted passwords or login cookies sent in a single TLS session, but it does not expose the private key itself. "However, if you operate a TLS server, you should consider if you can completely disable key exchange based on RSA decryption. If you need to keep it for backwards compatibility, it is *strongly* encouraged to use a separate RSA key for this purpose, *not* reused or authorized for any other purpose." -- Brian May <b...@debian.org>
