Anything that makes privileges escalation exploits more damaging is a real problem. I’m getting tired of how these are being dismissed as if admin access should mean that you can ignore any security issues. There are things that even admin accounts should not be able to change at the hardware level, or if they can they must be reversible in the future by another user with admin access.
> The BMC needs to be ideally on a physically isolated network, or at least a separate one that has no route from the outside nor on the machine itself.
This is good practice but it shouldn’t excuse poor security at the hardware level.
Supermicro motherboards also commonly default to having a feature that bonds the BMC network interface to one of the main NICs if you don’t plug a cable into the BMC interface. It’s common for people to be surprised that their BMC is exposed on their main network because they didn’t plug in a cable on the BMC NIC port at all.
Some of the Supermicro boards don't even have a separate BMC NIC, the only choice is to bond it to one of the main NICs or sacrifice one of them to be BMC only. I try to pay attention to that now after being surprised by that once on some servers we bought.
Yes, all of which can be reversed by another admin in the future. That is expected.
It should not be the case that getting admin access one time can result in modifying the hardware in a way that can’t be reversed by future admin, short of physically reflashing the chip on the board.
If you have admin on windows you can flash the bios on regular motherboards with firmware that refuses to change.
It's really the "permanently" which is the design flaw. Boards should have a mechanism to recover from bad firmware, and the same mechanism is useful to recover from a bad flash.
Make the flash chip removable, or leave a JTAG. Or have a bit of actual ROM with the write lines not even connected and just enough of a firmware to be able to reflash the main one.
The vendors even sell this as downgrade prevention!
If administrator access is equivalent to ownership, then I strongly disagree.
Even if you changed the default from "failover" in the firmware you're just one CMOS reset (for whatever reason) away from it reverting back to putting the BMC on whatever network interface. This should really be something you can jumper off.
Flashing data? Fine.
Permanent? Not so much.
This is exactly the kind of barrier you want for something with so much power over the system, otherwise you're not much better off than where you started as physical access allows for quick swaps of chips.
Meanwhile it provides no meaningful resistance against physical access because someone with physical access can swap the entire board or a dozen other things.
Should every software config require buying new hardware because the initial config gets permanently flashed with an e-fuse to only allow a single write? You could even make a security argument for such a setup, but good luck getting approval for your 15th motherboard this quarter because you typo'd the config.
Also, dban and degaussing is not entirely equivalent -- from a practical perspective the equivalent is hard drive shredding (because the hardware cannot be used again in the old/non-malware config -- dban and degaussing are more like factory default resets). Do some organisations need to do this? Sure. Should we design systems with the assumption that any mistake means that the hardware is destined for the shredder? I would hope not...
It’s not common in modern IT, and the only time I do it myself is in the course of preserving vintage hardware
And if you need to desolder to remove the malicious code, it's pretty reasonable to call it unremovable.
If you are magnetically destroying hard drives as part of decommissioning, that's not really the same thing. You're not using admin access to do it, and you're not making a change that permanently applies to all future use of the device (because there is no future use).
You don't go ahead and erase the same disk once a week. Decommissioning isn't something that occurs for the same project, once a month.
Its not the same operational process.
Is this documented?
If it's documented, it's not an excuse for not reading documentation. You're not supposed to throw stuff (hardware or software) in production without reading the documentation.
You might see that as a facetious comparison. But the number of orgs which actually would desolder the chips in that circumstance is very close to the number which actually would scrap and replace. And if 99% of orgs won't actually do it when needed, then a "works in theory" method of re-securing servers is real-world useless.
What chip are you using to bit bang? Is that chip directly or indirectly controlled by the firmware? Usually it is.
True in the common case, but this can/should be guarded against by disk encryption and secured boot chains.
Anyone can delete a file. Nobody wants to ban deleting files.
More generally, when you get down to the bottom of the pile of elephants, you are requesting some software currently running on your computer to write some bits to some kind of storage medium.
But there is no law of physics that says the software must to do as you ask! If the software is malicious, it can refuse. It could even pretend that it updated the bits but not actually do so.
"Oh, but I booted into $OTHER_PROGRAM and it writes the bits!"
Maybe. But how do you know that the boot loader faithfully loaded it? You don't. Maybe the boot loader is malicious and patches your firmware updater so that it won't actually write new firmware.
If you squint and tilt your head, it kinda looks like Ken Thompson's "Reflections on Trusting Trust".