[TETENAL]

ATA hard disks can be protected with a password. This password will be asked for by the BIOS which then unlocks the disk. To avoid that a malicious program changes the password of the disk the BIOS locks the security features of the drive so that the password can not be changed. Even when the password feature of the drive is not used the BIOS needs to set the security lock of the drive or any program can enable the password. This would mean that a malicious program could set the password to something unknown to the user who wouldn't be able to access his data any more after a reboot.

Apple computers do not use the password features of ATA drives afaik, but heise.de found that they also negligently don't set the security lock of the drive:

http://www.heise.de/ct/english/05/08/172/

The question is: have the BIOS programmers of the desktop PC manufacturers thought of this? A tour of inspection through the device zoo of c't magazine's editorial staff provided some shocking insights: In the case of two thirds of all the PCs inspected the security functions were not frozen; and this group included not only devices cobbled together but also current branded PCs by Dell, HP and Apple.

Currently no malicious program that makes use of this security risk is know yet. Apple as usual sees no need to react:

Apple […] sees no need for action - to load a kernel extension it is necessary to enter the administrator's password, the company noted. We have come to an agreement with Apple to the effect that we will program a demonstration of the damaging action and make it available to Apple. Perhaps someone in the United States will change his or her mind once he or she can only access their hard disk after entering correctly "c't Magazin für Computertechnik" (including the umlaut!).

[JLL]

Since you have to give the app your password, the app can do absolutely everything - including wiping the entire hard drive.

[TETENAL]

Originally Posted by JLL

Since you have to give the app your password, the app can do absolutely everything - including wiping the entire hard drive.

If I understand the c't article correctly you don't need to enter an admin password if you run as admin already. Most Mac users run as admins. Even when you give away your password the most a malicious program can do is delete your hard drives, which is bad enough, but at least you can start over with a backup.

Without the security freeze lock however it can now also economically destroy all attached hard drives.

It's a lame excuse to say that the password is required. The security freeze lock feature exists for a reason and Apple should update the OF to prevent the risk of total data loss and hard drive damage instead of shifting the blame to the users.

[Millennium]

Forgive me if I'm misunderstanding something, but if Macs don't use the password feature anyway, then why does this matter? Changing the drive password wouldn't have any effect, would it?

[OreoCookie]

Because someone else could lock your harddrive, Millenium.

[Millennium]

Originally Posted by OreoCookie

Because someone else could lock your harddrive, Millenium.

That's the point; if OSX ignores the password anyway, then wouldn't the lock have no effect?

[TETENAL]

Originally Posted by Millennium

That's the point; if OSX ignores the password anyway, then wouldn't the lock have no effect?

OS X can't ignore the password. It's a hardware feature of ATA drives. If something sets the password you can not get hold of any data at all, no matter what OS. If some malicious program does set the password for your drive you can throw it away.

[JLL]

Originally Posted by TETENAL

If I understand the c't article correctly you don't need to enter an admin password if you run as admin already. Most Mac users run as admins.

You can't install anything into /System/Library/ without entering a password - it needs root access.

Originally Posted by TETENAL

Even when you give away your password the most a malicious program can do is delete your hard drives, which is bad enough, but at least you can start over with a backup.

It can erase every single hard drive connected to your system - including network mounted hard drives.

[Millennium]

Originally Posted by TETENAL

OS X can't ignore the password. It's a hardware feature of ATA drives. If something sets the password you can not get hold of any data at all, no matter what OS. If some malicious program does set the password for your drive you can throw it away.

Ah; in that case there is a problem.

It's not as serious as it might sound, given that as JLL points out, it requires not just admin access but root access. This is, frankly, enough for most. The bug should certainly be fixed, but it is not as critical as, say, remotely auto-installing Dashboard widgets.

[TETENAL]

Originally Posted by Millennium

It's not as serious as it might sound, given that as JLL points out, it requires not just admin access but root access.

Are you sure a normal admin process can not send ATA commands directly to the drive? The article doesn't seem to be conclusive about that.

Originally Posted by Millennium

The bug should certainly be fixed, but it is not as critical as, say, remotely auto-installing Dashboard widgets.

With total data loss, no chance to recover data with a data recovery application, and economically totalling the drives, the consequences are potentially severe. All it needs to fix this is an OF update to set the security lock freeze. I don't understand why Apple and JLL oppose this.

[eevyl]

Originally Posted by TETENAL

Are you sure a normal admin process can not send ATA commands directly to the drive? The article doesn't seem to be conclusive about that.
With total data loss, no chance to recover data with a data recovery application, and economically totalling the drives, the consequences are potentially severe. All it needs to fix this is an OF update to set the security lock freeze. I don't understand why Apple and JLL oppose this.

Well, I'm not 100% sure but to access the hardware directly you need to build a kernel IO extension, and that for sure needs the password to get installed even if you are admin.

[Gee4orce]

Mac's don't have BIOS.

They have OpenFirmware.

FYI.

[analogika]

Originally Posted by TETENAL

Are you sure a normal admin process can not send ATA commands directly to the drive? The article doesn't seem to be conclusive about that.

I thought all hardware access has to run through the HAL of OS X?

[ghporter]

If OS X doesn't interface with the ATA drive's password security system, then how can someone alter the drive's password while it's installed in a Mac?

[analogika]

From TFA:

Mac OS X behaves in a similar fashion to Windows: Given root rights kernel extensions can be loaded, which can then issue ATA commands.

[Millennium]

Originally Posted by TETENAL

Are you sure a normal admin process can not send ATA commands directly to the drive? The article doesn't seem to be conclusive about that.

Only a process actually running as root can do something like this. There are only four ways for a process to run as root:

• It must be actually started as root.
• It must be run by the system during the boot process (as with a kext)
• The sticky bit in its permissions must be set and it must be owned by root (setting this up, by the way, requires root).
• An Admin user must authenticate, using either sudo or the GUI, to momentarily grant root privileges. This requires a password.

End result: somewhere along the line, someone has to enter a password, or this is not going to happen.

With total data loss, no chance to recover data with a data recovery application, and economically totalling the drives, the consequences are potentially severe.

The consequences of a meteor falling on my head would be severe indeed, but I'm more concerned about accidentally cutting myself with a knife while cooking. Why is this? Because although the meteor implies more dire consequences, the odds of it actually occurring are extremely low. The consequences of cutting myself by accident are probably low -though they could be more severe- but the odds of it occurring are much higher, to the point where I consider it a greater point of concern.

All it needs to fix this is an OF update to set the security lock freeze.

There may not be anything 'all' about it; depending on how this command would be sent this may not be a trivial thing to do at all.

I don't understand why Apple and JLL oppose this.

It doesn't sound like it's an issue of opposition, as much as not seeing it as a truly serious issue requiring immediate patching.

[ghporter]

From TFA:

Mac OS X behaves in a similar fashion to Windows: Given root rights kernel extensions can be loaded, which can then issue ATA commands.

Exactly.

My question should have been more complete, as nobody could tell which post I was thinking about when I posted it. I was wondering how any kernel process could interact with the drive without having an admin on that machine start it. An admin can hose a Mac just about as easily as an admin can hose up a Windows box if he or she is either malicious or incompetent, but for the life of me, I can't see how this could "just happen."

[TETENAL]

So then it can not "just happen". It requires that the user is lured to give his password.

However ATA drives have a "security lock freeze" feature so that it can not happen at all. Even when a naive user gives away his password. This is done because not only data can be lost but also the drive could be destroyed.

Apple doesn't make use of the security lock freeze which is an unnecessary negligence.

[CharlesS]

Hmm, this does sound like something that needs to be fixed.

Yeah, if I give a malicious app my password, it can rm -rf / my drive and erase everything, but at least I'd be able to reformat, restore from backup, and get on with my life. From the sounds of it, someone who exploited this vulnerability could cause me to actually have to buy a new hard drive.

[analogika]

Originally Posted by TETENAL

Apple doesn't make use of the security lock freeze which is an unnecessary negligence.

Agreed.

I just don't think it is such a "major" issue.

It definitely needs to be fixed, though.

[Person Man]

Originally Posted by TETENAL

Apple doesn't make use of the security lock freeze which is an unnecessary negligence.

Is there a way for the end user to turn on the security lock freeze to protect themselves while we wait for the manufacturers (i.e. Dell, HP, Apple, etc) to fix it?

[TETENAL]

Originally Posted by Person Man

Is there a way for the end user to turn on the security lock freeze to protect themselves while we wait for the manufacturers (i.e. Dell, HP, Apple, etc) to fix it?

c't made solutions for Windows, Linux, and Mac OS X. See the article I linked to in the first post. It installs a kext on Mac OS X, which is only a partial solution since if a malicious kext would be loaded before the security kext it would be too late.
Currently nothing is known to exploit this and I don't dare to install any kext. I would prefer a fix by Apple.

[Kristoff]

There's another vulnerability.

If someone is standing behind you, they can read EVERY SINGLE THING YOU TYPE!!!

Apple needs to fix this ASAP

[Person Man]

Originally Posted by TETENAL

c't made solutions for Windows, Linux, and Mac OS X. See the article I linked to in the first post. It installs a kext on Mac OS X, which is only a partial solution since if a malicious kext would be loaded before the security kext it would be too late.
Currently nothing is known to exploit this and I don't dare to install any kext. I would prefer a fix by Apple.

So in other words, you can't set some bit on the hard drive once, and it will remember it across reboots...

Combine that with this, and we've got a real problem.

[Big Mac]

Originally Posted by Person Man

So in other words, you can't set some bit on the hard drive once, and it will remember it across reboots...

Combine that with this, and we've got a real problem.

That's a Windows exploit. We're talking about the Mac. Still, Apple's explanation for why this ATA issue is a non-issue does seem to be lacking persuasive force.

[Person Man]

Originally Posted by Big Mac

That's a Windows exploit. We're talking about the Mac. Still, Apple's explanation for why this ATA issue is a non-issue does seem to be lacking persuasive force.

I know that particular one is a Windows exploit. But it would be just as simple for someone, knowing that an organization uses Macs, to enable the hard drive password, and then hold their data for ransom... "We won't give you the password unless you give us $xxx.

[milhous]

quickly, everyone move to SCSI!

[JKT]

Originally Posted by Person Man

I know that particular one is a Windows exploit. But it would be just as simple for someone, knowing that an organization uses Macs, to enable the hard drive password, and then hold their data for ransom... "We won't give you the password unless you give us $xxx.

Any organisation worth its salt would have backups of all its (important) data on an external source. They'd have to be idiotic not to. It could be argued that any consumer would be equally stupid not to have a backup of their important data. However, the real world gets in the way of this idealism...

[theolein]

I wonder if this couldn't be handled by Open Firmware? OF has access to all devices prior to booting the OS, and OF is one hell of a lot more powerful than any BIOS. I'm sure a simple firmware upgrade could fix this by setting the password once with a standard Apple password and then entering it on each boot.