Hey,
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. :)
- 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.
- 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 ..)
//Peter