Phoenix SecureCore Technology 4 (SMI handler, improper access control): An SMI handler with missing access control lets

Impact

An SMI handler with missing access control lets an attacker modify the SPI flash. That is the direct route to a permanent firmware implant: rewrite the boot flash and the compromise survives OS reinstall, disk replacement and node reimaging between tenants, while sitting below Secure Boot and below anything attestation can honestly measure. Highest-scored Phoenix advisory in this set.

Who can reach it

Local attacker on the host with the ability to invoke the SMI handler - in practice admin/root, or a tenant with kernel access on bare metal.

What to do

OEM BIOS update on the fixed SecureCore Technology 4 build (affected from 4.3.0.0). Firmware flash, one reboot per node. No config workaround for the handler itself, but this is the case where platform SPI protections earn their keep: confirm BIOS Lock Enable, SMM BIOS Write Protect and protected range registers are actually set on your platform - many OEM defaults leave at least one of them off, and a properly locked flash blunts the primitive even on unpatched firmware.

References