Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 13:29:29, Ola Lundqvist wrote:
> Hi all LTS contributors
>
> My question is whether removing default ciphers and introducing new
> options is acceptable so late in the release cyckle. My assumption is
> no, but let me know if you have another opinion. More details below.
A priori, I think it is if it fixes serious security vulnerabilities and
there is no easier way to do so.
> If you have seen my email to ELTS then you may read faster. It is not
> identical as the Jessie version is significantly easier to port than
> the wheezy version.
I'm not on the ELTS mailing list, so hopefully this email has all the
information I need. :)
> I think I need some advice. I have investigated the following issues for gnutls.
> CVE-2018-10844
> CVE-2018-10845
> CVE-2018-10846
>
> I hope to spare you the time to read the full scientific paper on this matter.
Did you actually read it? :) It's pretty interesting...
> The overall problem is that by running some piece of software on the
> same CPU as the gnutls software is running it is possible to decrypt
> the plaintext by very smart techniques to deduce things from timing
> differences. OpenSSL has fully addressed this by always taking exactly
> the same time regardless of the input data but this was not properly
> done for gnutls.
Or rather, they took a "pseudo-constant time" approach, which the paper
demonstrates as exploitable.
> Upstream do in fact not even plan to do this as the problem only occur
> in the following cases:
> - CBC cipher
> - If Encrypt-then-MAC (RFC7366) is unsupported by the peer
>
> Instead upstream have done the following:
> 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846)
> 2) Do a fix with SHA384 (for CVE-2018-10845)
> 3) Remove SHA256 and SHA384 from the default MAC ciphers (for
> CVE-2018-10844 and CVE-2018-10845)
> 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845)
>
> 1: I do not think we can do 1 such late in the release cycle. I mean
> new options now would be rather pointless. I will mark CVE-2018-10846
> as ignored due to this. Or do you think new options is ok also in
> Jessie?
I looked at the upstream patch (MR#657) for this and it doesn't look
that invasive. According to GitLab, it is "21 files with 738 additions
and 148 deletions", which seems fairly small considering the scope of
the change:
https://gitlab.com/gnutls/gnutls/merge_requests/657.patch
> 2: 2 is easy to do but as SHA384 is not part of the default ciphers I
> see limited value. I do not think it is worth it on its own.
Upstream issue says this "should addressed in [...] 3.3" which means
they might have rolled out a patch for our precious jessie release on
this:
https://gitlab.com/gnutls/gnutls/issues/455
So I think it would make sense do backport that work - according to the
security tracker, there's a minimal patch that might fix this in:
https://gitlab.com/gnutls/gnutls/commit/cc14ec5ece856cb083d64e6a5a8657323da661cb
But that is also part of the the larger fix in CVE-2018-10846 from what
I understand, that is MR#657.
> 3: Should we remove SHA256 and SHA384 from the default MAC ciphers? It
> add some extra protection against this but it is a backwards
> compatibility problem and therefore may not be good from an
> availability perspective. I'm not sure how good it is to remove
> ciphers such late in the release cycle either. SHA256 and SHA384 is
> mostly deprecated now when AEAD cipher is available but still the peer
> could be an old version (for example AEAD was not supported in
> wheezy).
This is an interesting question. On the one hand, it would be good to
fix this, but on the other hand, one of the reasons people run LTS is
exactly that kind of stuff. I am not sure it would be a good idea to
completely remove a *protocol* from the supported list, unless we have a
better idea of how frequently used it is.
GnuTLS is a particularly sticky problem because it's not as widely used
as OpenSSL, and it's not clear to me *where* exactly it's used. I know
we used to link against it in the Charybdis IRCd, for example, but that
caused all sorts of problems so I switched the Debian package to mbedtls
in 3.5.5 and above, which means buster and later, which means stretch
and jessie and before still all link to gnutls and would suffer from
those issues.
I would look at what upstream did for earlier releases here.
> 4: Will do this and I do not think the backporting work is that
> complicated. I will investigate a little more.
It does look like there's a simpler fix that's usable for only fixing
CVE-2018-10844, if the security tracker is accurate:
https://gitlab.com/gnutls/gnutls/commit/c32a8690f9f9b05994078fe9d2e7a41b18da5b09
This, again, is also part of the larger fix in MR#657.
Combined, those last two patches make about +- 50 lines of diff,
compared to the 700+ lines of diff for the larger merge request. But do
consider that a large part of MR#657 (+400 lines) is the introduction of
tests/tls-force-etm.c, a standalone file which shouldn't cause conflicts
at the very least.
> I think I should do 2 and 4, but not 1 and 3.
>
> What do you think? If I do not hear any objections I'll do so.
I would give it a shot and try to backport the whole thing. I would also
carefully look at the 3.3.x series to see if there's an official commit
shipping those. At first glance, it does look like a release was made on
all branches, including a 3.3.30 release that bundles some of those
patches.
In fact, I'd be tempted to seriously consider upgrading to that upstream
release after comparing our changelog with theirs to see if there's
anything missing either side...
It seems that upstream did the right thing here and backported a bunch
of stuff for us already - it'd be too bad to waste that effort and skip
those CVEs. ;)
A.
--
À force de ne jamais réfléchir, on a un bonheur stupide
- Jean Cocteau
Reply to: