[LinuxBIOS] Adding Support for ATA Freeze Command.
ralph at inputplus.co.uk
Mon May 23 19:13:32 CEST 2005
> > 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.
OK, well if I come back in another life where I have some free time I'll
have a play.
> > 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..
I too thought it was a bit short but he works for a hard disc company
and I wouldn't be surprised if either he has some means of detecting
whether he's getting warmer or not, or perhaps he just tries likely
passwords first and he was talking about the typical time taken.
> > 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.)
A scenario: I have daily backups, I carry out a post-mortem after
detecting an intrusion, I'm happy to re-install from scratch and restore
a known-safe backup, and fix the entry point of the cracker before
exposing the machine to the network. But the hard drive is now for the
bin because it's been locked.
I'm happy to take all those other precautions, but I'm trying to cut out
one of the few things a malicious, remote, cracker could do that costs
> 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.
I agree if the Linux kernel is very early on, i.e. the BIOS stage, then
it's good enough for the kernel to do it. I was talking about the OS
once started by the bootloader. But wouldn't that require a run-time
option again because you'd want to avoid the freeze happening some
times, and without flashing a new BIOS.
> 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 ..)
It's far easier and more portable to write the MBR than it is the BIOS.
Given root access will sometimes be obtained I'd like to stop them being
able to make my hard drive defunct; its data I've got backed up,
offline. It's all a trade-off but it would seem that adding an ATA
Freeze most of the time on start-up is a worthwhile one.
More information about the coreboot