Hi Peter,
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 me hardware.
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.
Cheers,
Ralph.