[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gnutls investigation and request for advice for Jessie



Hi Antoine

Thank you for the input this is valuable. I have some comments below.

On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré <anarcat@orangeseeds.org> wrote:
>
> 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.

I'm not so sure this is a serious issue as it is only exploitable in a
rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is
unsupported by the peer.
Most software do have that support as I understand it.

More on this below.

> > 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. :)

It should. I copied that email and adjusted it to suite Jessie.

> > 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...

Yes and it was really interesting. I must say that I'm impressed with
what they have achieved. It must have been a rather comprehensive
analysis.

> > 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.

Precisely, the "pseudo-constant time" was not the proper solution. In
fact OpenSSL had its problem in the beginning as well as I understood
from the paper.

> > 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

I agree on that. But introducing an option will not help in most cases
that use gnutls. I mean gnutls is used in most cases as a library and
unless the other software is changed then there is no use of
introducing the option.

657 includes 1, 2, 3, and 4 described in this email and some other
minor things too.

> > 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

Correct, I'm the one that added that entry to the security tracker. :-)

I also agree that we should do this, but only if we change any of the
other. I would not upload a new package with just this. But this is
more of a copy paste error from the ELTS email. I should have removed
that sentence about "not worth on its own".

> But that is also part of the the larger fix in CVE-2018-10846 from what
> I understand, that is MR#657.

Correct.

> > 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 run apt-rdepends -r on it and got a gazillion of packages. From
abiword to cups to... lot of others. I do not know if all of them
actually make use of it as many of them are things I did not even
thought had any encryption in it.

> 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

Again correct I added that entry. :-)

> 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.

But not the default cipher removal, right?

> 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...

That is another way. I'm not so comfortable with doing that
considering that I broke some software I did that with a library
package. I do not remember what library it was now but some browser
did not work after that.

> 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. ;)

:-D on the other hand maybe we break backwards compatibility. If it
wasn't for the backwards compatibility I would not have asked. :-)

Again thank you for the input.

Cheers

// Ola

>
> A.
>
> --
> À force de ne jamais réfléchir, on a un bonheur stupide
>                         - Jean Cocteau



-- 
 --- Inguza Technology AB --- MSc in Information Technology ----
/  ola@inguza.com                    Folkebogatan 26            \
|  opal@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  /
 ---------------------------------------------------------------


Reply to: