Almost unfixable “Sinkclose” bug affects hundreds of millions of AMD chips
Summary: The DEFCON conference was this past week and one of the presentations was on a bug found in AMD microchips that allows firmware level execution
Analysis:
Most of the scary malware known to the world operates in what is considered to be user-space on a machine. A malicious binary file is executed and the program runs in memory; typically restarting the machine would cause this malware to go away, but sometimes attackers may even leave the malicious binary on disk on the target machine and have a method for causing it to be executed upon restart, which is how they persist on the machine. User-space level malware can only do things that a user (regular or administrator) can do, like powershell (windows) or bash commands (unix).
More severe vulnerabilities exist which allow the malware to actually operate at the kernel-level, which is beyond what any individual interacting with the machine has access to. Kernel-level malware can directly access and influence things like I/O, memory, requests from user-space software to acquire and utilize resources, network sockets, and the specific tasking of the CPU. Kernel-space malware is hard to detect as it executes its commands at a layer that is effectively invisible to the end-user on the machine, and can even further disguise what traces may exist. Kernel-space malware is the ultimate spooky as it tends to be considered unfettered, undetectable access to a machine.
BUT THIS BUG IS THE BUG OF ALL BUGS. This bug exists in the firmware of the processor itself. This bug allows an attacker to have access to a machine that is not just unfettered and undetectable, it is unremovable. The firmware is the lowest layer of software that literally interacts with the physical hardware of the machine. And we’re not just talking about the firmware of a random piece of hardware like the screen or the keyboard, we’re talking about the processor itself.
The interesting piece (for us) of this article is when one of the two individuals who discovered this bug summarized its gravity (hah):
“Nissim sums up that worst-case scenario in more practical terms: “You basically have to throw your computer away.”
That’s enough to make sys admin’s skin crawl. Who wants to have to replace a whole server running in prod? What a nightmare that must be, right? But of course, in this class we’re not just focused on 2U servers sitting in a network closet at HQ – we’re focused on hardware that sits on satellites hurling at insane speeds far above the earth. If an adversary could gain firmware level access to the processors present on satellites, they could completely shut down services. Throwing away a firewall and replacing it might take a purchase order and a few hundred dollars of rush delivery. Throwing away a satellite means years, decades even, to get that service back online. For small cube-sat, scientific expeditions, that could be problematic, but what if the adversary targeted something more specific. No satcom, no GPS, no imagery for years or decades would have second and third-order effects that would certainly extend into billions of dollars of damage and or lost productivity, not to mention the incredible loss of life that could occur.
This whole concept further highlights one of the unique aspects of cybersecurity in that there is nothing that can be done to prevent an attack like this, should the bug exist. You can harden and defend vectors to gain access to a vulnerable machine, no amount of preparation or hardening can protect against something that exists at such a low level on a piece of hardware provided by an oligopoly market.