Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel SPI Flash Flaw Lets Attackers Alter or Delete BIOS/UEFI Firmware (bleepingcomputer.com)

Posted by msmash on from the fixed,-next dept.

Catalin Cimpanu, writing for BleepingComputer: Intel has addressed a vulnerability in the configuration of several CPU series that allow an attacker to alter the behavior of the chip's SPI Flash memory -- a mandatory component used during the boot-up process [1, 2, 3]. According to Lenovo, who recently deployed the Intel fixes, "the configuration of the system firmware device (SPI flash) could allow an attacker to block BIOS/UEFI updates, or to selectively erase or corrupt portions of the firmware." Lenovo engineers say "this would most likely result in a visible malfunction, but could in rare circumstances result in arbitrary code execution."

4 of 46 comments (clear)

  1. Re:Headline is misleading by Anonymous Coward · · Score: 2, Informative

    It doesn't affect BIOS, just UEFI.

    It affects the SPI flash which could be used against either BIOS or UEFI

  2. Applied the Fix by DaMattster · · Score: 3, Informative

    It is always hairy when you apply a firmware fix but I am pleased to say that Lenovo's update for the ThinkCentre M70 works just fine. Although, it took a while to apply and power cycled 3 times. At one point I almost said, "Fuck! It bricked."

  3. They can't. by Anonymous Coward · · Score: 3, Informative

    They literally (intentionally?) broke the SPI write-lock switch back in the 8 MBit days and instead made it 'write-lock *ONLY IF* hardware sense pin+post-power on software enable are both set.' What does that mean in layman's terms? Glitching power can cause the SPI flash to believe it has been power cycled. Since the write protect requires software intervention to enable and since said write protect function is only normally run at boot time, said glitching can unlock the bios write protect post-boot, allowing arbitrary reflashing after boot. Intel's kludge to fix this was adding write protection into the southbridge/firmware controller hub that blocks read/write access to memory ranges after boot without a properly signed image, only not all their hardware does it properly and there are other ways to get around it (external reflashing on some boards before they started requiring all the signed blobs for everything.) Now, rather than a simple 1 pin to write disable the whole chip, you have 2-3 different possible ways your bios memory range is write protected, none of which may keep hackers or governments from injecting unwanted changes into your SPI flash/bios images for purposes most of us would rather not thing about.

    The only solutions to this problem are new hardware or 'shim hardware' that sits between the spi flash chip and the motherboard and relays commands between them, filtering write and erase calls for the specific SPI chip in the system (since for some stupid reason this stuff isn't fully standardized and while most chips can be read with generic commands, write and erase is sometimes non-standard even among the same product designation, but different generations/iterations of part!) Truly a step back from the parallel/lpc flash days.

  4. Found out the hard way by Ubuntu last year by zdzichu · · Score: 3, Informative

    The problem was uncovered by Ubuntu last year: https://linux.slashdot.org/sto...
    It was so grave they had to pull down released version and patch the workaround.

    --
    :wq