Bug 1582571 (CVE-2018-10844)
| Summary: | CVE-2018-10844 gnutls: HMAC-SHA-256 vulnerable to Lucky thirteen attack due to not enough dummy function calls | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Adam Mariš <amaris> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | anarcat, ansasaki, erik-fedora, jv+fedora, mike, nmavrogi, pspacek, rh-spice-bugs, rjones, security-response-team, slawomir, tmraz |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-10 10:26:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1589703, 1589704, 1619509, 1619510, 1619511, 1619512, 1619513, 1622402, 1802259, 1802260 | ||
| Bug Blocks: | 1582575 | ||
|
Description
Adam Mariš
2018-05-25 15:30:42 UTC
External References: https://eprint.iacr.org/2018/747 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] Upstream patch: https://gitlab.com/gnutls/gnutls/merge_requests/657 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?
Thanks,
A.
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. 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 |