In the past 72 hours it has been discovered that there is a major security flaw in Mac OSX 10.7.3.
It deals specifically with the use of Legacy FileVault in OSX 10.7. Legacy FileVault is the older “Home Directory only” encryption used in Mac OSX 10.6.x and prior. Legacy FileVault would only be active in Mac OSX 10.7.x if you had enabled FileVault in 10.6.x (or prior), upgraded to 10.7, and then opted NOT to convert your old Home Directory only encryption to the newer Full Disk Encryption FileVault of 10.7. There is not an Apple Approved method or GUI to enable or create a new Legacy FileVault on 10.7.x.
HOWEVER… I produced a guide back on October of 2011 that outlined how to manually enable and create a new Legacy FileVault in Max OSX 10.7.x Lion (http://www.taborcg.com/2011/10/16/how-to-enable-legacy-filevault-on-mac-osx-10-7-lion/). As I started in the guide there are several reasons why Legacy FileVault might have an advantage over the new FileVault, including true security on multiuser systems and having good crypto security with Mac OSX 10.7 Lion running on non-approved hardware (i.e. Hackintosh OSX86)
The bug effects both use cases of Legacy FileVaults from upgrades AND manually created Legacy FileVaults using the aforementioned guide. The has only surfaced after the 10.7.3 update. It would appear that some bonehead at Apple left a debugging flag turned on that records both the username and password IN CLEAR TEXT to a log file whenever an encrypted Legacy FileVault disk is mounted. This does not appear to log the password when new Full Disk Encryption FileVault disks are mounted at boot time, and does not log when encrypted DMG files are mounted, only when Legacy FileVault disks are mounted at the point of user logon.
The username and password in clear text are stored int he log file: /var/log/secure.log (and it’s subsequent rolled over backups .bz2)
The easiest way to view and work with the file is via the terminal and elevating yourself to superuser (root) status.
From the terminal type:
sudo su –
and enter your password (assuming you are a user with administrative privileges)
Once you see the root# prompt, change directories to the system log location.
cd /var/log/
From here you can do an ls to view the files, or simply cat or nano the secure.log to view it.
nano ./secure.log
Look for one of the offending lines like:
May 4 23:41:56 Home-Mac-Pro authorizationhost[128]: DEBUGLOG | -[HomeDirMounter mountEncryptedHomeWithURL:attributes:dirPath:username:] | about to call DIHLFVMount. urlAttribute = /Users/.mckinleytabor/mckinleytabor.sparsebundle, password = mysupersecrettinfoilhatpasswordthatitwouldtakelikeamillionyearstobruteforceandnothisisnotit, mountPointParent = /Users, homeDirPath going to the DIHLFVMount call = /Users/mckinleytabor
Conversely, you can also do a Control-W in nano and just search for your password, if you are using Legacy FileVault and 10.7.3, it will be there.
(Just as an aside, it’s always odd to SEE my passwords written out. I (and you should) NEVER write down a password, so to me, my passwords are not words, they are elements of my imagination that correspond to muscle memory. My brain does not file them away as actual text or words. So to them written out is an oddly dissociative experience.)
The end of result of this debacle is that ANYONE with root permissions (i.e. any other user with Administrative rights) or anyone who physically extracts the harddrive and reads it with another computer, has easy access to the passwords.
WORD AROUND
Apple programers are going to need to stop dog paddling around in their corporate wall garden swimming pool full of $100 bills and fix this. But until then there is a quick and dirty way to be a bit safer. We can run a cron job to scrub the offending files off the system. It’s not perfect, but it will work. Doing this will remove your ability to refer to the secure.log file to diagnose any issues logged there, but to be honest prior to today, I have never had to use this file, so not having it is not a problem for me. Use with your own discretion.
Cron, for those of you who do not know, is the *nix way of running programs and scripts on a timmer. You can add a “cron job” with the following command, which will open a text editor.
crontab -e
In most cases this will only up the text editor vi (or vim). If you have never worked with cron, you should be looking at a blank page. You will need to add a line to this page, that will be the command and timings for the “cron job”. Vi is a very powerful text editor (which you should take the time to learn) but for our proposes today, you only need to know a few commands. When you want to type text into a document with vi you must first type “i” to start editing the file. (This is the command to insert text)
Enter the following line into vi:
* * * * * srm -frmz /var/log/secure.log* && ln -s /dev/null /var/log/secure.log
What does this line mean? The five space separated asterisks are the timing codes telling cron when to run the command. As you may now asterisks in *nix are short hand to mean “anything/everything” (which is why *nix can mean Unix or Linix). The first asterisk for the minute of the house, which in our case is EVERY minute of the hour. The second asterisk is the hour of the day, which in our case is EVERY hour of the day. The third asterisk is the day of the month, which in our case is EVERY day of the month. The four asterisk is month of the year, which in our case is EVERY month of the year. The fifth asterisk is day of the week, which in our case is EVERY day of the week. So in a nutshell, five asterisks mean to run the command every minute until the end of time.
The command is everything starting with “srm”. Srm is a *nix command meaning “secure remove”. Unlike the normal “rm” command which simply unlinks files, srm scrubs them off the disk so that they are highly unlikely to be recovered via forensic means. The “-frmz” switches tells srm to: Force the process even if there might be a lock on the file (“f”), Run Recursive so that it grabs any files in lower directories (“r”) (not strickly needed in our case, but better safe than sorry), Medium scrubbing of 7 US DOD random rewrites over the top of the files in question (“m”) and finally, Zero out the file location with 00000 (“z”). The final part of the command “/var/log/secure.log*” tells srm what files to scrub off the drive. In this case it will be the secure.log and any of it’s backed up .bz2 predecessors. PLEASE note that the file asterisk in the command is important, and that it’s placement at the end of the command WITHOUT any spaces before it is important. As I said, * is short hand for anything/everything. When the asterisk is attached to a file, like secure.log*, it means to get every file who’s name begins with secure.log. Putting a space between the secure.log and the * might result is some unwanted behavior, like scrubbing off the secure.log, and then every other file in the directory you are running srm from. Not good to scrub your entire drive if you happen to be sitting on the root (/) directory. 
The “&&” is again short hand for “also run this command”, a simple way to put to separate commands on the same line to be run consecutively. The next command is “ln” which in *nix allows us to “link” files. The switch “-s” means to Symbolically link the file (as apposed to a hard link, which is not possible with what we are about to do). The next two times are the files we are linking. In this case we are linking the systems /dev/null to /var/log/secure.log. The system file /dev/null is a *nix special file used when you want to transfer data into nothing (i.e. delete it). It’s a place that can be used in scripts to dump unwanted automatic data, or provide a filler when you are required to have something but want nothing (quite existential nihilistic isn’t it). Here because we are linking /var/log/secure.log to /dev/null, anytime the system tries to write out data to the file /var/log/secure.log, it goes “nowhere”, meaning it is never written onto the disk, it is never recorded.
Once you have entered the cronjob, type Esc twice to exit the editing mode of vi, then type the following line to save and exit vi:
:wq
(note the colin is important)
After less than 60 seconds you can do an ls -la command and all of the offending secure.log and secure.log.*.bz2 files will be gone, replaced by a file /var/log/secure.log pointing to /dev/null.
Optional
If you want to test the command PRIOR to running it in a cronjob, you can simply run:
srm -frmz /var/log/secure.log* && ln -s /dev/null /var/log/secure.log
From any command propt and it should scrub the log file off the system.
Into the Furture…
Some things to be concerned about.
- Apple released the 10.7.3 update on February 1, 2012. This means that this bug has been floating around for from 64 days. It was publicized within the last 3 days, but Apple still has their head in the sand and has not acknowledged the problem. It’s possible that this bug could have been exploited in the last 9 weeks. Remember the “FlashBack” Mac Virus has been active durning this time, and it did have root/administrative privileges. (Thought I want to stress that there has not been any confirmation that FlashBack was exploiting this bug, I only bring it up to illustrate that it COULD have exploited it.)
- If you are using TimeMachine or any other Full system backup, your /var/log/secure.log* files have been backed up and are floating around where ever. I suggest you start a hunt to find them and srm them out of existence.
- Now is a GREAT time to charge your password strategy (and again after the bug is fixed). If your password has been compromised, then changing it AFTER you build a job to srm the log files will help negate the breach.
- The combination of srm and ln in the cronjob is a belt a suspenders approach to the problem. (well, I guess you could say its a belt, suspenders, and jockstrap with cup approach). This is because I do not know how well the /dev/null -> /var/log/secure.log link will survive the automatic roll over of the logs, nor how it will survive any incremental updates from Apple. Because this is root running the cronjob it will be completely independent of the user. If for some reason the normal function of /var/log/secure.log and it’s roll overs is restored, the cronjob “should” kill it, scrub the files, and place the link back to /dev/null with the need for user intervention. I would advice that you wait 90 to 120 at the login screen each time you boot the system to allow for enough time for the script to do it’s job BEFORE you login. This way your password wil never be written to the disk, and the srm become redundant, but a safety catch.
- This is the long approach, if someone knows how to disable this debug flag, or turn off /var/log/secure.log logging altogether, I’m open to suggestions.
- Yes, if another user with admin/root privileges undoes your cronjob and removes your link to /dev/null, the system will go back to being broken. In very secure environments, I would respectfully submit that two users with admin/root rights on the same box is inherently insecure, but I’m not maganing your use case, so there may be a good reason for you needing it.
- According to some things I have read, this bug is fixed in the lastest developer build of Mac OSX 10.7.4 Lion. But we are a long way from that release, so maybe Apple will issue an interim patch. In the mean time add period checks to the log file to insure that clear text passwords
