Hi,
Are people generally aware of the ATA security commands? They allow a password to be set on a hard drive. It's the hard drive that's doing the password storing, not the motherboard, so the drive's still locked if it's moved to another machine. On boot-up the BIOS recognises the drive's locked and prompts the user for the password. It's also the normal UI for setting it in the first place.
Anyway, my point is passwords are typically not set. This means something malicous can set it and the next time the machine boots the user's locked out of his own drive. The c't magazine had an article on it recently.
http://www.heise.de/ct/english/05/08/172/
Once a drive's locked with an unknown user password then it's a dead drive unless the manufacturer can be persuade to give you the higher level password that allows a security format of the device to be done. This normally requires a paper-chase to prove you're the rightful owner.
Options are for users to set the password on their drives so it can't be set malicously to something unknown to them but that's a pain because it needs supplying on boot-up. Or, for the ATA Freeze command to be used soon after boot-up. This puts the drive in a state where it won't accept any password setting until after the next boot.
(The ATA-3 spec. is http://www.t13.org/project/d2008r7b-ATA-3.pdf -- see pages 33 and 75 by the number written on the page.)
Ideally, the Freeze needs to be done as soon as possible in the BIOS -> bootloader -> OS chain to make it harder to set the password before the freeze is done. That's why I'm here. :-)
It LinuxBIOS were to add support for Freeze drives it would be another advantage over other BIOSes. Am I right in thinking that LinuxBIOS itself knows nothing about ATA and that's left to FILO? Is that the only payload that deals with ATA?
(I'm also going to lobby the Grub people for those of us that don't have BIOS support for ATA Freeze.)
Cheers,
Ralph.
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.
Once a drive's locked with an unknown user password then it's a dead drive unless the manufacturer can be persuade to give you the higher level password that allows a security format of the device to be done. This normally requires a paper-chase to prove you're the rightful owner.
I can see at least two other ways to recover the drive;
1. Find that higher level password from someone other than the manufacturer.
2. Build custom hardware or just a custom BIOS to do a brute force search for the password in the drive.
It LinuxBIOS were to add support for Freeze drives it would be another advantage over other BIOSes. Am I right in thinking that LinuxBIOS itself knows nothing about ATA and that's left to FILO?
LinuxBIOS initializes the chipset and the payload may use the chipset to speak to a disk.
Is that the only payload that deals with ATA?
No, I know of a few other; Etherboot, Linux, ADLO and the FreeBSD kernel if we got that booted, I don't remember.
I'm not sure this functionality really belongs in the init part of LinuxBIOS, but perhaps you could have it added to Linux if it isn't already available there through ioctl() calls.
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. :)
//Peter
Hi Peter,
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.
Once a drive's locked with an unknown user password then it's a dead drive unless the manufacturer can be persuade to give you the higher level password that allows a security format of the device to be done. This normally requires a paper-chase to prove you're the rightful owner.
I can see at least two other ways to recover the drive;
- 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.
- 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. Custom hardware could do the reset but I don't know if it's within the ability of a BIOS?
I am aware that someone in the UK has built hardware that can brute-force it in under 12 hours.
It LinuxBIOS were to add support for Freeze drives it would be another advantage over other BIOSes. Am I right in thinking that LinuxBIOS itself knows nothing about ATA and that's left to FILO?
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.
Is that the only payload that deals with ATA?
No, I know of a few other; Etherboot, Linux, ADLO and the FreeBSD kernel if we got that booted, I don't remember.
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.
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.
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?
Cheers,
Ralph.
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
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.
Hi again Ralph,
On Mon, May 23, 2005 at 06:13:32PM +0100, Ralph Corderoy wrote:
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.
Right, no redundant storage, which probably wouldn't be susceptible to the problem anyway since the security commands only work with ATA and S-ATA drives.
I know I wouldn't care much about the ATA drive if I was prepared to deal with downtime and labor required for forensics and recovery in the above scenario.
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.
With Linux as the payload, the OS is 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.
Right. And the option can't be accessible by root.
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 difficult and less portable" is not "secure" - I would argue quite the opposite; it's security by obscurity, and that's always a bad idea.
But sure, if you want to protect the BIOS from software run as root, use real ROM (not flash). And if you want to protect the ATA drive from being locked by root, have the software in ROM send a freeze command.
Question is, should LinuxBIOS really go about changing configuration and settings of the hardware beyond what is absolutely neccessary for the payload to function?
I'm not sure it should, I think it's better to put the freeze command in FILO or Linux or 9load or ADLO or whatever payload.
From a security point of view it doesn't matter since the LinuxBIOS
init code and payload are stored in the same place and if the payload can be changed the init code can be changed too.
//Peter
-
Peter Stuge -
Ralph Corderoy