Security update of nettle

Sun Aug 7 20:16:06 UTC 2016

Hi Andreas

It 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:
https://git.lysator.liu.se/nettle/nettle/commit/3fe1d6549765ecfb24f0b80b2ed086fdc818bff3

Nettle have added such checks in the *_key_prepare functions, see here:
https://git.lysator.liu.se/nettle/nettle/commit/5eb30d94f6f5f3f0cb9ba9ed24bc52b7376176b6
https://git.lysator.liu.se/nettle/nettle/commit/52b9223126b3f997c00d399166c006ae28669068
https://git.lysator.liu.se/nettle/nettle/commit/544b4047de689519ab3e6ec55b776b95b3e264a9

I think this merge commit may be of help:
https://git.lysator.liu.se/nettle/nettle/commit/b721591c051ce9e2304033dd19564f089775df17

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 <ametzler at bebt.de> wrote:

> On 2016-08-07 Ola Lundqvist <ola at inguza.com> wrote:
> > On Sat, Aug 6, 2016 at 8:40 PM, Niels Möller <nisse at lysator.liu.se>
> wrote:
> >> Ola Lundqvist <ola at inguza.com> writes:
> >>> Magnus, Niels and I have been discussing the nettle update due to
> >>> https://security-tracker.debian.org/tracker/CVE-2016-6489
>
> >> 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
> >>> attacks."
>
> >> I'd suggest the more general "side-channel attacks" over "timing
> >> attacks".
>
> > 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.
>
>
> Hello Ola,
>
> 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.
> https://security-tracker.debian.org/tracker/CVE-2016-6489 points to
> "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
> stable/testing/sid?
>
> cu Andreaas
> --
> `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 ----
/  ola at inguza.com                    Folkebogatan 26            \
|  opal at 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  /
 ---------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20160807/ce9d8b46/attachment.html>