Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
140 lines (99 sloc) 5.91 KB
Security advisory: Xilinx ZU+ Encrypt Only Secure Boot bypass
=============================================================
The Xilinx Zynq UltraScale+ (ZU+) family of System-on-Chip (SoC) devices
supports a secure boot mode referred to as "encrypt only".
The encrypt only mode is an alternative to the "hardware root of trust" one,
allowing secure boot without asymmetric authentication but which instead,
quoting the ZU+ reference manual ([1] p279), "requires that all configuration
loaded must be encrypted and authenticated using AES-GCM".
Two design flaws have been identified that allow to execute arbitrary code,
resulting in loss of authentication and confidentiality, leveraging on the lack
of authentication for boot metadata, by means of boot image tampering.
The flaws spawn from the lack of authentication for execution addresses
specified in headers loaded early in the boot stage.
Such headers are not encrypted and, lacking authentication, allow an external
attacker to control, with some restrictions, loaded code execution addresses.
The first design flaw is present in the boot header parsing, performed by the
ZU+ internal boot ROM. Given that the internal boot ROM cannot be updated, only
a new silicon revision by Xilinx, with an adequately patched boot ROM, can
address the first vulnerability.
The second flaw is present in the partition header table parsing, performed by
the first-stage boot loader (FSBL). The second vulnerability can be addressed
by software means, implementing authentication of the partition header, its
resolution however cannot result in a safe use of the encrypt only mode as long
as the first vulnerability remains unresolved.
Loss of authentication allows the adversary sufficient control of the system
such that loss of confidentiality can occur as well.
It is highly recommended, for implementers of any secure boot or trust scheme
which involves encryption, using ZU+ P/Ns, to only use the "hardware root of
trust" mode.
Xilinx ZU+ lack of authentication for boot header in encrypt only secure boot
-----------------------------------------------------------------------------
The first-stage boot loader (FSBL) execution address is a parameter included in
the boot header, the first section of the boot image loaded by the ZU+ internal
boot ROM.
By design, the boot header is not authenticated under the "encrypt only" secure
boot mode, this opens up the possibility of malicious tampering of the FSBL
execution address, in a manner that allows arbitrary code execution.
Such tampering can occur when a malicious party has the opportunity of
modifying the boot header contents, for example by means of local boot device
(e.g. SD) tampering.
As a constraint to exploitation, the FSBL execution address must point to the
On-chip memory (OCM) region. This means that the execution address cannot be
directly pointed at arbitrarily controlled plaintext code stored in external
memories (e.g. QSPI).
This aspect does not prevent the possibility to exploit the issues, but merely
increases the difficulty required. A feasible scenario would be identifying a
ROP “gadget” or jump, within the FSBL payload, which would allow to bypass the
“encryption only” strategy enforcement.
Xilinx ZU+ lack of authentication for partition headers in encrypt only secure boot
-----------------------------------------------------------------------------------
The destination execution address for boot partitions is a parameter included
in partition headers, sections of the boot image loaded by first-stage boot
loader (FSBL).
By design, the partition headers are not authenticated under the "encrypt only"
secure boot mode, this opens up the possibility of malicious tampering of the
destination execution address, in a manner that allows arbitrary code
execution.
Such tampering can occur when a malicious party has the opportunity of
modifying the boot header contents, for example by means of local boot device
(e.g. SD) tampering.
The exploitation of the destination execution address lack of authentication
does not pose challenges as it can be manipulated to point at the partition
header itself, which can be modified to include valid instructions and
therefore achieving arbitrary code execution.
Affected versions
-----------------
All Xilinx Zynq UltraScale+ P/Ns are believed to be vulnerable, tests have been
performed against an Xilinx Zynq UltraScale+ MPSoC ZCU104 Evaluation Kit.
Given that the internal boot ROM cannot be updated, only a new silicon revision
by Xilinx, with an adequately patched boot ROM, can address the boot header
lack of authentication.
The partition header lack of authentication can be theoretically addressed with
an FSBL patch, though none is available at this time.
Credit
------
Vulnerabilities discovered and reported by the Inverse Path team at F-Secure,
in collaboration with Robert Bosch GmbH.
CVE
---
CVE-2019-5478: Xilinx ZU+ lack of authentication for boot header in encrypt only secure boot
CVE-2019-5478: Xilinx ZU+ lack of authentication for partition headers in encrypt only secure boot
Timeline
--------
2019-06-21: findings identified during a security audit by Inverse Path team at
F-Secure in collaboration with Robert Bosch GmbH.
2019-06-25: findings shared with Bosch PSIRT.
2019-06-28: findings shared with Xilinx PSIRT.
2019-07-05: Xilinx PSIRT confirms the findings.
2019-07-15: Xilinx PSIRT agrees to public disclosure process, consisting of a
Security Design Advisory and updates to the Technical Reference Manual.
2019-08-12: Xilinx Design Advisory [2] and F-Secure advisory [3] release.
2019-09-03: Xilinx communicates assigned CVE.
References
----------
[1] https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
[2] https://www.xilinx.com/support/answers/72588.html
Permalink
---------
[3] https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt
You can’t perform that action at this time.