Cisco NX OS: Bootloader Script Execution Vulnerability

### Summary During boot, the bootloader (cisco-grub) will enumerate all potential boot drives and probe for a menu.lst script file. If an adversary manages to place such a file on the system’s SSD or on an external USB drive, the bootloader will trust that file and execute all commands in it. This can be used to gain arbitrary code execution in the bootloader and/or bypass image signature verification checks that the bootloader would normally perform before executing an NX OS image. For example, the “displaymem” command allows exposing a small part of grub’s heap layout:  We can confirm that the memory layout never changes across reboots, which indicates the absence of exploit mitigations such as ASLR. This is unfortunately still common in such bootloaders and UEFI firmware. Combined with the “memrw” command, it is possible to read and write arbitrary memory:  The previous screenshots show that the commands were executed by simply entering them through the serial console. ### Severity High - A successful exploit could allow the attacker to elevate privileges to root. The vulnerable code can be triggered both via physical access and remotely, by modifying the device's file system. ### Proof of Concept To demonstrate that this also works without any user interaction, we created a simple menu.lst configuration file and placed it on a USB drive. As long as the USB drive is formatted using one of the file systems that grub supports (ext2, FAT32), it will try and open the script from /boot/grub/menu.lst.local and if it exists, it executes all commands in it, as shown in the following screenshots: For example, the “displaymem” command allows exposing a small part of grub’s heap layout:   Serial Console Log, showing how grub executes commands from our malicious menu.lst.local file without user interaction. This leads to arbitrary code execution since adversaries can use this and overwrite sections of grub itself, inject their own code or simply patch the signature verification in grub, which would allow booting any compromised version of NX OS. A secure erase operation removes the menu.lst file only if the system is not compromised already. If the attack is carried out carefully, attackers may try to bypass secure erase procedures. ### Further Analysis We believe that the identified vulnerability has a “Critical” severity since once the script has been placed, compromise happens without user interaction and all availability, integrity or confidentiality that the device would provide is permanently lost or controlled by the attacker. Attackers can use this vulnerability to bypass image verification and load arbitrary NX OS images, which can contain and execute any attacker-controlled code. Detecting this compromise from within a compromised NX OS image can be challenging since the attacker can mask their presence and there is no hardware root of trust that could provide cryptographically verifiable, tamper-resident evidence on which firmware was executed and how it was configured. Devices generally permit downgrades and out of the box, NX OS provides features that allow placing the payload, which paves the way for remote attacks that only require valid credentials and no further vulnerabilities. To exploit this vulnerability, attackers only need to be able to modify the contents of the boot flash or those of any attached USB storage device. There are several ways to achieve this and each system might require a different, but similar approach: - Use physical access to program the device’s boot SSD - U

Severity from

GitHub (reviewed advisory)

• github.com/google/security-research/security/advisories/GHSA-42j5-mmpp-3vwg
• github.com/google/security-research