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.
- Anatomy of a Security Flaw Announcement: The Strange Timeline of Spectre and Meltdown
- Bug Bounties Aren’t Just for Software
- Breaking the System to Fix It: The “Hackers” That Hunt for Security Vulnerabilities