Hi Brian Thank you for the feedback. Well we can do interface changes as long as they are backwards compatible. The package is backwards compatible. The problem here is that the fix is in a new function that no software will use and hence the fix is useless unless we also change all software using nettle.
How do we handle this kind of problem? Should all software using the insecure function be mapped to the same CVE, or should there in fact be different CVEs for each package that is insecure? Cheers // Ola On Wed, 9 Jan 2019 at 22:35, Brian May <b...@debian.org> wrote: > 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> > -- --- Inguza Technology AB --- MSc in Information Technology ---- / o...@inguza.com Folkebogatan 26 \ | o...@debian.org 654 68 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
