Bug 1582571 (CVE-2018-10844) - CVE-2018-10844 gnutls: HMAC-SHA-256 vulnerable to Lucky thirteen attack due to not enough dummy function calls
Summary: CVE-2018-10844 gnutls: HMAC-SHA-256 vulnerable to Lucky thirteen attack due t...
Alias: CVE-2018-10844
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1589703 1589704 1619509 1619510 1619511 1619512 1619513 1622402 1802259 1802260
Blocks: 1582575
TreeView+ depends on / blocked
Reported: 2018-05-25 15:30 UTC by Adam Mariš
Modified: 2023-09-23 18:11 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
It was found that GnuTLS's implementation of HMAC-SHA-256 was vulnerable to Lucky Thirteen-style attack. A remote attacker could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets.
Clone Of:
Last Closed: 2019-06-10 10:26:36 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3050 0 None None None 2018-10-30 07:24:59 UTC

Description Adam Mariš 2018-05-25 15:30:42 UTC
It was found that GnuTLS implementation of HMAC-SHA-256 was vulnerable to Lucky thirteen style attack due to the fact that not enough dummy compression function calls are added to cater for every situation.

Comment 5 Huzaifa S. Sidhpurwala 2018-08-21 05:44:26 UTC
External References:


Comment 6 Huzaifa S. Sidhpurwala 2018-08-21 05:45:19 UTC
Created gnutls tracking bugs for this issue:

Affects: fedora-all [bug 1619510]

Created gnutls30 tracking bugs for this issue:

Affects: epel-all [bug 1619512]

Created mingw-gnutls tracking bugs for this issue:

Affects: epel-all [bug 1619513]
Affects: fedora-all [bug 1619511]

Comment 8 Huzaifa S. Sidhpurwala 2018-08-21 06:01:51 UTC
Upstream patch:


Comment 11 anarcat 2018-09-28 20:01:26 UTC
Upstream (gnutls) folks claim this issue was fixed in later releases, but that claim seems to be disputed by the paper authors:

> However, we believe that the GnuTLS code is still vulnerable to
> variants of the attacks presented in our paper due to its
> padding-dependent memory accesses. We notified the GnuTLS team of our
> concerns about this on June 13th 2018. Our understanding is that the
> GnuTLS team does not plan to address the issues, but prefers to
> promote the use of Encrypt-then-MAC (as specified in RFC 7366) when
> legacy cipher suites are required.

I noticed that Red Hat issued the three CVEs associated with that paper... Does the Red Hat security team have any insight on the approach that should be taken to fix those problems correctly?



Comment 12 Nikos Mavrogiannopoulos 2018-10-01 07:03:12 UTC
I do not speak for the red hat product security, however the upstream log indicates the fix:

> ** Improved counter-measures for TLS CBC record padding. Kenny Paterson, Eyal Ronen
>   and Adi Shamir reported that the existing counter-measures had certain issues and
>   were insufficient when the attacker has additional access to the CPU cache and 
>   performs a chosen-plaintext attack. This affected the legacy CBC ciphersuites. [CVSS: medium]

> ** The ciphers utilizing HMAC-SHA384 and SHA256 have been removed from the default
>   priority strings. They are not necessary for compatibility or other purpose and
>   provide no advantage over their SHA1 counter-parts, as they all depend on the legacy
>   TLS CBC block mode.

That is, the existing counter-measures present were improved to protect against this attack. Indeed the paper authors mention that this may not be sufficient to counter other future attacks, and they are correct in that. How critical however would be such future attacks? For that one must note what is the actual impact of this attack. This type of attacks does only affect the legacy HMAC-based ciphersuites  and only when the gnutls peer does not implement the encrypt-then-mac construction. That's why the majority of HMAC ciphersuites are now disabled by default keeping HMAC-SHA1 for compatibility only.

Comment 13 errata-xmlrpc 2018-10-30 07:24:51 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2018:3050 https://access.redhat.com/errata/RHSA-2018:3050

Note You need to log in before you can comment on or make changes to this bug.