Database/Firmware, BMC & network fabric

IBM BladeCenter AMM (before 3.66E), IMM (before 1.43), IMM2: The in-band host-to-BMC pivot, with a CVE attached. The
Impact
The in-band host-to-BMC pivot, with a CVE attached. The management firmware stores IPMI credentials in cleartext and exposes them over two channels a tenant may already stand on - the chassis internal network, and the Ethernet-over-USB link that the host operating system sees as an ordinary network interface. A tenant who reaches root on the host OS of one blade reads those credentials off the in-band interface and then issues IPMI commands and opens remote-control sessions against blades belonging to other tenants. That is the whole out-of-band trust model inverted: the management plane was supposed to be the thing the host could not reach, and here the host reads its way in. Same primitive class as KCS host-to-BMC bridging, which has no CVE of its own because it is documented behaviour rather than a bug.
Who can reach it
Local root on the host OS of an affected blade (via the Ethernet-over-USB interface), or a position on the chassis internal network. Escalates from one tenant's node to chassis-wide control.
What to do
Flash AMM to 3.66E+, IMM to 1.43+, IMM2 to 4.15+. Beyond the flash, the lasting control is to sever the in-band path: disable the Ethernet-over-USB / LAN-over-USB interface on hosts that do not need in-band management, and where in-band agents are required, treat the host-to-BMC channel as an untrusted boundary that needs its own authentication rather than an implicitly trusted sidechannel. Operators should assume any tenant with host root can talk to the BMC unless that interface has been explicitly turned off, and audit for it - it is enabled by default on a lot of hardware.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.