Lion Legacy Filevault WHOOPS

Question

Level 1

14 points

Lion Legacy Filevault WHOOPS

The following describes a serious Lion security flaw & asks how to make Apple aware of it...

When Lion mounts a legacy FileVault sparse bundle at user login, the system logs the following to /var/log/secure.log (hostname and actual password changed for security reasons):

Apr 11 19:39:35 hostname authorizationhost[1240]: DEBUGLOG | -[HomeDirMounter mountEncryptedHomeWithURL:attributes:dirPath:username:] | about to call DIHLFVMount. urlAttribute = /Users/.username/username.sparsebundle, password = password-here-in-plain-text, mountPointParent = /Users, homeDirPath going to the DIHLFVMount call = /Users/username

Lion should not be writing the username and password to disk! This is a serious security problem that renders an encrypted legacy FileVault useless because it makes the password available to anyone that can read the secure.log file.

How does one write a problem ticket to Apple to make them aware of this?

Lion OS-OTHER, Mac OS X (10.7.3)

Posted on Apr 12, 2012 5:23 PM

Reply

Answer 1

Top-ranking reply

Ashka

Level 4

3,885 points

Apr 12, 2012 5:27 PM in response to jlbmacuser

For a start:

http://www.apple.com/feedback/macosx.html

Reply

Answer 2

jlbmacuser Author

Level 1

14 points

Apr 12, 2012 5:34 PM in response to Ashka

Thanks, I submitted a bug report to Apple.

Reply

Answer 3

May 2, 2012 7:47 AM in response to jlbmacuser

This is really severe!

I have removed the file and pointed symlink to null device - this prevents writing anything to the file (at the cost of losing other security related information from this log file).

In case anybody wanted to do the same here's what you need to paste to the Terminal.app:

f=/var/log/secure.log && sudo rm $f && sudo ln -s /dev/null $f

and type your password.

(not sure, but sudo only works if you have password set and you're on an admin account)

Reply

Answer 4

jlbmacuser Author

Level 1

14 points

May 2, 2012 9:41 AM in response to toulouse15072

Yea, that'll do the trick OK but is severe indeed. Perhaps a Perl or sed script that runs with root privelege could be scheduled periodically to remove the offending material in secure.log??? Better yet, have it trigger upon a mount of a sparse bundled home folder. I don't know how to best handle such, as I don't have a root account enabled on my system. Is a root account needed to write scripts with root privelege or is there another way to do it with Launchd or something.

Reply