An errant debug switch in 10.7.3 could expose encrypted data for some Mac users.

Share this story

A security flaw in the most recent version of OS X Lion, 10.7.3, can allow anyone with access to system logs to gather passwords to decrypt legacy FileVault home directories or access remote home directories of networked users. Though the flaw was first discovered a whopping three months ago, it has been widely publicized after a security researcher posted details of the flaw to a cryptography mailing list on Friday.

While only users with admin or root access could access the passwords stored as plain text in the log files, it's possible that malware could be created to look into the file for any passwords in order to access personal data.

The security implications are even worse, though, according to security researcher David Emery. "The [system] log in question can also be read by booting the machine into firewire disk mode and reading it by opening the drive as a disk or by booting the new-with-Lion recovery partition and using the available superuser shell to mount the main file system partition and read the file," he wrote to the cryptography e-mail list on Friday. "This would allow someone to break into encrypted partitions on machines they did not have any idea of any login passwords for."

A process called "HomeDirMounter" is used by "authorizationhost" on OS X to mount remote home directories stored on a networked server, commonly in enterprise environments like offices or schools. This process accesses the remote directory and mounts it to a local computer as if it existed locally on the main boot volume. This same process mounts encrypted FileVault home directories created with earlier versions of OS X, which are stored in a separate, encrypted virtual volume (or sparse bundle).

In OS X 10.7.3, HomeDirMounter logs information that appears to have been used for debugging during development of the 10.7.3 update. Among the information it stores in var/logs/secure.log is the password used to mount a home directory, in clear text, anytime a remote or FileVault home directory is mounted.

Thankfully, passwords for standard local users aren't logged. However, users relying on the older FileVault could potentially have their encrypted data exposed to anyone with admin or root access to their machine.

The same vulnerability puts network users at risk—any user with admin privileges could potentially access the secure.log file and grab passwords for other users on the network that have recently used the same machine.

The flaw appears to have first been reported by a German systems administrator who posted about it to Apple's support forums in February. His post went unanswered until this weekend, however, when Emery's detail of the flaw was widely circulated.

No one from Apple appears to have acknowledged the flaw as of yet, but Paul Hazelden, a system administrator working in an education environment, claims in a post on Novell's support forums that betas of the next version of OS X, 10.7.4, do not exhibit the password logging problem. (Hazelden's school uses a Novell authentication service called Kanaka, which is indirectly affected by the same password logging bug.) It's also worth noting that the flaw is not present in OS X 10.7.2.

Until Apple releases the update to OS X, the only workaround appears to be running periodic scripts which purge the debug lines from secure.log. Alternately, local FileVault users can be protected somewhat from external hacks by using FileVault2, which encrypts the entire boot volume instead of just individual home directories.

So since my Mac Mini came w/Lion on it, I have never used the original File Vault, so I'm fine. Good to know. Looks like, if possible, the best answer is to be upgraded to Lion and make sure evrything is encrypted w/FV2. Naturally this answer won't work for unsupported systems or anything PPC.

It would seem the past couple months have been bad for OS X security. I read a report recently by Sophos which indicated that due to repeated attempts to improve Windows (7) security it actually is more secure than OS X. There are aspects of system security that Apple have yet to implement which are standard in Windows for a couple years now. I hope Apple up their game related to security. Their response to the recent Flashback outbreak was pretty poor (slow to respond, inadequate response, lack of good communication and openness).

I don't think the situation is all *that* bad, really. All OSes have holes and bugs--it goes with the territory. I think a bigger problem for the OS X community might be the RDF-spawned denial by many who actually think OS X is immune to such problems ("It's why I bought a Mac!" and so on.)

This is a bit more direct though. I feel like a way to counteracting this is to just grep everything for a user password before releasing a build. That's probably how they found it. Or better yet, use a password hash... like you are supposed to.

So since my Mac Mini came w/Lion on it, I have never used the original File Vault, so I'm fine. Good to know. Looks like, if possible, the best answer is to be upgraded to Lion and make sure evrything is encrypted w/FV2. Naturally this answer won't work for unsupported systems or anything PPC.

Actually, this particular bug is only present in the latest version of Lion.

This won't affect many people, but it still proves that Apple has to wake up. Soon. Someone (or more than one) is sleeping at the wheel here, no doubt.

This is just shameful for *any* company. For a company like Apple that could throw money at that problem at will, or just drown the problem in money, even more. I would expect some heads to roll around the place very soon, really.

Apple needs to go back to the development department responsible, go through the versioning logs, and find the person(s) responsible for this stupid security error. Really there is absolutely no excuse for any programmer to do this. If they simply 'forgot' to remove the offending code/compile switch, then they need to be punished appropriately. Simplest case - it will cost them some type of monetary fine, worst case - it will cost them their job.

Of course, if it's a simple error of the release process, like the build team missed a step, then they need to be reprimanded and the process needs to be scrutinized to minimize human error.

P.S. I talk from experience where my pay was docked with a fine if a security error was found in my code at a later time. You can be sure that after a couple of times, it didn't happen again.

Yes, it is a stupid error and it needs to be fixed. However, if one reads the article before jumping on the "Apple knows nothing about security" bandwagon, one might see that "While only users with admin or root access could access the passwords stored as plain text in the log files..."This somewhat reduces the severity of the problem. Yes, someone with admin or root access to the machine can find a lot of things on that machine, reset any user's password, even get any user's network password to the machine, so there is very little need to go find the debug log if one already has access to the system and root password.Still, it is feels so much better to be smug and act like you are some kind of security expert who could teach Apple a lesson or two.

This somewhat reduces the severity of the problem. Yes, someone with admin or root access to the machine can find a lot of things on that machine, reset any user's password, even get any user's network password to the machine, so there is very little need to go find the debug log if one already has access to the system and root password.

None of the things you mentioned would allow for access to encrypted data. This flaw does, however.

And it's not so much how few users this issue affects. What's important to take from this is that it's yet one more example of Apple's lax security practices. This is the sort of thing that got MS in trouble with XP pre-SP2. Microsoft has since learned to take security very seriously. It's apparent that Apple has not yet learned that lesson.

You do know this affects like 12 people, right? Only legacy home directory Filevault that no-one used if they were paying attention. Current FV 2.0 (the actual usable version) is not affected.

ah nice to know that. The article made it bigger again than it was.

Not correct. The article affects systems which use mobile home directories as commonly used in schools and businesses where computers have multiple users. It is a *big* problem in academic computing.

++

this affects every school / university or organization that mounts home directories from a server... IE this is actually a much bigger bug than most sites are letting on. Storing passwords plain text is just BAD.

Now add in some other scenarios like you are building a master image, and during that process a network admin login accesses some mounted folders to copy down data... this information could now be on a master image that you are deploying to your network... Kind of scary stuff there... Especially for really large deployments..

In the Novell mailing list where the problem was originally highlighted they've already tried (on 4/27) the next minor beta version of OSX (10.7.4) and the problem seems to have already been fixed there:

This may shock some, but FileVault is not secure. OMG but it's encrypted. Yeah, not secure at all. Until Apple impliments full disc encryption (see hell freezes over) it is not secure.

If you want to know why it's not secure, or why full disc encryption is never on the way may I point you to any support forum for any full disc encryption product. Short answer: people forget passwords.

Ok so admins can see clear text passwords, and those same admins can just log over as you already. No password needed. So, outside of some malware angle, and embarrassment. This is kinda news maybe?

This may shock some, but FileVault is not secure. OMG but it's encrypted. Yeah, not secure at all. Until Apple impliments full disc encryption (see hell freezes over) it is not secure.

If you want to know why it's not secure, or why full disc encryption is never on the way may I point you to any support forum for any full disc encryption product. Short answer: people forget passwords.

Ok so admins can see clear text passwords, and those same admins can just log over as you already. No password needed. So, outside of some malware angle, and embarrassment. This is kinda news maybe?

FileVault2 is full disk encryption. Also, Apple has a solution for password forgetfulness, you can store a copy of the key with them if you'd prefer: http://support.apple.com/kb/HT4790

This may shock some, but FileVault is not secure. OMG but it's encrypted. Yeah, not secure at all. Until Apple impliments full disc encryption (see hell freezes over) it is not secure.

If you want to know why it's not secure, or why full disc encryption is never on the way may I point you to any support forum for any full disc encryption product. Short answer: people forget passwords.

Ok so admins can see clear text passwords, and those same admins can just log over as you already. No password needed. So, outside of some malware angle, and embarrassment. This is kinda news maybe?

FileVault2 is full disk encryption. Also, Apple has a solution for password forgetfulness, you can store a copy of the key with them if you'd prefer: http://support.apple.com/kb/HT4790

I stand corrected sir, and ty. I'll leave the post, as if you're not using full disc encryption it's still not secure.

Apple needs to go back to the development department responsible, go through the versioning logs, and find the person(s) responsible for this stupid security error. Really there is absolutely no excuse for any programmer to do this. If they simply 'forgot' to remove the offending code/compile switch, then they need to be punished appropriately. Simplest case - it will cost them some type of monetary fine, worst case - it will cost them their job.

Of course, if it's a simple error of the release process, like the build team missed a step, then they need to be reprimanded and the process needs to be scrutinized to minimize human error.

P.S. I talk from experience where my pay was docked with a fine if a security error was found in my code at a later time. You can be sure that after a couple of times, it didn't happen again.

What role did the QC or QA team play, in the position you held? In my experience, that's where the rubber hit the road. Any mistake could creep in while writing code and propping doors open to better move through the code. Not to let the programmer off the hook (as if they'd allow that!) but it's the second or third pairs of eyes, who haven't been coding, but who sit down to the code, fresh, that should catch this.

..."While only users with admin or root access could access the passwords stored as plain text in the log files..."This somewhat reduces the severity of the problem. Yes, someone with admin or root access to the machine can find a lot of things on that machine, reset any user's password, even get any user's network password to the machine, ...

I'm glad you wrote it like this, as it's an excellent illustration of the value of creating sub-user accounts, which don't have Admin-level access, for daily use.

Yes, it is a stupid error and it needs to be fixed. However, if one reads the article before jumping on the "Apple knows nothing about security" bandwagon, one might see that "While only users with admin or root access could access the passwords stored as plain text in the log files..."This somewhat reduces the severity of the problem. Yes, someone with admin or root access to the machine can find a lot of things on that machine, reset any user's password, even get any user's network password to the machine, so there is very little need to go find the debug log if one already has access to the system and root password.Still, it is feels so much better to be smug and act like you are some kind of security expert who could teach Apple a lesson or two.

i think another issue here is the use of ASL, the subsystem that creates databases of the logs and stores them for some time in another folder. There doesn't seem to be a straightforward way of deleting the current folder and making Lion regenerate the databases, so the passwords could live on in binary for a while.

Yes, it is a stupid error and it needs to be fixed. However, if one reads the article before jumping on the "Apple knows nothing about security" bandwagon, one might see that "While only users with admin or root access could access the passwords stored as plain text in the log files..."This somewhat reduces the severity of the problem. Yes, someone with admin or root access to the machine can find a lot of things on that machine, reset any user's password, even get any user's network password to the machine, so there is very little need to go find the debug log if one already has access to the system and root password.Still, it is feels so much better to be smug and act like you are some kind of security expert who could teach Apple a lesson or two.

Considering the number of possible unknown zero day attacks or root escalation bugs one should never think its OK to have passwords stored in a log file in plain text. If that is your view of security then I don't think anything that anyone says hear would have an impact on you...

Why would you ever want the possibility of having anyone have access to your password, ever... Also considering it takes about 10 seconds to reset the local admin password on an OSx machine, and about the same amount of time to get into firewire disk mode - this is a serious issue. Most universities for instance have no issues with faculty logging into lab computers... Now any student with physical access to the lab machine can also snag anyones password just but putting the machine in target disk mode...

I read a report recently by Sophos which indicated that due to repeated attempts to improve Windows (7) security it actually is more secure than OS X.

And if you read it on the Internet, it must be true. Yeah, right...

Actually, it is right. And it's been right since long before Win 7. Apple just hasn't paid that much attention to security. Until now, they haven't had to as there were so few (relatively) Macs in comparison to Windows (even post-XP*) that Macs just weren't that rich a target.

*XP in its time was also a pretty secure OS. But XP's time was a decade ago, and has been well and truly over since at least 2007. Hard to expect a decade+ old obsolete OS to be up to par when it should be out to pasture.

This is a bit more direct though. I feel like a way to counteracting this is to just grep everything for a user password before releasing a build. That's probably how they found it. Or better yet, use a password hash... like you are supposed to.

This may shock some, but FileVault is not secure. OMG but it's encrypted. Yeah, not secure at all. Until Apple impliments full disc encryption (see hell freezes over) it is not secure.

If you want to know why it's not secure, or why full disc encryption is never on the way may I point you to any support forum for any full disc encryption product. Short answer: people forget passwords.

Ok so admins can see clear text passwords, and those same admins can just log over as you already. No password needed. So, outside of some malware angle, and embarrassment. This is kinda news maybe?

Filevault 2 is full disc encryption, introduced with Lion. So hell froze over July 20 of last year? Were there unseasonable lows when it was announced?

Filevault also had a reputation for eating home directories, and stored your keys insecurely. AFAIK, there are no known issues with Filevault 2.

You do know this affects like 12 people, right? Only legacy home directory Filevault that no-one used if they were paying attention. Current FV 2.0 (the actual usable version) is not affected.

ah nice to know that. The article made it bigger again than it was.

Not correct. The article affects systems which use mobile home directories as commonly used in schools and businesses where computers have multiple users. It is a *big* problem in academic computing.

++

this affects every school / university or organization that mounts home directories from a server... IE this is actually a much bigger bug than most sites are letting on. Storing passwords plain text is just BAD.

Now add in some other scenarios like you are building a master image, and during that process a network admin login accesses some mounted folders to copy down data... this information could now be on a master image that you are deploying to your network... Kind of scary stuff there... Especially for really large deployments..

This only seems to affect AFP mounted home directories. Other AFP mounts don't do the logging, nor do other filesystems. AFP is pretty Apple-specific, so I'd bet there are very few organizations serving AFP shares as home directories.