AMI MegaRAC SPx (BMC cryptography / HMAC): A step is missing when the BMC generates its HMAC, so the authentication tag

CVSS 6.3CVE-2023-34471Firmware, BMC & network fabricAMI-SA-2023006Nozomi Labs BMC auditcurated

Impact

A step is missing when the BMC generates its HMAC, so the authentication tag it produces is weaker than intended and can be forged. The result is that an attacker can present traffic the BMC accepts as authentic - loss of authentication as well as confidentiality and integrity. Practically it degrades whatever assurance you thought you had that a management command came from your orchestration system rather than from something else on the wire.

Who can reach it

Adjacent network, requires an existing high-privilege position and user interaction, at high attack complexity. This is a chaining bug rather than a standalone break-in - it matters mostly as the thing that lets an attacker who already has partial management-plane access forge their way further.

What to do

Firmware flash to SPx_12.2 / SPx_13.0 or later; fixed in early SPx branches, so the real work is verifying that the ODM build actually running on each node is from a fixed branch rather than trusting AMI's fix version. No config-only remediation. Compensate by treating the management network as untrusted transit: bastion-only access, mutual TLS with your own CA, and alerting on BMC sessions that do not originate from your management hosts.

References

https://9443417.fs1.hubspotusercontent-na1.net/hubfs/9443417/Security%20Advisories/AMI-SA-2023006.pdf https://nvd.nist.gov/vuln/detail/CVE-2023-34471

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.