Hacker News Reader

Comment by dmos62 | Hacker News Reader

I'm hopeful that open processors like RISC will be a big step in solving this. But, then there will still be all that other blob-y, closed hardware like SSDs, network cards, radios. In my humble opinion, there's something wrong with everyone having to use hardware (and software to a slightly lesser extent) that's not auditable and not patchable (by you). There should be a legislative framework for consumer protection.

View on HN

There will never be such a legislation as long NSA, FBI, CIA, <insert any intelligence agency here> have an interest for a back-door which they will ever have.

A computer in malicious hands is a weapon as much as movable types and the photo-copier are/were.

I wasn't aware of this "Ministry of Freedom" before today (despite knowing about Libreboot). But "Ministry of Freedom" works because these older laptops have been reverse engineered to the point where we can be confident in how their firmware works... and replace it with something open-source.

There are companies who continue to strive to build open-source hardware: such as the Talos II workstation, the System76 laptops, and Pinephone.

Of these: the Talos II stuff with POWER9 CPUs seems the "most open source" out of all solutions. Its a bit of a subjective measure for sure. However, Talos II is rather expensive.

I think these older Thinkpad Txxx laptops with libreboot definitely work as a more entry-level introduction to fully free software from the boot-process up. Its clearly a cheaper methodology than Talos II (or System76). So that's probably a good thing that they serve different market niches.

> other blob-y, closed hardware like SSDs, network cards, radios.

Actually the ryf certification allows this kind of firmware if they are written in ROM; in such cases, they are considered part of the hardware. I understand the complaints about this stance but I know no other similar certification and I think that having non-replaceable firmware forces the vendors to include the minimum of logic inside it and be more careful, so I'm not entirely against it.

Ideally the source code of the firmware should be available. I try to vote with my wallet for that and encourage people to do the same.

> Actually the ryf certification allows this kind of firmware if they are written in ROM

I never really understood this logic... it's still closed-source software, it just happens to be unmodifable?

and the CPU is also closed-source software, just "compiled" into gates (synthesised)

In this read-only case the manufacturer no longer has write access, just like you don't have write access, so there is more equality between you and the manufacturer. Thats the logic, but I agree it is a bad idea because it incentivises placing firmware into ROM, which cannot be replaced after reverse engineering it.

I’ve never seen a big problem with things like SSDs or sensors and likewise parts having their own blobs. Sure, it’d be nice if you can poke around in them, but they don’t have DMA and they have no way to communicate with the outside world.

It’s as if you put a untrustworthy guy on a really far away island and occasionally go to him and ask him what the temperature is. He has no way to observe what is happening on the mainland, and even if he did he has no way to talk to anyone about it.

Could a rogue SSD move things around in your filesystem? If so, couldn't it install a rootkit?

Either way, it's not just about backdoors. A blob is like a car that you cannot perform maintenance on. You want to be able to fix bugs, and also inspect it to check if there aren't any. Maybe customize it.

Hmm, I’m not sure I agree. Malicious firmware blobs in your disk controller could do all sorts of damage, like silently replacing parts of executable files with whatever they like. Someone made a proof of concept of this a few years ago - where they managed to replace some of the controller firmware in a hard disk. Their modified drive would then silently replace a certain executable with something else. And on that drive, the attack was persistent.

And are modern NVMe drives isolated? Is your system secure if you have a malicious PCIe device attached? (Even if disk controllers are isolated, are graphics cards? Couldn’t my NVMe drive just claim to be a GPU and DMA all it likes?)

Full-disk- or file-system-level encryption on everything reduces the impact by a lot.

How is the full-disk encryption implemented? Not by the disk, I hope.

In OpenBSD, for example, in software.

Naturally. LUKS or ZFS native encryption, for example.

This is pretty nifty, but I have to imagine that it is also detectable if you look for it. The drive can't differentiate between being read for execution and being read for analysis. So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change.

Such a program could be injected into the firmware of the machine, so it will never be read from disk, and it is unlikely need updating. One could also produce a second, clean room, program which does the same thing. This could serve as a back up in case a buffer overflow or similar exploit is found and leveraged in the first validation program.

Additionally, without the ability to self-update its signature database, version updates would render this hack ineffective.

> So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change.

The drive could do things like serve up a malicious version of a system DLL on boot (within the first 20 seconds of being powered on). Then deliver unmodified copies of the file on subsequent read requests. An attack like that would be difficult to detect even if you plugged the drive into another computer.

And as for self updating, the payload could make internet requests, and fetch updated versions of itself online. The controller could then look out for any write which contains a well known sequence of (seemingly random) bytes. And then flash itself with subsequent bytes written to disk. The system component just needs to write the update to a temporary file, flush to disk, then immediately deletes it again afterwards.

I agree with some other sibling posters that the best protection against this is probably full disk encryption. Is that enabled by default yet on windows or macos?

> And are modern NVMe drives isolated? Is your system secure if you have a malicious PCIe device attached?

Only if it's sitting behind an IOMMU. This is rarely the case; although it is starting to improve.

> Hmm, I’m not sure I agree. Malicious firmware blobs in your disk controller could do all sorts of damage, like silently replacing parts of executable files with whatever they like. Someone made a proof of concept of this a few years ago - where they managed to replace some of the controller firmware in a hard disk. Their modified drive would then silently replace a certain executable with something else. And on that drive, the attack was persistent.

See Spritesmods.com [1] for a PoC from 2013 (!!). Guy managed to run Linux on the firmware.

[1] http://spritesmods.com/?art=hddhack

RISC architecture is gonna change everything

Reply on news.ycombinator.com