Back to list
Fwd: [cryptography] Apple Legacy filevault barn door...
May 05 2012 07:48PM
Jeffrey Walton (noloader gmail com)
Interesting reading from the cryptography mailing list
---------- Forwarded message ----------
From: David I. Emery <die (at) dieconsulting (dot) com [email concealed]>
Date: Fri, May 4, 2012 at 8:40 PM
Subject: [cryptography] Apple Legacy filevault barn door...
To: cryptography (at) randombit (dot) net [email concealed]
Â Â Â Â 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
Â Â Â Â 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
Â Â Â Â 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
Â Â Â Â 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.
[ reply ]
Copyright 2010, SecurityFocus