Secure hardware again, Re: cyber-"terrorism"?

[Matthew Astley]

On Wed, Sep 18, 2002 at 01:25:48PM +0100, Ben Laurie wrote:
> Brian Gladman wrote:

> >Although both David and Peter are unconvinced that the gains in
> >security terms would be significant, I have to disagree with them.
> >If we can get strong process separation and full control of memory
> >and peripheral access we don't need anything more from hardware.
> 
> I think their point, and I'm inclined to agree, is that of the
> things you say we need to be secure, the least important is the
> trusted boot - and if I have a security kernel running, I need it
> even less. I'm not sure what you mean by "limited code metrics", but
> clearly the biggest source of security problems today is bugs in
> code, so I imagine that you are hoping to address that in some way.
> I'd like to hear more.

I have to say I agree with Brian. Secure the hardware... but provided
this doesn't involve supporting or encouraging the TCPA in any way.

IMHO dumb hardware is the easiest and safest solution. You can
secure-boot a BBC B just by knowing that the expansion slots are
clean, and I'd be impressed if you could trojan the HDC. 8-)

If you can _do_ secure booting on a PC, and the people who implement
it are different from the people addressing buffer overruns etc., the
parallel effort is sensible.

To be secure you have to patch all the holes. Fate (or money/politics)
has brought the hardware bugs up the priority list from where they
would otherwise be for most people. If the bugs are to be fixed, let's
fix them in a sane way.

Software BIOS protection doesn't seem very reliable. If the box is
r00ted enough to run LILO (or whatever) then the systrace protection
for the BIOS write calls isn't enough.


I've suggested making a "Compact Flash card" to "dumb read-only BIOS"
bridge to enable secure booting. The plan would be to remove the CF
card and put it in a standard read/write adapter when one needed to
reflash it.

AFAICS this would serve Brian's desire for a secure boot, and be much
cheaper (in terms of money and side effects) than anything TCPA are
suggesting.


Hmm, secure boot damns the Transmeta Crusoe right out of the water,
AIUI. That's unfortunate.

My modem is reflashable, but I'm pretty sure it can't hurt me by
anything other than DoS.

Current IDE devices and graphics cards seem far too smart to be
sitting on the bus directly. We don't have the option of using dumb
hardware here.

> [...] Not entirely sure what you mean by "full control of memory and
> peripheral access" but if its what I think you mean (i.e. as well as
> an MMU a way of mediating DMA and other access by hardware other
> than a CPU), then this isn't, as I understand it, a TCPA feature in
> any case (but is a Pd one). I'm not sure I believe that controlling
> memory access from peripherals is an adequate defence against
> hostile hardware in any case.

You need to ensure that the hard disc controller can't grub around in
memory for the exploit code's process entry and clear the UID byte
(ie. make the process run as root). I don't know much about DMA.

Just as important though is ensuring that the HDC doesn't flip the
setuid bits for you the next time you read the directory entry for
/tmp.

Current systems for signing binaries (eg. bsign) could prevent the HDC
returning a trojaned "bash" if they ran a runtime check, instead of as
a tripwire-like scan. Of course performance would take a hit.
TNSTAAFL. Maybe the hit could be spread out during the run by
digesting the program in pages and then signing the block of digests?

I've never heard of an OS that signs the contents of directory inodes.
Maybe I should get out more.

If graphics cards were strictly "write only" devices, they couldn't
pose a threat.


So, apologies if I seem to be running in "make it up as I go along"
mode. I appear to be suggesting not trusting the smart peripherals any
further than you can throw them. This doesn't require any hardware
mods beyond control of DMA, and you get for free some protection
against attackers who remove and modify the contents of your drive.


Matthew  #8-)