[LinuxBIOS] Adding Support for ATA Freeze Command.
stuge-linuxbios at cdy.org
Sun May 22 05:06:37 CEST 2005
On Sat, May 21, 2005 at 04:26:01PM +0100, Ralph Corderoy wrote:
> > On Sat, May 21, 2005 at 10:43:42AM +0100, Ralph Corderoy wrote:
> > > Are people generally aware of the ATA security commands?
> > No, probably not. Certainly not if people means everyone with a ATA
> > drive.
> No, sorry, I meant people on the list.
Oh, ok. Well, by now everyone should be aware. :)
> > 1. Find that higher level password from someone other than the
> > manufacturer.
> The manufacturer tends to set it to something unique and keeps a
> record of it against the unit's serial number.
Oh, ok, then that wont work.
> > 2. Build custom hardware or just a custom BIOS to do a brute
> > force search for the password in the drive.
> After five failed attempts the drive refuses to do anything more
> until a hardware reset or power cycle.
Right. Some drives I've had even had a limit of three attempts.
> Custom hardware could do the reset but I don't know if it's within
> the ability of a BIOS?
It's certainly possible to add a simple reset circuitry using common
components (one resistor+one transistor) on e.g. a parallell port and
control it from the BIOS. Just twisting wires together with component
pins would be enough, and doable in any environment.
> I am aware that someone in the UK has built hardware that can
> brute-force it in under 12 hours.
Ok. I haven't made any tests even though I've thought about this
matter earlier, but 12 hours feels a bit short. I guess it isn't
particularly CPU intensive though, no encryption, just add one and
send, with the occasional reset..
> > LinuxBIOS initializes the chipset and the payload may use the chipset
> > to speak to a disk.
> Right. So it's not LinuxBIOS itself that would be involved.
Well.. See discussion below.
> > I'm not sure this functionality really belongs in the init part of
> > LinuxBIOS,
> No, I don't think it does unless there's already ATA commands in
> there that talk to a drive.
Right. There aren't. But..
> > but perhaps you could have it added to Linux if it isn't already
> > available there through ioctl() calls.
> It's possible in Linux already at the system call level, and
> recently hdparm added support through its -F option -- the c't
> article's author sent a patch IIRC, but by the time Linux is
> running is a bit late. A malicious program running under Linux
> where Freeze has already been done by hdparm could write to the MBR
> causing the password to be set on the next boot. That's unless the
> BIOS has done a Freeze before the MBR gets run.
My humble opinion is that you have much bigger problems if a
malicious program has root priviledges in your system.
Sure, if a security "hole" is easy to plug, why not plug it, but
there are many other security measures that can and should be used
on production systems with important data that are effective for
recovering from an attack of this kind as well as several others.
(Redundant hardware and storage, with external backups.)
> > There's a problem with the interaction required, LinuxBIOS has
> > always been designed to not require any configuration or options
> > to be handled interactively, which I think is good. Others will
> > of course disagree. :)
> It does need an element of configuration else the drive would
> always be frozen and the password could never be set. It sounds
> like FILO could be the place. Is that the standard `boot from a
> hard drive' payload with LinuxBIOS?
(See here about the things above.)
..yes.. At the moment, standalone FILO or the FILO included in
Etherboot is the standard boot-from-storage payload for most OSes.
The intention, however, has always been to use Linux as the boot-
from-anything payload and we're getting closer to that becoming
reality each day. The showstopper is flash ROM size, but that is
increasing on new mainboards, and LPC (where any size ROM can be
used) is getting much more popular as well.
Then, suddenly, the Linux kernel isn't so late in the boot process.
Remember, LinuxBIOS doesn't care about legacy junk such as the MBR,
it starts the payload immediately, as per compile-time configuration.
But, if the malicious program can write to MBR, it can also write a
new BIOS to flash. Rather than trying to stop root from destroying
hardware I'd prefer to make sure the system doesn't run as root or
make sure that the hardware can't be destroyed, or that it doesn't
matter if it IS destroyed. (Security commands unsupported or VMware
or frequent backups or ..)
More information about the coreboot