{"id":4440,"date":"2019-01-23T04:17:47","date_gmt":"2019-01-22T18:17:47","guid":{"rendered":"https:\/\/www.flamingspork.com\/blog\/?p=4440"},"modified":"2019-01-23T09:41:35","modified_gmt":"2019-01-22T23:41:35","slug":"cve-2019-6260-gaining-control-of-bmc-from-the-host-processor","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2019\/01\/23\/cve-2019-6260-gaining-control-of-bmc-from-the-host-processor\/","title":{"rendered":"CVE-2019-6260: Gaining control of BMC from the host processor"},"content":{"rendered":"\n

This is details for CVE-2019-6260<\/a> – which has been nicknamed “pantsdown” due to the nature of feeling that we feel that we’ve “caught chunks of the industry with their…” and combined with the fact that naming things is hard, so if you pick a bad name somebody would have to come up with a better one before we publish.<\/p>\n\n\n\n

I expect OpenBMC to have a statement shortly.<\/p>\n\n\n\n

The ASPEED ast2400 and ast2500 Baseboard Management Controller (BMC) hardware and firmware implement Advanced High-performance Bus (AHB) bridges, which allow arbitrary read and write access to the BMC’s physical address space from the host, or from the network if the BMC console uart is attached to a serial concentrator (this is atypical for most systems).<\/p>\n\n\n\n

Common configuration of the ASPEED BMC SoC’s hardware features leaves it open to “remote” unauthenticated compromise from the host and from the BMC console. This stems from AHB bridges on the LPC and PCIe buses, another on the BMC console UART (hardware password protected), and the ability of the X-DMA engine to address all of the BMC’s M-Bus (memory bus).<\/p>\n\n\n\n

This affects multiple BMC firmware stacks, including OpenBMC, AMI’s BMC, and SuperMicro. It is independent of host processor architecture, and has been observed on systems with x86_64 processors IBM POWER processors (there is no reason to suggest that other architectures wouldn’t be affected, these are just the ones we’ve been able to get access to)<\/p>\n\n\n\n

The LPC, PCIe and UART AHB bridges are all explicitly features<\/em> of Aspeed’s designs: They exist to recover the BMC during firmware development or to allow the host to drive the BMC hardware if the BMC has no firmware of its own. See section 1.9 of the AST2500 Software Programming Guide.<\/p>\n\n\n\n

The typical consequence of external, unauthenticated, arbitrary AHB access is that the BMC fails to ensure all three of confidentiality, integrity and availability for its data and services. For instance it is possible to:<\/p>\n\n\n\n

  1. Reflash or dump the firmware of a running BMC from the host<\/li>
  2. Perform arbitrary reads and writes to BMC RAM<\/li>
  3. Configure an in-band BMC console from the host<\/li>
  4. “Brick” the BMC by disabling the CPU clock until the next AC power cycle<\/li><\/ol>\n\n\n\n

    Using 1 we can obviously implant any malicious code we like, with the impact of BMC downtime while the flashing and reboot take place. This may take the form of minor, malicious modifications to the officially provisioned BMC image, as we can extract, modify, then repackage the image to be re-flashed on the BMC. As the BMC potentially has no secure boot facility it is likely difficult to detect such actions.<\/p>\n\n\n\n

    Abusing 3 may require valid login credentials, but combining 1 and 2 we can simply change the locks on the BMC by replacing all instances of the root shadow password hash in RAM with a chosen password hash – one instance of the hash is in the page cache, and from that point forward any login process will authenticate with the chosen password.<\/p>\n\n\n\n

    We obtain the current root password hash by using 1 to dump the current flash content, then using https:\/\/github.com\/ReFirmLabs\/binwalk to extract the rootfs, then simply loop-mount the rootfs to access \/etc\/shadow. At least one BMC stack doesn’t require this, and instead offers “Press enter for console”.<\/p>\n\n\n\n

    IBM has internally developed a proof-of-concept application that we intend to open-source, likely as part of the OpenBMC project, that demonstrates how to use the interfaces and probes for their availability. The intent is that it be added to platform firmware test
    suites as a platform security test case. The application requires root user privilege on the host system for the LPC and PCIe bridges, or normal user privilege on a remote system to exploit the debug UART interface. Access from userspace demonstrates the vulnerability of systems in bare-metal cloud hosting lease arrangements where the BMC
    is likely in a separate security domain to the host.<\/p>\n\n\n\n

    OpenBMC Versions affected: Up to at least 2.6, all supported Aspeed-based platforms<\/p>\n\n\n\n

    It only affects systems using the ASPEED ast2400, ast2500 SoCs. There has not been any investigation into other hardware.<\/p>\n\n\n\n

    The specific issues are listed below, along with some judgement calls on their risk.<\/p>\n\n\n\n

    iLPC2AHB bridge Pt I<\/h1>\n\n\n\n

    State:<\/strong> Enabled at cold start
    Description:<\/strong> A SuperIO device is exposed that provides access to the BMC’s address-space
    Impact: <\/strong>Arbitrary reads and writes to the BMC address-space
    Risk: <\/strong>High – known vulnerability and explicitly used as a feature in some platform designs
    Mitigation:<\/strong> Can be disabled by configuring a bit in the BMC’s LPC controller, however see Pt II.<\/p>\n\n\n\n

    iLPC2AHB bridge Pt II<\/h1>\n\n\n\n

    State:<\/strong> Enabled at cold start
    Description:<\/strong> The bit disabling the iLPC2AHB bridge only removes write access – reads are still possible.
    Impact:<\/strong> Arbitrary reads of the BMC address-space
    Risk: <\/strong>High – we expect the capability and mitigation are not well known, and the mitigation has side-effects
    Mitigation:<\/strong> Disable SuperIO decoding on the LPC bus (0x2E\/0x4E decode). Decoding is controlled via hardware strapping and can be turned off at runtime, however disabling SuperIO decoding also removes the host’s ability to configure SUARTs, System wakeups, GPIOs and the BMC\/Host mailbox<\/p>\n\n\n\n

    PCIe VGA P2A bridge<\/h1>\n\n\n\n

    State: <\/strong>Enabled at cold start
    Description:<\/strong> The VGA graphics device provides a host-controllable window mapping onto the BMC address-space
    Impact:<\/strong> Arbitrary reads and writes to the BMC address-space
    Risk:<\/strong> Medium – the capability is known to some platform integrators and may be disabled in some firmware stacks
    Mitigation:<\/strong> Can be disabled or filter writes to coarse-grained regions of the AHB by configuring bits in the System Control Unit<\/p>\n\n\n\n

    DMA from\/to arbitrary BMC memory via X-DMA<\/h1>\n\n\n\n

    State<\/strong>: Enabled at cold start
    Description:<\/strong> X-DMA available from VGA and BMC PCI devices
    Impact: <\/strong>Misconfiguration can expose the entirety of the BMC’s RAM to the host
    AST2400 Risk:<\/strong> High – SDK u-boot does not constrain X-DMA to VGA reserved memory
    AST2500 Risk:<\/strong> Low – SDK u-boot restricts X-DMA to VGA reserved memory
    Mitigation:<\/strong> X-DMA accesses are configured to remap into VGA reserved memory in u-boot<\/p>\n\n\n\n

    UART-based SoC Debug interface<\/h1>\n\n\n\n

    State:<\/strong> Enabled at cold start
    Description:<\/strong> Pasting a magic password over the configured UART exposes a hardware-provided debug shell. The capability is only exposed on one of UART1 or UART5, and interactions are only possible via the physical IO port (cannot be accessed from the host)
    Impact:<\/strong> Misconfiguration can expose the BMC’s address-space to the network if the BMC console is made available via a serial concentrator.
    Risk:<\/strong> Low
    Mitigation:<\/strong> Can be disabled by configuring a bit in the System Control Unit<\/p>\n\n\n\n

    LPC2AHB bridge<\/h1>\n\n\n\n

    State:<\/strong> Disabled at cold start
    Description:<\/strong> Maps LPC Firmware cycles onto the BMC’s address-space
    Impact:<\/strong> Misconfiguration can expose vulnerable parts of the BMC’s address-space to the host
    Risk:<\/strong> Low – requires reasonable effort to configure and enable.
    Mitigation:<\/strong> Don’t enable the feature if not required.
    Note:<\/strong> As a counter-point, this feature is used legitimately on OpenPOWER systems to expose the boot flash device content to the host<\/p>\n\n\n\n

    PCIe BMC P2A bridge<\/h1>\n\n\n\n

    State: <\/strong>Disabled at cold start
    Description:<\/strong> PCI-to-BMC address-space bridge allowing memory and IO accesses
    Impact:<\/strong> Enabling the device provides limited access to BMC address-space
    Risk:<\/strong> Low – requires some effort to enable, constrained to specific parts of the BMC address space
    Mitigation:<\/strong> Don’t enable the feature if not required.<\/p>\n\n\n\n

    Watchdog setup<\/h1>\n\n\n\n

    State:<\/strong> Required system function, always available
    Description:<\/strong> Misconfiguring the watchdog to use “System Reset” mode for BMC reboot will re-open all the “enabled at cold start” backdoors until the firmware reconfigures the hardware otherwise. Rebooting the BMC is generally possible from the host via IPMI “mc reset” command, and this may provide a window of opportunity for BMC compromise.
    Impact:<\/strong> May allow arbitrary access to BMC address space via any of the above mechanisms
    Risk:<\/strong> Low – “System Reset” mode is unlikely to be used for reboot due to obvious side-effects
    Mitigation:<\/strong> Ensure BMC reboots always use “SOC Reset” mode<\/p>\n\n\n\n

    The CVSS score for these vulnerabilities is: https:\/\/nvd.nist.gov\/vuln-metrics\/cvss\/v3-calculator?vector=3DAV:A\/AC:L\/PR:=N\/UI:N\/S:U\/C:H\/I:H\/A:H\/E:F\/RL:U\/RC:C\/CR:H\/IR:H\/AR:M\/MAV:L\/MAC:L\/MPR:N\/MUI:N=\/MS:U\/MC:H\/MI:H\/MA:H<\/a><\/p>\n\n\n\n

    There is some debate on if this is a local or remote vulnerability, and it depends on if you consider the connection between the BMC and the host processor as a network or not.<\/p>\n\n\n\n

    The fix is platform dependent as it can involve patching both the BMC firmware and the host firmware.<\/p>\n\n\n\n

    For example, we have mitigated these vulnerabilities for OpenPOWER systems, both on the host and BMC side. OpenBMC has a u-boot patch that disables the features:<\/p>\n\n\n\n

    https:\/\/gerrit.openbmc-project.xyz\/#\/c\/openbmc\/meta-phosphor\/+\/13290\/<\/a><\/p>\n\n\n\n

    Which platforms can opt into in the following way:<\/p>\n\n\n\n

    https:\/\/gerrit.openbmc-project.xyz\/#\/c\/openbmc\/meta-ibm\/+\/17146\/<\/a><\/p>\n\n\n\n

    The process is opt-in for OpenBMC platforms because platform maintainers have the knowledge of if their platform uses affected hardware features. This is important when disabling the iLPC2AHB bridge as it can be a bit of a finicky process.<\/p>\n\n\n\n

    See also https:\/\/gerrit.openbmc-project.xyz\/c\/openbmc\/docs\/+\/11164<\/a> for a WIP OpenBMC Security Architecture document which should eventually contain all these details.<\/p>\n\n\n\n

    For OpenPOWER systems, the host firmware patches are contained in op-build v2.0.11 and enabled for certain platforms. Again, this is not by default for all platforms as there is BMC work required as well as per-platform changes.<\/p>\n\n\n\n

    Credit for finding these problems: Andrew Jeffery, Benjamin
    Herrenschmidt, Jeremy Kerr, Russell Currey, Stewart Smith. There have been many more people who have helped with this issue, and they too deserve thanks.<\/p>\n","protected":false},"excerpt":{"rendered":"

    This is details for CVE-2019-6260 – which has been nicknamed “pantsdown” due to the nature of feeling that we feel that we’ve “caught chunks of the industry with their…” and combined with the fact that naming things is hard, so … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1],"tags":[],"class_list":["post-4440","post","type-post","status-publish","format-standard","hentry","category-general"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5a6n8-19C","jetpack-related-posts":[{"id":4508,"url":"https:\/\/www.flamingspork.com\/blog\/2019\/12\/10\/looking-at-the-state-of-blackbird-firmware\/","url_meta":{"origin":4440,"position":0},"title":"Looking at the state of Blackbird firmware","author":"Stewart Smith","date":"2019-12-10","format":false,"excerpt":"Having been somewhat involved in OpenPOWER firmware, I have a bunch of experience and opinions on maintaining firmware trees for products, what working with upstream looks like and all that. So, with my new Blackbird system I decided to take a bit of a look as to what the firmware\u2026","rel":"","context":"In "code"","block_context":{"text":"code","link":"https:\/\/www.flamingspork.com\/blog\/category\/code\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4419,"url":"https:\/\/www.flamingspork.com\/blog\/2018\/11\/19\/tracing-flash-reads-and-writes-during-boot\/","url_meta":{"origin":4440,"position":1},"title":"Tracing flash reads (and writes) during boot","author":"Stewart Smith","date":"2018-11-19","format":false,"excerpt":"On OpenPOWER POWER9 systems, we typically talk to the flash chips that hold firmware for the host (i.e. the POWER9) processor through a daemon running on the BMC (aka service processor) rather than directly. We have host firmware map \"windows\" on the LPC bus to parts of the flash chip.\u2026","rel":"","context":"In "code"","block_context":{"text":"code","link":"https:\/\/www.flamingspork.com\/blog\/category\/code\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.flamingspork.com\/blog\/wp-content\/uploads\/2018\/11\/4096bytewindowtrace.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.flamingspork.com\/blog\/wp-content\/uploads\/2018\/11\/4096bytewindowtrace.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.flamingspork.com\/blog\/wp-content\/uploads\/2018\/11\/4096bytewindowtrace.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/www.flamingspork.com\/blog\/wp-content\/uploads\/2018\/11\/4096bytewindowtrace.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":4515,"url":"https:\/\/www.flamingspork.com\/blog\/2019\/12\/13\/upstreaming-blackbird-firmware-step-1-skiboot\/","url_meta":{"origin":4440,"position":2},"title":"Upstreaming Blackbird firmware (step 1: skiboot)","author":"Stewart Smith","date":"2019-12-13","format":false,"excerpt":"Now that I can actually boot the machine, I could test and send my patch upstream for Blackbird support in skiboot. One thing I noticed with the current firmware from Raptor is that the PCIe slot names were wrong. While a pretty minor point, it's a bit funny that there's\u2026","rel":"","context":"In "cool gadgets"","block_context":{"text":"cool gadgets","link":"https:\/\/www.flamingspork.com\/blog\/category\/cool-gadgets\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4207,"url":"https:\/\/www.flamingspork.com\/blog\/2016\/10\/31\/fast-reset-trusted-boot-and-the-security-of-sbinreboot\/","url_meta":{"origin":4440,"position":3},"title":"Fast Reset, Trusted Boot and the security of \/sbin\/reboot","author":"Stewart Smith","date":"2016-10-31","format":false,"excerpt":"In OpenPOWER land, we've been doing some work on Secure and Trusted Boot while at the same time doing some work on what we call fast-reset (or fast-reboot, depending on exactly what mood someone was in at any particular time.... we should start being a bit more consistent). The basic\u2026","rel":"","context":"In "General"","block_context":{"text":"General","link":"https:\/\/www.flamingspork.com\/blog\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4526,"url":"https:\/\/www.flamingspork.com\/blog\/2019\/12\/15\/are-you-fans-of-the-blackbird-speak-up-i-cant-hear-you-over-the-fan\/","url_meta":{"origin":4440,"position":4},"title":"Are you Fans of the Blackbird? Speak up, I can’t hear you over the fan.","author":"Stewart Smith","date":"2019-12-15","format":false,"excerpt":"So, as of yesterday, I started running a pretty-close-to-upstream op-build host firmware stack on my Blackbird. Notable yak-shaving has included: Update README.md for Fedora 31 build-deps because READMEs are importantSupport Python3 as default \/usr\/bin\/python (so I could compile it at all on Fedora 31)RaptorCS Blackbird support the actual minimal firmware\u2026","rel":"","context":"In "cool gadgets"","block_context":{"text":"cool gadgets","link":"https:\/\/www.flamingspork.com\/blog\/category\/cool-gadgets\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":4561,"url":"https:\/\/www.flamingspork.com\/blog\/2020\/03\/08\/yet-another-near-upstream-raptor-blackbird-firmware-build\/","url_meta":{"origin":4440,"position":5},"title":"Yet another near-upstream Raptor Blackbird firmware build","author":"Stewart Smith","date":"2020-03-08","format":false,"excerpt":"In what is coming a month occurance, I've put up yet another firmware build for the Raptor Blackbird with close-to-upstream firmware (see here and here for previous ones). Well, I\u00e2\u20ac\u2122ve done another build! It\u00e2\u20ac\u2122s current op-build (as of yesterday), but my branch with patches for the Raptor Blackbird. The skiboot\u2026","rel":"","context":"In "General"","block_context":{"text":"General","link":"https:\/\/www.flamingspork.com\/blog\/category\/general\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts\/4440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/comments?post=4440"}],"version-history":[{"count":3,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts\/4440\/revisions"}],"predecessor-version":[{"id":4443,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/posts\/4440\/revisions\/4443"}],"wp:attachment":[{"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/media?parent=4440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/categories?post=4440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.flamingspork.com\/blog\/wp-json\/wp\/v2\/tags?post=4440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}