Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.4: Be aware of a FileVault security issue with Mail.app System 10.4
The Drag to save Mail attachments in Terminal hint reveals a security hole in Mail.app for FileVault users. When you drag an email attachment from a Mail message window to a Finder window, a temporary file is created in the hidden directory /private -> var -> tmp -> folders.UID -> TemporaryItems -> com.apple.mail.drag, where UID is replaced by your numeric user ID. This copy of the attachment is not encrypted. The temporary file will be automatically deleted at the next startup, but anyone who has physical access to the machine before then can easily retrieve it. Even after the file is deleted, it may be recoverable with a low-level disk editor. This defeats the pupose of FileVault.

I confirmed that when you save an attachment by clicking the Save pop-up menu in the Mail message window that no temporary file is created. So anyone who uses FileVault security (or, like me, keeps their whole /Users directory on an encrypted disk image) should not drag attachments from a Mail window, if privacy of those attachments is a concern.
    •    
  • Currently 1.86 / 5
  You rated: 1 / 5 (7 votes cast)
 
[12,682 views]  

10.4: Be aware of a FileVault security issue with Mail.app | 9 comments | Create New Account
Click here to return to the '10.4: Be aware of a FileVault security issue with Mail.app' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: Be aware of a FileVault security issue with Mail.app
Authored by: momerath on Dec 22, '06 08:35:22AM
Yeah, I guess anything created in the /tmp directory is a "security hole" in the sense that it's unencrypted. Solution: ln -s /private/var/tmp/folders.UID ~/tmp?

[ Reply to This | # ]
10.4: Be aware of a FileVault security issue with Mail.app
Authored by: rparrish on Dec 22, '06 10:08:24AM

Can we assume the responsible thing was done, and this was also reported to Apple?



[ Reply to This | # ]
10.4: Be aware of a FileVault security issue with Mail.app
Authored by: rhowell on Dec 22, '06 10:13:21AM

When a Filevault user is logged in, his entire Home folder is unencrypted. Anyone with admin access can then read/write into his home folder.

The security hole would be the following (I can't check this right now): when a Filevault user logs out, the contents of his temporary folder are not securely erased.



[ Reply to This | # ]
10.4: Be aware of a FileVault security issue with Mail.app
Authored by: lincd0 on Dec 22, '06 01:52:13PM
When a Filevault user is logged in, his entire Home folder is unencrypted.

That's not correct. The home folder is stored on an encrypted disk image, and the contents are always encrypted on disk. When you open a file on such an image, the disk driver decrypts the data into RAM. It can leak out to disk in swap files, but in Tiger you have the option to encrypt the swap files as well.

Anyone with admin access can then read/write into his home folder.

That's beside the point. The purpose of encryption is prevent data theft by an attacker with physical access.

[ Reply to This | # ]

10.4: Be aware of a FileVault security issue with Mail.app
Authored by: lincd0 on Dec 22, '06 01:56:09PM

I'm the submitter of this hint. While I thank the site admins for publishing it, I'd like to point out that the incorrect pathname notation (with arrows in place of slashes) is theirs, not mine.

[ Reply to This | # ]

10.4: Be aware of a FileVault security issue with Mail.app
Authored by: bitwise on Dec 22, '06 11:49:26PM

Do you use filevault? I do. When a filevault user is logged in, one can ssh to the machine or otherwise login as another (admin) user and read (I believe write also via sudo) anything from the filevault user's home.

So, the fact that tmp files are present while logged in shouldn't be a huge concern assuming normal read/write protections since one can get at the user's home folder anyway.

Finally, if the os is smart enough to securely erase the tmp files when the user logs out and his home is again fully secure then that should be adequate.

I might be missing something here, but I think I agree with the commenter with whom you disagreed (;



[ Reply to This | # ]
10.4: Be aware of a FileVault security issue with Mail.app
Authored by: mantrid on Dec 23, '06 12:15:47PM

If a filevault user is logged in when the computer is stolen and power is cut off (or if it is stolen some time after sudden power loss while the user was logged in), the contents of their home folder will be inaccessible to the thief because of filevault. However, with sudden power loss, the tmp file will not have been deleted, and being outside of the filevault image, it will be freely accessible. This would only affect tmp files for attachments created during that session, but it's still an issue.

But even with a normal log out or shutdown, the tmp files are not erased securely (why would you think they were anyway?), so unencrypted pieces of any attachment dragged and dropped months in the past could still be floating around on the hard drive of a habitual drag and dropping filevault user, recoverable by any thief with the right tools. This danger was already mentioned in the hint. Performing an "Erase free space" operation would probably clear that up, but it might not have occurred to anyone that doing that would even be necessary without this hint.

If the problem doesn't affect you, fine (it doesn't affect me either), but don't downplay the issue. I'd say this is a good hint since it provides the service of making people that might be affected aware of the problem, and even provides a workaround (use "Save") to avoid the creation of the insecure tmp file in the first place.



[ Reply to This | # ]
Other consequences of FileVault only encrypting $HOME
Authored by: caitifty on Dec 29, '06 11:39:47AM

I use my mac laptop in a medical setting which requires the use of a mysql database containing sensitive medical information. Filevault only encrypts $HOME, and mysql by default stores data in /usr/local. The solution to this (and other security problems where software stores sensitive data outside $HOME) is to move the directory containing the actual data to somewhere inside $HOME and symlink back to where the software expects to find it. In my mysql example (and keep in mind this is specific to my exact version of mysql), this means:

sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
(to stop mysql before screwing with it..)

mkdir ~/sensitivedata

sudo mv /usr/local/mysql-standard-5.0.22-osx10.4-powerpc/data ~/sensitivedata/

sudo ln -s ~/sensitivedata/data/ /usr/local/mysql-standard-5.0.22-osx10.4-powerpc

sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
(to restart the server)

The other big pain from this is that setting mysql to automatically start on startup will no longer work - it'll try and start while the data files are still encrypted and fail. Easy enough to start it by hand (or your own script) after you're fully logged in, but still..



[ Reply to This | # ]
10.4: Be aware of a FileVault security issue with Mail.app
Authored by: romulis on Jan 11, '07 11:28:21AM

If you store the whole /Users directory in an encrypted disk image - how do you login? (serious question!)



[ Reply to This | # ]