Bug 1536464 - ipxe: Processing of TLS records is vulnerable to timing attacks
Summary: ipxe: Processing of TLS records is vulnerable to timing attacks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1536465 1539167 1539168 1545493
Blocks: 1536467
TreeView+ depends on / blocked
 
Reported: 2018-01-19 13:29 UTC by Adam Mariš
Modified: 2021-10-21 19:53 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
It was found that TLS implementation of iPXE is vulnerable to timing attacks when processing TLS records. An attacker could use this flaw to decrypt data, during PXE boot process, transmitted between the PXE server and client.
Clone Of:
Environment:
Last Closed: 2021-10-21 19:53:19 UTC
Embargoed:


Attachments (Terms of Use)

Description Adam Mariš 2018-01-19 13:29:48 UTC
It was found that TLS implementation iPXE is vulnerable to timing attacks when processing TLS records allowing attacker to leak the information whether integrity check failed or succeeded.

In tls_split_block(), the code returns early in case the problems with self-consistency of decrypted message arise, returning different error code in different error cases, allowing attacker to leak information either via timimng channel or based on error codes:

https://git.ipxe.org/ipxe.git/blob/fbe8c52d0d9cdb3d6f5fe8be8edab54618becc1f:/src/net/tls.c#l2220

In tls_new_ciphertext(), attacker can infer the amount of processed data which is supposed to be secret based on the amount of time it takes to process MACs:

https://git.ipxe.org/ipxe.git/blob/fbe8c52d0d9cdb3d6f5fe8be8edab54618becc1f:/src/net/tls.c#l2314

Comment 1 Adam Mariš 2018-01-19 13:29:50 UTC
Acknowledgments:

Name: Hubert Kario (Red Hat)

Comment 3 Hubert Kario 2018-01-19 15:07:13 UTC
same type of vulnerability as CVE-2013-0169 (a.k.a Lucky 13)

Comment 4 Huzaifa S. Sidhpurwala 2018-01-23 06:28:30 UTC
Analysis:

As Hubert mentioned in comment #3, this is essentially a lucky-13 attack against. The attacker on the same network segment, can at the most decrypt blocks of data, (which also depends on the TLS MAC used) which in a pxe setup should not be very useful to the attacker.

Comment 6 Joshua Padman 2018-01-23 08:42:55 UTC
The versions of ipxe in the OpenStack repositories are older than those in RHEL, OpenStack installations should have been consuming these packages from RHEL.

Comment 11 Huzaifa S. Sidhpurwala 2018-02-15 03:50:27 UTC
Created ipxe tracking bugs for this issue:

Affects: fedora-all [bug 1545493]

Comment 12 Cedric Buissart 2018-02-23 19:10:04 UTC
Statement:

This is essentially CVE-2013-0169 affecting ipxe packages. The maximum impact of this flaw is that the attacker on the same network segment, can decrypt TLS data transmitted between the pxe server and the client. In a pxe setup this does has minimal security impact.

This issue affects the versions of ipxe as shipped with Red Hat Satellite version 6 and Red Hat Ceph Storage 1.3. Red Hat Product Security has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Comment 13 Ademar Reis 2019-01-18 21:58:20 UTC
(In reply to Cedric Buissart from comment #12)
> Statement:
> 
> This is essentially CVE-2013-0169 affecting ipxe packages. The maximum
> impact of this flaw is that the attacker on the same network segment, can
> decrypt TLS data transmitted between the pxe server and the client. In a pxe
> setup this does has minimal security impact.
> 
> This issue affects the versions of ipxe as shipped with Red Hat Satellite
> version 6 and Red Hat Ceph Storage 1.3. Red Hat Product Security has rated
> this issue as having Moderate security impact. A future update may address
> this issue. For additional information, refer to the Issue Severity
> Classification: https://access.redhat.com/security/updates/classification/.

Apparently this was never fixed upstream... Is there a patch somewhere, or is the fix obfuscated somehow and I don't see it?

Comment 14 Hubert Kario 2019-01-21 12:53:43 UTC
I am not aware of any patch fixing it.


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