Flaw in macOS 'Quick Look' could reveal encrypted data
Quick Look is a marquee feature Mac users rely on to easily preview files without opening a dedicated app, but the years-old tool could potentially reveal sensitive information on encrypted drives.
![](https://apple.insidercdn.com/gallery/26482-37726-180618-QuickLook-l.jpg)
The security hole, which has assumedly been present in Quick Look since the feature rolled out more than a decade ago, was detailed earlier this month in a blog post by security researcher Wojciech Regula. Patrick Wardle, with Regula's assistance, provided an in-depth explanation of the flaw in a blog entry last week that was picked up by The Hacker News on Monday.
As Regula notes, Apple's Quick Look mechanism generates and caches thumbnails of files, images, folders and other data for fast and easy access by macOS. This allows Mac users to quickly preview said information with the tap of the space bar. Instead of relying on a dedicated app, such as Acrobat for PDFs, macOS is able to provide a "quick look" at the file using OS assets.
The problem, which was initially discussed some eight years ago, is Quick Look's file handling practices. Apple's feature stores thumbnail caches on an unencrypted drive, meaning snippets of originating files, even those contained in encrypted containers, can be exposed to those who know where to look.
"This means that all photos that you have previewed using space (or QuickLook cached them independently) are stored in that directory as a miniature and its path," Regula writes.
To verify his claims, Regula created a proof of concept in which two images were saved in two separate encrypted containers, one created with VeraCrypt and another with macOS Encrypted HFS+/APFS. The researcher was able to find both images and their paths with a simple command, which in turn granted access to a miniature version of the original files.
Wardle adds that Quick Look's caching function extends to attached USB drives, with thumbnails stored on the host computer's boot drive. He further argued that while the Quick Look flaw does not reveal the entire contents of a given file, what it does provide could prove useful to nefarious actors or law enforcement agencies.
That said, it would be relatively simple for Apple to patch the issue. As Wardle notes, Apple could relegate Quick Look previews to files located outside encrypted containers or, alternatively, flush thumbnail caches when a volume is unmounted.
Without an official fix, users concerned about exposing potentially sensitive data can manually delete a Quick Look cache when a container is unmounted by using the
![](https://apple.insidercdn.com/gallery/26482-37726-180618-QuickLook-l.jpg)
The security hole, which has assumedly been present in Quick Look since the feature rolled out more than a decade ago, was detailed earlier this month in a blog post by security researcher Wojciech Regula. Patrick Wardle, with Regula's assistance, provided an in-depth explanation of the flaw in a blog entry last week that was picked up by The Hacker News on Monday.
As Regula notes, Apple's Quick Look mechanism generates and caches thumbnails of files, images, folders and other data for fast and easy access by macOS. This allows Mac users to quickly preview said information with the tap of the space bar. Instead of relying on a dedicated app, such as Acrobat for PDFs, macOS is able to provide a "quick look" at the file using OS assets.
The problem, which was initially discussed some eight years ago, is Quick Look's file handling practices. Apple's feature stores thumbnail caches on an unencrypted drive, meaning snippets of originating files, even those contained in encrypted containers, can be exposed to those who know where to look.
"This means that all photos that you have previewed using space (or QuickLook cached them independently) are stored in that directory as a miniature and its path," Regula writes.
To verify his claims, Regula created a proof of concept in which two images were saved in two separate encrypted containers, one created with VeraCrypt and another with macOS Encrypted HFS+/APFS. The researcher was able to find both images and their paths with a simple command, which in turn granted access to a miniature version of the original files.
Wardle adds that Quick Look's caching function extends to attached USB drives, with thumbnails stored on the host computer's boot drive. He further argued that while the Quick Look flaw does not reveal the entire contents of a given file, what it does provide could prove useful to nefarious actors or law enforcement agencies.
That said, it would be relatively simple for Apple to patch the issue. As Wardle notes, Apple could relegate Quick Look previews to files located outside encrypted containers or, alternatively, flush thumbnail caches when a volume is unmounted.
Without an official fix, users concerned about exposing potentially sensitive data can manually delete a Quick Look cache when a container is unmounted by using the
qlmanage
utility.
Comments
Should this one get flaw of the year, or flaw of the decade?
(I always kind of wondered how well behaved things like Spotlight and QuickLook were when it came to their caching/indexing... now we know.)
Bravo security researcher!
You have to jump onto anything to complain about Apple, right?
"Flaw of the decade"? Give me a break!
Not as bad as the ‘zero password root user login’ bug from earlier. Not as bad by far.
https://az4n6.blogspot.com/2016/10/quicklook-thumbnailsdata-parser.html
For external drives and volumes it makes sense to put caches on the boot drive because it avoids running out of space on the external and the system can clean them up when not needed. They probably don't wipe them because it looks like they put all references for every drive in the same cache so wiping them out would mean wiping the entire cache, including the boot drive. Perhaps they could have a separate cache per drive and wipe the ones for mounted drives on unmounting or on detecting the drive has been unmounted for a while.
The cache can be found using apps like DiskWave ( https://diskwave.barthe.ph ) in the /private/var folder. I have cleaned it a few times manually when running low on disk space due to it using a lot of space, sometimes over 1GB. The reset command is pretty simple:
qlmanage -r cache
It doesn't specify a drive to wipe so this wipes the entire cache.
This cache is also used for the thumbnails that are generated when you go into icon view. If you scroll a large list of photos in icon view, it creates quite a large cache of the thumbnails. This saves wear on an SSD as it doesn't need to write them each time. The cache is only really useful for large photos and for hard drives. SSDs are so fast now (~2-3GB/s) that the cache isn't needed in a lot of cases, it can generate the icons on the fly and store some in RAM.
I'm not sure if Apple will fix this by wiping the cache as it means wasting CPU/GPU rebuilding them. For photographers, this could waste battery life when they browse images on external drives. Apple's catch-all seems to be the full disk encryption. The Mac boot drive is encrypted so everyone has that layer of protection by default. Perhaps there can be command-line options for the QuickLook cache. I'd quite like a maximum size option because sometimes it wastes a lot of space but there can be options to reset the cache regularly or when a drive is unmounted and options to disable the cache entirely or only for mounted volumes, maybe even an option to have the cache encrypted where the user sets a password like how you can encrypt iTunes backups.
For now the user just needs to reset the cache now and again and this can be made to happen daily if needed. Some cleanup tasks on the Mac happen at startup but reboots are rarely needed so some caches stick around for a long time.
Another potential security issue is the console log. If QuickLook has a problem generating caches for media, it gets logged in the console. Sometimes that logs large amounts of sensitive data in multiple logs. This can be cut down by changing the log settings to not write warnings to disk but the default setting stores the data.
From memory, QL cache was designed and written before FileVault. So the QL cache and external drives were all assumed to be unencrypted - all good. And (again from memory) FileVault encryption initially was only available on the main drive (without command line hacks). Again - the security on the QL cache and the original files was the same or better.
If the QL cache is on an encrypted drive and the data is on a different encrypted drive - the choice is much more difficult. You can’t equate encryption. One key may be secure and the other insecure (taped to the back of the laptop). Best practice would be not to cache in this case.
As for deleting the cache, they should probably do that after a time period. Configurable in the UI or the Terminal app.
Don't you ever get tired of writing those crappy comments?
Well, unless I'm misunderstanding what happened, it's about as legitimate of an oops as Twitter's writing passwords into a plain-text file.
As I said previously, I've always kind of wondered what happens when documents on encrypted drives and such get accessed in terms of caching, Spotlight, recently opened files, or stuff like this. Some I know you can set and such, but the very fact that there are services building these indexes are all chances for things to go wrong.
Yea, it rather new behavior for me, and I'm not happy about doing it either. I used to enjoy praising Apple for a job well-done and recommending them to all my clients, friends, etc.
re: flaw of the decade - maybe a bit of hyperbole, but can you think of a bigger one off-hand?
Possibly, though you'd have had to stumble across the password one in the first place under the right conditions for a narrow time period. For this one, you'd just have to know it existed and have physical access... maybe even to TimeMachine backups?
Also, it needs a reboot to do it.
it it seems like it should be a pretty easy fix, and to use it you need physical access to the machine, the actual impact is pretty minimal.
I think this is more serious for a couple of reasons.
First, someone working on QuickLook should have realized this... it's a dead-simple, dead-stupid kind of problem. Secure things should stay secure, not get written out into non-secure things. It makes one wonder how many other aspects of the OS are like this (as someone already mentioned, logging). It shows a lack of understanding and care about security.
At least the password issue was pretty obscure and one can imagine the kind of coding mistake that surfaced it. This, however, was a bad design from the start and then careless oversight as encryption became the norm. This is isn't some glitch that surfaced.
Second, If someone has access to the computer, unless cleared, this is now a history of external storage devices, files, file-contents, etc. whether encrypted or not. Every computer isn't necessarily under the control of a sole-person with FileVault running, etc.
There is also no way to patch this. Anyone with access to a system or unencrypted backup of a system could go back through, now, and find even documents from external storage, servers, etc. that are no longer part of the file system or on the machine.... even if they were encrypted.
I suppose Apple might trigger clearing this cache with their next update, and ultimately fix the problem going forward. But, there is a lot of history now out there in the wild.
But if you have an attachable encrypted drive, you expect a different behavior. E.g no cache or a hidden cache on the encrypted drive.
We have build ourself an encrypted Finder app and there are thumbnails and previews too. Our App SimpleumSafe does not have this vulnerability, because we have a different cache design and our caches are encrypted. So this can be easily done by Apple too.
We have seen lot of "easy to use" features in the past, like automatically open file downloaded in Safari, which isn't a good idea too. Apple has non technical people in mind when designing the UI, but today there are more and more attacks and Apple has more clearly to show what settings are for "easy to use" vs. "security".
We have built a free security advisor to start that work. SimpleumCheck.
Hopefully Apple awakes, because this a real leak for people who work with sensitive data.