Apple Security Flaw, not just FileVault users!

[Kev]

http://www.zdnet.com/blog/security/apple-security-blunder-exposes-lion-login-passwords-in-clear-text/11963

This articles and others reference how it may affect multiple different configurations, even ones that have never had FileVault enabled.

I have confirmed in my environment that our 10.7.3 users with mobile accounts, bound to Active Directory, have this issue occurring on their machine.

Our users that are using network accounts with local home folders do not experience the issue. Our users that are using pure local accounts & home folders do not experience the issue. None of my machines that use pure network home folders have been upgraded so I have nothing to confirm or deny in that situation.

To check for the string of data in the log file, you can simply run the following terminal command:

grep password /var/log/secure.log

If your log file has rolled over you will have .0.bz2, etc. In my experience I was able to find it in the current log file for my users, but your experience may vary.

To "fix" this problem for now, I have a policy running that executes a script that runs the following three commands:

rm /var/log/secure.log

ln -s /dev/null /var/log/secure.log

rm /var/log/secure.log.*.*

This will remove the log files, effectively stop the machine from logging to the secure.log and remove previous versions of the log file.

This isn't the best solution, but we cannot tolerate passwords on machines in clear text. I assume nobody else would choose to do so either.

[nkalister]

i'm using AD with mobile accounts under 10.7.3, no passwords are present in my secure.log or any of it's archives. Kev- are you creating mobile accounts, or syncing home directories to a network share? I'm creating mobile accounts with local home directories.

[tlarkin]

Hey Everyone,

I saw this over the weekend and tried to verify it on my end. I was unable to verify this as an actual security flaw. However, my test AD account on my laptop has a local home folder and is also a mobile account. Delving further into this flaw, it seems to be specific. If your user mounts a home folder after login, then the flaw is present. I don't think mobile homes are affected since the home folder is actually local, and just syncs with the network home folder.

Reading through some mailing list posts on this I think that is the case. I am unable to verify that at the moment because I don't have that set up currently at my finger tips.

So, this flaw may not really affect you depending on your environment. If someone is using network homes which mount after login could you please verify?

Thanks,
Tom

[Kev]

The users that are affected in our environment are technically "Mobile Accounts".

However, we do no syncing at all, so in practice as it relates to the user folder, this is really a local home folder on the machines in question. The benefit of this on the portables for our teachers is that their AD credentials get cached locally. That way they can use AD credentials on their laptop, w/o the need for AD to be open to the outside world to make this happen. We do not do any syncing because we are CrashPlan users and it greatly reduces the network traffic by not syncing the data.

I also read someone having the issue with pure network home folders, but was not able to replicate that in the testing that I have done since my previous post. With no word from Apple, it is hard to say what scenarios do have issues and which ones do not.

It is definitely a good idea for everyone to check though.

[Kev]

In my haste, I did have a small part of that written poorly w/o the proper verbiage in there. I just made the edits that I noticed, hopefully it is more clear.

[Kev]

FYI: I have been able to recreate this issue on client Macs that are running 10.7.3, with AD accounts, and network home folders.

[jarednichols]

With FV1 encryption, yes?

[Kev]

No. None of these users have ever been configured to use FileVault on any machine on our campus.

[jarednichols]

Interesting.

[rtrouton]

It looks like the password issue is tied to the process that mounts home directories using a URL. (In FileVault 1's case, this may be popping up because the encrypted home folder is stored on an encrypted disk image, which needs to mount.) So, if you've got home folders mounting from another volume, you're probably going to see this issue:

Based on this assumption, here's who should have the issue:

1. 10.7.x Macs that automount a network home directory

This would affect the following scenarios:

A. Macs using network homes instead of local homes
B. Macs with mobile homes that sync with a network home

1. 10.7.x Macs that use FileVault 1

If your Macs don't fall into those categories, you're probably not seeing this issue. If your Macs do, check your logs.

[rockpapergoat]

if anyone's willing to test this (i haven't), here's a possible patch:

https://gist.github.com/2635697

[Kev · Accepted solution]

Here is the official word on the resolution from Apple...

OS X Lion v10.7.4 and Security Update 2012-002 Login Window Available for: OS X Lion v10.7.3, OS X Lion Server v10.7.3 Impact: Remote admins and persons with physical access to the system may obtain account information Description: An issue existed in the handling of network account logins. The login process recorded sensitive information in the system log, where other users of the system could read it. The sensitive information may persist in saved logs after installation of this update. This issue only affects systems running OS X Lion v10.7.3 with users of Legacy File Vault and/or networked home directories. See http://support.apple.com/kb/TS4272 for more information about how to securely remove any remaining records.