15 May 2012. Apple offers fix:
But note this caution about Filevault 2 (FV2):
May 10, 2012 5:40 AM (in response to Patrick Barsby)
FV2 is highly secure, but there is 'hole' in the whole philosophy behind
it, which only applies if you have other users on your system and you give
them 'startup' permissions (i.e., they have their own password for FV2).
Once a user is given startup permissions, they can in fact read your entire
user home folder through Single User mode. This is a pretty obscure vulnerability
and only applies under the situation I just described. If you do have other
users on your system and you want your own home folder to remain out of their
reach, don't give them startup permissions. Alternatively, use Disk Utility
to locally encrypt sensitive folders in your own account.
5 May 2012
Apple Legacy Filevault Hole
Date: Fri, 4 May 2012 20:40:07 -0400
From: "David I. Emery" <die[at]dieconsulting.com>
Subject: [cryptography] Apple Legacy filevault barn door...
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
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
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
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole
celebration of what could have been, but wasn't and is not to be now either."
cryptography mailing list