Schneier on Security

RootWyrm • January 7, 2014 2:11 AM

Sigh. You know what’s disgusting? That people don’t understand how BIOS actually works any more. Not at all.

First of all, if it was in BIOS, it would be show in standard BIOS forensics. Period. Either that or you’re doing it wrong. There is no third option, and I would certainly know – I’ve DONE it. Anyone affected by it would know the second they pulled ANY misbehaving gear into a diag lab that something had tampered with it.

People need to stop spreading this outright false information about ‘badBIOS’ and such. Period. Just because paranoia is proved correct doesn’t mean you’re not completely and utterly wrong from a technical standpoint. You think you’re right? Pull the suspect chip, do an SPI dump and send it to an expert to disassemble. (Provided binary updates are more frequently partials.)

FEEDTROUGH doesn’t reside in the BIOS, end of story. Can you get covert channel comms of sufficient complexity to do the job in less than 512 BYTES of data? Oh, and it can’t be in hardware without subverting the entire chain and multiple factories – these are devices built with many parts right off the shelf. Same for stealthing it in the CMOS parts themselves – you would have to subvert multiple factories at multiple suppliers. Nobody single-sources the flash.

And nobody competent enough to write something in 512 bytes is going to be stupid enough to put it in a place where it can be EASILY found. I can very, very easily find out if a BIOS’ contents have been altered with $10 in hardware from eBay. Occam’s Razor: if some random guy changing his BIOS logo can find it easily, then it’s not going to be there. I mean seriously – that would be just the height of stupidity on the developer’s part.
Plus, for stuff like Juniper, Cisco, etc, the BIOS is mostly what’s termed generally as “non-reference” meaning they aren’t just customizing AMI, Award, etc. Nevermind that it’s non-UEFI and therefore true zero-portable – code cannot be re-used safely even between ‘minor’ hardware revisions.

Not to mention, every proper forensic analysis has found no evidence of the claimed ‘badBIOS’ and variants to date. That’s because, hey guess what, it’s not in the BIOS. See, the BIOS is like a piece of paper that you write on with pen. What’s on there is what’s on there. Put it down in another room away from the notebook it came from, and the letters haven’t changed – they can’t. You can’t just magically erase any evidence of it, especially if it hasn’t been toggled to write and is currently running and the malware can somehow detect physical access and the list goes on and on.

So I guess congratulations to all the people who have wasted hours doing forensics wrong or in the wrong place? I mean seriously; use your common freaking sense here. What are you going to do in 512 bytes? And why 512 bytes?

Because 512 bytes is total space for an MBR. And about the most guaranteed ‘free’ space you’ll find, if you find any. And you’re not going to put the payload in it. BTDT; it’s uselessly small for complex malware – especially when you consider Flame was 20MB+ for a very small set of operations and devices. But if you want to set a series of registers in compromised devices nobody’s had the good sense to look at, which are much harder to forensically inspect? Oh yes. And those devices also have more room and can lie dormant.
Oh, and the way the PC BIOS has to work permits you to set up an early stage MBR of 512 bytes that sets a bunch of registers and then does a ‘go to next MBR’ in less than 50 cycles at real-mode clock. And the only way you’re going to catch that nasty is going cycle by cycle on actual hardware. Literally one cycle at a time.

And wouldn’t you know it… most non-PCH USB controllers are burst reprogrammable and happen to be able to present as MBR capable. Just as a starting point. (It’s definitely an entry point I would consider using if I had known quantity hardware using a common part.) Also remember that it has to begin prior to protected mode and persist past SMM; not a lot of possibilities.

Obviously a lot of gross oversimplification and leaving out a tremendous amount of details, but you get the general idea of it.

But really, it’s a whole stack of Occam’s Razor. Don’t leave it in an area easily examined forensically; use the most common part for maximum coverage with minimum effort; use something with guaranteed variables (e.g. network stack present and not disabled, insensitive to external factors like link state, etc.); use the minimum size and effort to enable a wider range of payloads; and locate it in a device where any intervention or operation would have the least risk of exposing it or be unable to expose it including physical examination. CMOS has and always will fall on the wrong side of all of those.

Unfortunately, since this is related to some sensitive ongoing things, that’s the extent of what I’m comfortable saying publicly or privately. In short: stop wasting everyone’s time claiming it’s the BIOS and pointing to the BIOS. It’s not the damn BIOS; only for specific targeted platforms (as in FEEDTROUGH, but that is questionable for various reasons) is it BIOS related, and BIOS is being used as a generalization and lever.
Think you’ve got a sample? Start desoldering MACs (Ethernet for you younguns), third-party USB controllers, hard drive uCs, IPMI, and third-party SATA. Then dump onboard contents (oh how I do not envy people attempting that.) Don’t waste time on SuperIO since any modern one loads from CMOS and can’t act as MBR or loads from IPMI and will be in IPMI contents.

Unfortunately, GFL getting clean samples to compare against – I’ve been doing “bad things” with OROMs since 1997 and even I can’t get a proof clean firmware for any of that. Proof clean means a sanitized build from the manufacturer – highly sensitive and proprietary. But those are the parts you should be looking at.

Will probably write up something on my blog again as to why TAO BIOS != ‘badBIOS’, never did, and never could – not ever. (Oh boy, sifting through 10,000+ spam or insane comments again.) It’s as electrically impossible as 208VAC @ 30A from nothing but a 1.5V D cell. It is exceptionally depressing that so many supposedly ‘technical’ people haven’t bothered to do enough very basic research to understand that simple fact.