Gaining control of BMC from the host processor | Hacker News Reader

Gaining control of BMC from the host processor

flamingspork.com

52 pointsbroodbucket11 comments

The description looks bad on the surface, but as always reality is more nuanced. These issues are only problematic in specific circumstances, particularly, bare-metal cloud hosting where the BMC might be in a separate trust domain to the host and the user on the host is provided with root (or equivalent) privileges. If your threat model is "root on the host owns the platform" then the only problem is that the BMC is yet another spot to hide malware.

The concern is that existing BMC firmwares have been shown as unsafe for bare-metal cloud types of configurations by default, so organisations using platforms in this environment may be doing so with false confidence.

FWIW, in my experience there's lots of middle ground between the host being completely untrusted and the user having root on both the host and the BMC. Anywhere from "we're letting random third party collaborators share our machines" to "it's only in-house users, but they may not properly secure their machines" is a use case where regular users even with root on the host would not have root on the BMC.

It's for reasons like this that I'm very thankful that the OpenBMC effort is getting off the ground. The prior lack of documentation and understanding of what the communication channels, and how they're configured is a huge problem. Perhaps it's time to get the SPI programmer out again and see if I can't finish replacing the BMC firmware on a bunch of my boards.

Please upstream your changes! I remember you were playing around with getting OpenBMC running on a Supermicro X11, would be good to expand the x86-64 support

Old security overview: https://www.schneier.com/blog/archives/2013/01/the_eavesdrop...

Something important to note is that this is largely a BMC firmware problem - the hardware can be securely configured to maintain CIA against the host, just sometimes it is not.

A lot of these debug features are re-enabled on SoC reset so there are quite interesting attacks you can do there just given access to reboot the SoC. Attack before the OS has been loaded and has had time to disable the features and you win.

These are silicon issues as far as I know.

Right; then it comes down to platform design and whether you can reboot the soc in a mode that both reopens the bridges and doesn't kill the host, though that's not relevant if you're accessing it from the UART debug interface.

FWIW the mitigation patch in OpenBMC turns off all the bridges early in u-boot to minimise the race window for system reset/AC cycles.

Obviously would be better if it was possible to avoid the race window entirely (i.e. bridges default to closed, can be strapped open by the platform designer, and opened as required by firmware). We had asked for hardware changes along these lines for future generations (but may need to push a little harder...)

I thought "reflash the BMC firmware from the host" was a feature? A hard to use, poorly documented feature, granted.

Depends on your threat model and if you expect root on the host to also have root on the BMC.

Right. The experience so far is that most people find the capability surprising.

Reply on news.ycombinator.com