Hacker News Reader

Comment by alliao | Hacker News Reader

whatever became of it? I thought at the time security experts would swarm and dissect it to death to give us articles after articles of concrete tampering examples... but it just vanished?

View on HN

Security researchers did swarm on it and none of them could corroborate the story. It's been widely discredited in security researcher circles.

This exploit was found after the article was published: https://www.wired.com/story/supermicro-bug-virtual-usb/

That is an unintended vulnerability which can be exploited. While also bad it's not evidence of a malicious hardware installed before leaving the factory.

If it was an attack that one guy was specifically being attacked.

No one has ever found or been shown one of the affected boards.

When it's a plausible attack against an obviously-critical component it seems most prudent to assume the worst and hope to be wrong :)

Okay, assume that your motherboard/BMC is backdoored. What exactly is the sane way to proceed, given that you can't verify it and you have no reason to believe that any alternatives are better?

At home I have my BMCs on a network segment where they can't talk to each other, to the Internet (so no auto-updating), or even to any of my client machines. When I want to use one I connect a patch cable from my laptop to a designated breakglass port on one of my switches.

I do run DHCP/NTP/etc on that subnet, but those services are running in FreeBSD Jails connected to the host OS with vnet(9) "epair" interfaces given RFC3021-style /31 addresses (and/or the IPv6 equivalent) and firewalled with PF on the host-OS side such that none of them have the ability to explore any other parts of my network if they get popped :)

The idea was that it could just compromise your host OS. It doesn't matter that you jail services, since the attack is affecting the hardware underneath the kernel that underlies them; the theoretical attack was more along the lines of "the motherboard watches incoming packets and if it sees a trigger then that packet never makes it to the OS, and if the motherboard wants to send traffic it can either send packets itself (after reading the route table directly out of kernel memory) or modify already-outbound traffic to exfiltrate whatever it wants".

Buy open-source hardware that doesn't have so many compromise points? Assemble some kind of bootstrap verifier out of NAND gates and use that to run your own chip fab?

Reply on news.ycombinator.com