X

Insignificant bug keeps encrypted disks unlocked after ejecting in OS X

While not the expected behavior, this bug is technically not a breach in security.

Topher Kessler MacFixIt Editor
Topher, an avid Mac user for the past 15 years, has been a contributing author to MacFixIt since the spring of 2008. One of his passions is troubleshooting Mac problems and making the best use of Macs and Apple hardware at home and in the workplace.
Topher Kessler
3 min read

Apple's CoreStorage disk encryption technology has a small bug that will keep a disk unlocked, even after it has been ejected from the system.

In OS X Lion, Apple introduced a drive management technology called CoreStorage. When enabled, CoreStorage will create a "logical volume group" out of one or more physical drive partitions, and then create usable "logical volumes" from this group to serve as storage for your system. This setup allows the logical volume to span multiple physical partitions (as is seen with Apple's Fusion Drive), and support features like encryption for Apple's FileVault 2.

According to the manual page for the OS X disk management command "diskutil" (the Terminal approach to disk management), when any logical volume is ejected, if it is encrypted then it should be set to a locked status, meaning that in order to access the volume again, you should be required to supply its password.

diskutil man page showing corestorage volume management
The diskutil manual page clearly states that ejecting an encrypted volume ought to "re-lock" it (click for larger view). Screenshot by Topher Kessler/CNET

However, currently this is not the case, and the bug results in the drive remaining unlocked. The only way to lock a drive again is to completely eject the logical volume group that hosts the logical volumes, instead of simply ejecting the volume itself.

What this translates to is if you eject an encrypted volume from your system but leave the device attached, then it can be remounted at any time without providing a password, as long as the system is not restarted. To see this in action, first enable Disk Utility's Debug menu and using it to show all volumes (including hidden and unmounted ones), and then do the following:

  1. Attach an encrypted drive to your Mac and supply the password when prompted.
  2. Open Disk Utility (with hidden partitions enabled), and underneath the drive you will see the mounted volumes along with other support volumes in dimmed text.
  3. Now eject the volume by dragging it to the Trash. Note that this will make the encrypted volume appear grayed out in Disk Utility, meaning it is unmounted and therefore unavailable, but not remove it from the system.

At this point, OS X claims the volume should require a password again when remounted; however, merely unmounting does not do that, and if you select it in Disk Utility and clicking the "mount" button in the toolbar, the volume will simply mount again without any password prompt. This will happen, be it in your account, or in that of another user on the system, so if you eject and log out, then another user may log in and be able to mount the drive in this manner.

Disk Utility in OS X
With Disk Utility set to view hidden partitions, you can select the unmounted and encrypted drive and simply click the Mount button to remount it without having to enter its password again. While not the expected behavior, this is technically not a breach in security (click for larger view). Screenshot by Topher Kessler/CNET

This issue appears to have been around since the introduction of FileVault 2 and CoreStorage in OS X. Although it provides a small potential breach of security, the scope of the concern here is actually quite limited and in truth is more a matter of perception.

For one, even though the drive can be remounted within another account, this is not really a security breach because of the default way in which OS X handles drives. When any drive is mounted, be it encrypted or standard, it will be available for access by all accounts on the system. Therefore, relying on the encryption locked status to secure a drive from other users is not a reliable means of security.

Additionally, this bug does not reveal any information about the encryption, and is also limited to the local system while the drive is still attached, so the drive's password and encryption keys are still secured with the current Mac it's being used with, and cannot be transferred for use with another system.

While at first this may seem concerning, this problem is more a matter of perception than a true security risk, and to some degree it can simply be seen as a lack of continuity between the behaviors seen and Apple's manual page. The bug appears to mainly be that performing an eject routine on a corestorage volume just unmounts the volume, leaving the volume group itself still attached and ready to be used, so ejecting really does not perform an eject at all.

Therefore, if desired, you can lock these drives again simply by unplugging them after ejecting (an action already done in most cases). Unplugging the drive will detach the CoreStorage logical volume group, clear any passwords and encryption keys stored in memory, and lock the drive.



Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.