|
||
|
15 May 2012. Apple offers fix: https://support.apple.com/kb/TS4272 But note this caution about Filevault 2 (FV2): https://discussions.apple.com/thread/3940600?tstart=0 softwater 5 May 2012 Apple Legacy Filevault Hole
Date: Fri, 4 May 2012 20:40:07 -0400 As someone said here recently, carefully built crypto has a unfortunate tendency to consist of three thick impregnable walls and a picket fence in the back with the gate left open. That seems to have happened to Apple's older ("legacy") Filevault in the current release of MacOX Lion (10.7.3).... something intended to protect sensitive information stored on laptops by providing for encrypted user home directories contained in an encrypted file system mounted on top of the user's home directory. Someone, for some unknown reason, turned on a debug switch (DEBUGLOG) in the current released version of MacOS Lion 10.7.3 that causes the authorizationhost process's HomeDirMounter DIHLFVMount to log in *PLAIN TEXT* in a system wide logfile readible by anyone with root or admin access the login password of the user of an encrypted home directory tree ("legacy Filevault"). The log in question is kept by default for several weeks... Thus anyone who can read files accessible to group admin can discover the login passwords of any users of legacy (pre LION) Filevault home directories who have logged in since the upgrade to 10.7.3 in early February 2012. This is worse than it seems, since the 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. This would allow someone to break into encrypted partitions on machines they did not have any idea of any login passwords for. One can partially protect oneself against the firewire disk and recovery partition attacks by using Filevault 2 (whole disk encryption) which then requires one know at least one user login password before one can access files on the main partition of the disk. And one can provide further weaker protection by setting a firmware password which must be supplied before one can boot the recovery partition, external media, or enter firewire disk mode - though there is a standard technique for turning that off known to Apple field support ("genius bar") persons. But having the password logged in the clear in an admin readible file *COMPLETELY* breaks a security model - not uncommon in families - where different users of a particular machine are isolated from each other and cannot access each others files or login as each other with some degree of assurance of security. Granted, of course that someone able to alter executable code could plant keyloggers and the like... and break this ... but actually shipping product that does so without notice is disturbing. And for those who use Apple's easy backup tools ("Time Capsule"), it was possible to assume that those tools only wrote copies of the sparsebundle encrypted container for a Filevault legacy home directory to the backup media meaning that an unencrypted backup would still provide protection for the contained encrypted home directories... but with the password required to decrypt the sparebundles stored in the clear on the (unencrypted) backup that assumption is no longer true. One wonders why such a debug switch exists in shipped production code... clearly it could be invoked covertly in specific situations, this seems to be an example of someone turning it on for the entire release by accident. Nobody breaks encryption by climbing the high walls in front ... when the garden gate is open for millions of machines. This bug (LEA feature?) seems to have been introduced into MacOS Lion 10.7.3 early February 2012 and so far has not been corrected by any updates. --
Dave Emery N1PRE/AE, die[at]dieconsulting.com DIE Consulting, Weston, Mass
02493 _______________________________________________
cryptography mailing list
|