-- Eugen* Leitl <a href="http://www.lrz.de/~ui22204/">leitl</a> ______________________________________________________________ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 ---------- Forwarded message ---------- Date: Sat, 30 Jun 2001 11:13:15 -0400 (EDT) From: Bill Arbaugh <waa@cs.umd.edu> To: Peter Lister <P.Lister@sychron.com> Cc: linuxbios@lanl.gov Subject: Re: [OT,long] "Zeroing" a machine / flashing from OS I essentially solved this problem with a prototype built using the 430HX chipset a few years ago. The project, AEGIS, used the boot block portion of the flash to hold intitialization and recovery code. Everything else had a digital signature paired with it. Prior to passing exec control to the next step- the signature is checked. If it's valid, then we pass control. If it's not, then we try to recover a valid version. Essentially, I built a prototype of the TCPA spec (www.trustedpc.org) before the TCPA was even a thought. That's history. Today, we've been funded by DARPA to add this same functionality to LinuxBIOS (or at least use the init routines from LinuxBIOS). We also will add crypto hardware support. We're just getting started, but we hope to have some results late summer early fall. We're also hoping to team up with a major manufacturer so that we can have the capability on their servers and laptops. Our biggest problem is that we don't want users to have to change their flash chip. That means that we can't use Linux as the loader. Instead, we need to use something along the lines of GRUB. We're looking at a number of alternatives now, and we'll let everyone know what we find. Bill ------------------------------------------------------------------- Bill Arbaugh www.cs.umd.edu/~waa University of Maryland waa@cs.umd.edu College Park 301.405.2774 ------------------------------------------------------------------- On Sat, 30 Jun 2001, Peter Lister wrote:

James Finnie said...

...

Many boards do infact have a jumper on the board, which removes the ability to flash the BIOS without having physical access to reset the jumper - these mechanisms are completely secure, as they disable one of the flash chip write pins. And lets face it, if people have physical access to the machine, and want to do you some damage, there is little you can do about it.

I'm thinking of cases where a hostile party can run any *software*, including an arbitrary bootloader or OS, but can't get access to the hardware to set a jumper or hit a switch (unless it's a software controlled switch, of course - which includes the ATX "power switch"; more of a polite hint to shut down). You tell me that the jumpers *do* provide physical security. Fine - though it occurs to me that the manufacturer's "secret" flash code might just look at the state indicated by said jumper and refuse to flash, with no physical control. Few people would know the difference.

Yes, if someone has physical access, all bets are off - the question is "How close can I get to physical access just via software?" and the answer would appear to be "If I can flash system rom with an evil BIOS, pretty close".

...

If a hacker has gained sufficient access to your mission critical datacenter systems through a trojan, in order to be able to run some arbitrary flashing code, I would say that was the least of your worries.... they already have access to whatever they could want, why would they bother implanting a trojan BIOS?

Because it survives the scrubbing of magnetic media - even the complete disassembly of the machine. Done well, it would be undetectable by any current virus checker. You have to assume, for instance, that it could pervert the disk controllers. I'm probably not interested in user A, whose lax security gave me a root exploit (as you say, he's screwed anyway) - I'll bide my time and wait until A has gone bankrupt and all the computer systems are auctioned off to user B - whose system is otherwise impregnable.

I appreciate that commodity hardware is not designed for this sort of security, since it is considered desirable to update in the field with just a floppy. Most people consider a system board with BIOS as just a component. Machines are being treated more as anonymous cluster members than standalone systems with specific identities, so that it seems likely that they will be moved between jobs quite dynamically.

Given the stories of trivial "write protection", manufacturers assurances of security seem generally worthless. :) Probably the best defense would be a hardware "factory settings" switch which zaps all nonvolatile storage back to a burned-in state, rather than relying on "write protection". The machine could press its own button, since that would be a guaranteed safe option, as even hostile software could do no more than reinstate the trusted code.

Don't be surprised when the first LinuxBIOS derived rom virus toolkit gets into the hands of the script kiddies and the FBI arrests Ron. Of course, this may be the best way to get the manufacturers to solve the problem (a virus, not arresting Ron).

-- Peter Lister, Sychron Inc. - 1-866-SYCHRON Intelligent Infrastructure - www.sychron.com