Hi AndreasIt looks like you have managed without the context. I'm sorry that I was a little too brief.First thank you a lot for confirming that gnutls do not use nettle in wheezy. This is very good to know as I can safely patch nettle without considering gnutls usage of nettle. Thanks! It saves me the burden of patching and coordinating several uploads.The follow up patches that are needed are to modify gnutls (as long as it is using nettle).This (below) is what I have understood from Niels Möller. He is the source of my knowledge so please be in contact with him about the details.The correction in nettle is to use mpz_powm_sec instead of mpz_powm. The problem is that mpz_powm_sec will crash if the modulo argument is an even number. So a check is needed to ensure that or else we have a denial of service problem.You can see the detailed correction here:Nettle have added such checks in the *_key_prepare functions, see here:I think this merge commit may be of help:The issue is that gnutls do not use (or do not check the return code) these prepare functions so there is therefore nothing that prevent the service from crashing in case an invalid signature is provided. The attack would for example be possible on some service provider having a common web server for multiple clients where the client can add their own certificate/key. In such case the whole server will go down instead of just this client.So a check is needed in gnutls to check that the modulo is not even. This can be done either by using the prepare functions (and check the return code) or by checking it explicitly.Was this enough context?// Ola--On Sun, Aug 7, 2016 at 8:04 AM, Andreas Metzler <firstname.lastname@example.org> wrote:On 2016-08-07 Ola Lundqvist <email@example.com> wrote:
> On Sat, Aug 6, 2016 at 8:40 PM, Niels Möller <firstname.lastname@example.org> wrote:
>> Ola Lundqvist <email@example.com> writes:
>>> Magnus, Niels and I have been discussing the nettle update due to
>> Please note that some coordinatoino with gnutls may be needed, to avoid
>> a denial-of-service problem involving invalid private keys.
>>> I suggest something like this: "Protect against potential timing
>>> attacks against exponentiation operations as described in
>>> CVE-2016-6489 RSA code is vulnerable to cache sharing related
>> I'd suggest the more general "side-channel attacks" over "timing
> I do not think coordination with gnutls is needed. I can not see that
> gnutls depend on nettle in wheezy.
> I can see that it can potentially do that, but I do not think it do.
> There are no dependencies declared on nettle library and from unstable
> changelog it looks like this build dependency was first added in gnutls28.
> Wheezy has gnutls28.
> I may be wrong however.
> Or can it be so that nettle is built in statically and that a build
> dependency is not needed as some other package has a build dependency so we
> get it indirectly?
> I'm including the gnutls maintainers to get their opinion.
I think I am missing a little bit context, according to the security
tracker the issue applies to practically all versions of, from oldstable
up to and including unstable but the discussion seems to focus on LTS.
You are right regarding wheezy/oldstable. It shipped gnutls 2.12.x built
against libgcrypt instead of nettle, there should not be a problem with
a nettle update. 3.3.8 (using nettle) is in wheezy-backports, but that
is not covered by LTS afaiu.
I am wondering about stable/testing/sid though.
"Original patch had some unintended side effects:", e.g. breaking
GnuTLS. There is a lot of discussion following, however I failed to get
whether the followup patches commited to nettle git did away with the
"unintended side effects" or whether we still need to coordinate for
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- Inguza Technology AB --- MSc in Information Technology ----/ firstname.lastname@example.org Folkebogatan 26 \| email@example.com 654 68 KARLSTAD |\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /-----------------------------