Firmware as a gaping security hole?

[Hypnos]

A question that is probably much too naive, but I have not found a satisfactory answer: isn't closed-source firmware, whether pre-installed on a device or loaded by the kernel, a gaping security hole in and of itself?

E.g., could not a mole working on the firmware team of motherboard vendor put in some lines to read the unencrypted contents of memory, then forward it to a 3rd party through a network device using an encrypted connection?

If the mole in question works for your government, we already know they have tapping setups with major data carriers, and are likely installing back doors into major operating systems, so why wouldn't they do the same with firmware?

Given this obvious attack strategy, why do we bother with military grade encryption for our data if we aren't using open source firmware?
_________________
Personal overlay | Simple backup scheme

[PaulBredbury]

[Hypnos]

I think that's true if you have a sequestered network where you can run a tool like psad, a la a corporate network behind a firewall where the expected behavior of all the devices behind the firewall is known.

What about a smart phone, or when you're using your laptop on the airport wireless?
_________________
Personal overlay | Simple backup scheme

[cach0rr0]

[John R. Graham]

Choose your poison. Where the product designer really cares about security, the firmware images can be signed (meaning that signature verification is made part of the product). But if this is done, the firmware blob is unpatchable because any modification would break the signature. Some might consider that binary firmware blobs are bad enough, but binary firmware blobs that you can never alter might be worse.

I agree that open source firmware provides more verifiability but it isn't possible for a lot of vendors because of licenses for the content of the firmware blob. I also would favor vendors that did open source their firmware, but not until this wasn't hurting me.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hypnos]

Binary firmware doesn't have to be patchable, just replaceable, so the manufacturer can issue new firmware that way (you can verify it's authenticity w/ a PGP key or something). But, this does assume you trust the manufacturer to never backdoor your system on purpose.
_________________
Personal overlay | Simple backup scheme

[John R. Graham]

Yes, agreed. Now, that said, silicon has been discovered that has functionality that wasn't supposed to be there. Afraid of opaque firmware? Me, too. But we accept something that is even more opaque.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hypnos]

I thought of that, but I wonder how much compromised silicon you can hide if you have an open source firmware and software driver stack.

In my example above, you'd have to have the few hundred code lines to implement the attack written as chip logic, without hurting the performance of the rest of the silicon and not being detected by the firmware/driver developers.

Perhaps someone with experience engineering such devices can shed light on whether this is feasible.
_________________
Personal overlay | Simple backup scheme

[wcg]

There was recent discussion on the kernel list of a proposal
to have the kernel sign loadable modules at compile time
and check the signatures at load time (the signatures have
to be in the kernel binary, imho).

That should probably be extended to loadable firmware.

This does not protect you from a priori vulnerabilities
designed into the firmware, of course, and one wonders
why not just include the firmware in the kernel binary,
since you would not be able to load modified firmware
without recompiling the kernel anyway.
_________________
TIA

[chithanh]

Of course device firmware can contain malicious code:
http://it.slashdot.org/story/10/11/23/198215/rootkit-in-a-network-card-demonstrated

Also Intel AMT (popular on many business desktops) has its own separate processor and provides backdoors into your system if configured to.

Whether this is bad or not depends on your threat model. Some hardware like hard disks need only be trusted if you boot from them or store anything unencrypted there. Same for network traffic, if you only communicate via IPSec then the network card cannot intercept or corrupt the transmission without being noticed.

Others like PCI devices can DMA over your memory (an IOMMU can mitigate this problem to some degree).

[Hypnos]

[chithanh]

Any code that is executed before the operating system loads can in principle not be defended against.

Early boot attacks exist that hide the existence of the IOMMU (or part of it) from the operating system.

[Hypnos]

Let me try to summarize for my own edification:

The BIOS can issue commands and otherwise control devices until it passes control to the OS on boot. After that, the BIOS is unable to execute malicious code, but individual devices can operate malicious code on their internal memory, or in the case of PCI devices by issuing PCI commands.

The risk from a malicious BIOS can be mitigated by having encrypted hard disk data that is only decrypted by the OS. The risk from malicious devices can be mitigated by only passing them encrypted data (e.g., IPsec, hard disk encryption). The extra risk from PCI devices can mitigated by enabling all IOMMUs known to exist.

The loophole here is that you need a trusted boot chain (BIOS, boot hard disk firmware, boot sector) which won't compromise the initrd which you use to decrypt the hard disk data. This can be mitigated somewhat buy using read-only boot media (e.g., CD-ROM) created on a trusted system.

Anything I miss?
_________________
Personal overlay | Simple backup scheme

[chithanh]

I don't think your risk assessment is accurate.

Firstly, BIOS code can be executed even in the absence of any malicious intent well after the OS boots (e.g. system management mode).
Boot-based Malware could even launch a "blue pill" style attack by using the CPU's hardware virtualization capabilities.

The operating system is not executed from the boot media, it is loaded into RAM and executed there. Between loading and execution, the code can be manipulated.

[Hypnos]

Thanks for the corrections!

[cach0rr0]

[Hypnos]

Given the risk of bricking the machine it's a nonstarter for me.

Any laptop coming preloaded with it and having a trackpoint would merit serious consideration from me.
_________________
Personal overlay | Simple backup scheme

[kimmie]

This morning, I went to make myself a coffee.

Next thing I know, I'm at my desk. I realise I'm emailing some guy in Exploitaria with my bank account numbers, passwords and ugh, I can't look... a few really nasty self-porntraits. I don't remember taking these last but judging by the shaving cuts I must have taken them just now. What? I feel sick, lurch to the bathroom and look in the mirror; in my eyes I see the room reflected. Little grey motion vectors appear when I move my head. Then the song of the sphincter starts up, and I rush to the crapper where I spend a couple really of uncomfortable minutes.

Clunk. Splish. In the bowl, I find what looks like a miniature satellite dish and a small circuit board. The dish has a nice yellow smiley printed on it, encircled by the words "Strongest Link 8". The circuit board has a logo on it. Grapes? I look closer. It says "Hucklehack Berryberry".

WTF????

[Hypnos]

I hate it when that happens. Esp. on tax day.
_________________
Personal overlay | Simple backup scheme