Re: Nettle and CVE-2018-16869
Ola Lundqvist <ola@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 <bam@debian.org>
Reply to: