
Gaining control of BMC from the host processor - broodbucket
https://www.flamingspork.com/blog/2019/01/23/cve-2019-6260-gaining-control-of-bmc-from-the-host-processor/
======
amboar
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.

~~~
KenoFischer
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.

------
KenoFischer
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.

~~~
amboar
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

------
rurban
Old security overview:
[https://www.schneier.com/blog/archives/2013/01/the_eavesdrop...](https://www.schneier.com/blog/archives/2013/01/the_eavesdroppi.html)

------
amboar
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.

~~~
bluecmd
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.

~~~
amboar
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...)

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

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

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

