# 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?

----------

## PaulBredbury

 *Hypnos wrote:*   

> forward it to a 3rd party through a network device

 

There would be someone who notices and publicizes this - who's logging suspicious network activity using iptables.

But yeah, avoid Huawei routers  :Wink: 

----------

## 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?

----------

## cach0rr0

 *Hypnos wrote:*   

> 
> 
> Given this obvious attack strategy, why do we bother with military grade encryption for our data if we aren't using open source firmware?

 

as a user of iwl1000-ucode, I'm just not all that worried

it hasn't been updated since April 2011, and it doesn't really stay stable long enough to give anyone any particularly useful data  :Laughing: 

i consider this a must-have security feature - firmware that is so unbelievably shitty and unstable, it doesnt stay functional long enough to provide for an attack vector.

----------

## 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

----------

## 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.

----------

## 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

----------

## 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.

----------

## 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.

----------

## 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 wrote:*   

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

 

Would motherboard firmware be able to issue DMA commands to effect the attack I described in the first post?  What if the operating system controls the IOMMU?

----------

## 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?

----------

## 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!

 *chithanh wrote:*   

> Firstly, BIOS code can be executed even in the absence of any malicious intent well after the OS boots (e.g. system management mode).

 

I just wiki'd system management mode -- wow, that's a wide open gate.  Malicious BIOS firmware could just issue the SMI interrupt at some fixed time after power-on, and get full access to the data in memory.

 *Quote:*   

> Boot-based Malware could even launch a "blue pill" style attack by using the CPU's hardware virtualization capabilities.

 

Modulo a malicious BIOS, the hypervisor can be disabled or locked down.

 *Quote:*   

> 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.

 

Understood.

It really seems there's no way around having a trusted BIOS.

----------

## cach0rr0

 *Hypnos wrote:*   

> 
> 
> It really seems there's no way around having a trusted BIOS.

 

one of the reasons coreboot has begun to look very interesting to me. 

that, and, the nonsense with UEFI and code signing

going to affect how i buy my mobos henceforth. I've as of yet not really even gotten my feet wet, just started reading.

----------

## 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.

----------

## 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.

----------

