[OT,long] "Zeroing" a machine / flashing from OS (fwd)

[Eugene Leitl]

-- 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 at cs.umd.edu>
To: Peter Lister <P.Lister at sychron.com>
Cc: linuxbios at 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 at 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