Security Flaw Found in Xilinx Zinc UltraScale+ Encrypt Only Secure Boot
Security flaws can leave products vulnerable and give engineers sleepless nights. Recently, a new security flaw was found in Xilinx's Zynq UltraScale+ SoC devices' encrypt only secure boot.
Security flaws can leave products vulnerable and give engineers sleepless nights. Recently, a new security flaw was found in Xilinx Zynq UltraScale+ SoC devices' encrypt only secure boot.
Xilinx recently announced that their popular product line, the Xilinx Zynq UltraScale+ SoC, has a two-part hardware security flaw, one part of which cannot be fixed. The problem lies in a secure boot mode called “Encrypt Only” which is an alternative boot method to the “Hardware Root Of Trust”.
Figure 1. Xilinx Zinc UltraScale+ MPSoC. Image courtesy of Xilinx.
Patching Security Issues
When designing products security is often a critical component as the product or device in question may hold potentially sensitive information.
Sensitive information traditionally includes usernames, passwords, and credit card information. Now with electronics expanding into everyday life, the scope of sensitive information is expanding into issues like webcam access that can allow attackers to spy on individuals to help them understand when properties are empty and even track targets. Also, microphones can provide attackers with a wealth of information from private conversations.
In many cases, security issues are of the software kind which can be fixed with a simple update or patch. For example, the Heartbleed vulnerability which affected OpenSSL allowed for attackers to retrieve large lengths of potentially private data from a server as the encryption method did not check for requested data lengths against the responding text. In other words, an attacker could ask a server to respond with the word “hello” but state that its size was 500 letters. This would result in the server responding with 500 bytes of content from its memory, which could have been potentially used to store passwords and other sensitive data.
Unfortunately, not all problems are related to software. In these situations, fixing the problem can be next to impossible.
The Xilinx ZU+ Security Flaw
When a device is configured in the “Encrypt Only” mode it starts by executing the first-stage boot loader (FSBL). This boot loader requires a parameter that points to the execution address but the parameter itself is not authenticated. Since the parameter is not authenticated an attacker can tamper with the execution address location and have the device execute at arbitrary addresses.
The second flaw that arises is that because the partition headers are not authenticated an attacker can manipulate the header so that it points to itself. Since the partition header is stored off-chip an attacker can inject valid instructions in the partition header so that arbitrary code execution can be done.
Adam Pilkey of F-Secure explained, "Attackers that are able to tamper with the boot header in the early stages of the boot procedure can modify its contents to execute arbitrary code, thereby bypassing the security measures offered by the 'encrypt only' mode."
While flaws can often be patched, this one cannot due to the nature of the flaw. The core of the problem lies in the silicon itself and the area of silicon in particular that has the issue is the ROM. Anyone who is aware of how memory works understands that ROM memory stands for Read Only Memory, which means that changing the contents of this is impossible. The only fix to this security bug is with a new silicon device with ROM that has been updated.
Folks, please read the actual paper on https://github.com/inversepath/advisories/blob/master/Security_Advisory-Ref_FSC-HWSEC-VR2019-0001-Xilinx_ZU+-Encrypt_Only_Secure_Boot_bypass.txt . This should *NOT* be reported as a security flaw. Encrypt-only boot mode is not intended to prevent code execution if you have physical access. It’s only usable for confidentiality. This would be a flaw if you recovered the encrypted contents or the key. Xilinx has always stated that HWROT (encrypt and RSA signed) is needed to secure against arbitrary code injection.
I hate this kind of irresponsible, sensationalist, CVE reporting by so-called cyber experts that seems to be tuned more grab headlines, than real security. It’s a bit like saying a popular electronic door lock is insecure because it doesn’t protect you from thieves using the window instead. This is completely fake news, and barely a bug let alone a vulnerability.