Flaw in macOS 'Quick Look' could reveal encrypted data

Posted:
in macOS
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.




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.
«1

Comments

  • Reply 1 of 21
    nunzynunzy Posts: 662member
    Apple can Just patch this. All software has bugs. Apple builds in security from the ground up.
  • Reply 2 of 21
    A name for this siteA name for this site Posts: 3unconfirmed, member
    Space bar always seemed like a bad idea. 
  • Reply 3 of 21
    cgWerkscgWerks Posts: 1,609member
    Nice.

    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.)
    edited June 19
  • Reply 4 of 21
    rob53rob53 Posts: 1,903member
    Complain all you want but had anyone else noticed it over the years? If not, then I doubt it was ever used. If it was I’m sure someone would have blabbed about it before this. Of course the researcher didn’t include the command to find the files. 
    williamlondonlamboaudi4chabigjmey267jony0
  • Reply 5 of 21
    A legitimate oops, and easily fixed.

    Bravo security researcher! 
  • Reply 6 of 21
    cgWerks said:
    Nice.

    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.)

    You have to jump onto anything to complain about Apple, right?

    "Flaw of the decade"? Give me a break!

    lamboaudi4jmey267
  • Reply 7 of 21
    It’s a manageable bug for the time being. You still need to be an authenticated user I assume (logging on as a different user would not reveal the cache data)? 
    Not as bad as the ‘zero password root user login’ bug from earlier. Not as bad by far.
    macplusplus
  • Reply 8 of 21
    MarvinMarvin Posts: 14,178moderator
    It’s a manageable bug for the time being. You still need to be an authenticated user I assume (logging on as a different user would not reveal the cache data)? 
    Not as bad as the ‘zero password root user login’ bug from earlier. Not as bad by far.
    Yes you'd need access to the boot drive, which is by default encrypted. It also looks like you'd need custom parsing tools to retrieve the raw data:

    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.
    edited June 19 Alex1NarthurbacgWerks
  • Reply 9 of 21
    If the cache is on an unencrypted drive, then it shouldn’t cache things from encrypted drives. Full stop. That’s a serious security faux pas. 

    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.
    asdasdwilliamlondoncgWerks
  • Reply 10 of 21
    asdasdasdasd Posts: 5,102member
    It’s a manageable bug for the time being. You still need to be an authenticated user I assume (logging on as a different user would not reveal the cache data)? 
    Not as bad as the ‘zero password root user login’ bug from earlier. Not as bad by far.
    No real issue here except for the encrypted data on the USB or external drive ( that is an issue). Its true that they logged in user can see the quicklook data, but the logged in user can also see the real data. 

    As for deleting the cache, they should probably do that after a time period. Configurable in the UI or the Terminal app. 
    edited June 19 chabig
  • Reply 11 of 21
    chabigchabig Posts: 620member
    asdasd said:

    No real issue here except for the encrypted data on the USB or external drive ( that is an issue). Its true that they logged in user can see the quicklook data, but the logged in user can also see the real data. 
    Yeah. On an encrypted drive (we all use Filevault 2, right?) only an authorized user could see this. So it's not a flaw that exposes data to hackers. It's a flaw that exposes data to other authorized users.
  • Reply 12 of 21
    IreneWIreneW Posts: 110member
    nunzy said:
    Apple builds in security from the ground up.
    Except when they don't. Like in this case.

    Don't you ever get tired of writing those crappy comments?
  • Reply 13 of 21
    netroxnetrox Posts: 640member
    If it was known for a decade, why was it never fixed or patched? Hmmm. 
  • Reply 14 of 21
    JonmatJonmat Posts: 24member
    netrox said:
    If it was known for a decade, why was it never fixed or patched? Hmmm. 
    That´s the point everybody is neglecting to adress.

    There are few valid arguments as it stands:

    1 - They forgot about it
    2 - It is not easy to adress
    3 - Tradeoff beween usability and security
    4 - Since user access is implied, they thought it wouldn´t be that big of a deal
    5 - It is by design

    All bad.

    1 - It´s unlikely, given the detail they are know for. It would mean they don´t take security serious enough.
    2 - Not being easy is not a valid argument if they preach about security. Same as number 1.
    3 - Would have been fixed by now. It would mean they preach a false sense of security.
    4 - This would mean they dont get security.
    5 - It would mean they lie about security.
    edited June 19 cgWerksavon b7
  • Reply 15 of 21
    rmfpdxrmfpdx Posts: 16member
    Easy solution - from linked article: just run "qlmanage -r cache" - cache cleared.
  • Reply 16 of 21
    cgWerkscgWerks Posts: 1,609member
    rob53 said:
    Complain all you want but had anyone else noticed it over the years? If not, then I doubt it was ever used. If it was I’m sure someone would have blabbed about it before this. Of course the researcher didn’t include the command to find the files. 
    I looks like he was just browsing the database file?

    A legitimate oops, and easily fixed.
    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.

    bestkeptsecret said:You have to jump onto anything to complain about Apple, right?

    "Flaw of the decade"? Give me a break!

    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?

    Not as bad as the ‘zero password root user login’ bug from earlier. Not as bad by far.
    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?

    Marvin said:
    The reset command is pretty simple:

    qlmanage -r cache

    It doesn't specify a drive to wipe so this wipes the entire cache.
    Also, it needs a reboot to do it.
  • Reply 17 of 21
    MarvinMarvin Posts: 14,178moderator
    cgWerks said:
    Marvin said:
    The reset command is pretty simple:

    qlmanage -r cache

    It doesn't specify a drive to wipe so this wipes the entire cache.
    Also, it needs a reboot to do it.
    No reboot required if you use qlmanage -r cache. The linked article originally suggested using qlmanage -r, which needs a reboot but the longer command zeroes the cache when the command is run. You can test it if you open the cache folder then open a large photo folder, put it into icon view and scroll down it. The thumbnails.data file will increase in size. Run the command and it will reset the file and the database.
    cgWerks
  • Reply 18 of 21
    MplsPMplsP Posts: 572member
    there seem to be a lot of alarmist claims here. This seems to be like a lot of security flaws discovers over the years in many different apps and OS’s. A feature/functionality is added, then a Security later is added afterwards and there’s a ‘back door’ of some sort that people didn’t notice because of the thousands of different ways they can exist. For those that don’t believe it’s existed all these years unnoticed, how many other security flaws in OSX, Windows, Flash, Intel chips, WiFi password protocols.... 

    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. 
  • Reply 19 of 21
    cgWerkscgWerks Posts: 1,609member
    Marvin said:
    No reboot required if you use qlmanage -r cache.
    Thanks!

    MplsP said:
    there seem to be a lot of alarmist claims here. This seems to be like a lot of security flaws discovers over the years in many different apps and OS’s. A feature/functionality is added, then a Security later is added afterwards and there’s a ‘back door’ of some sort that people didn’t notice because of the thousands of different ways they can exist. For those that don’t believe it’s existed all these years unnoticed, how many other security flaws in OSX, Windows, Flash, Intel chips, WiFi password protocols.... 

    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.
  • Reply 20 of 21
    johsimjohsim Posts: 1member
    I think Apple has improved the balance of "easy of use" and security over the last years and a spacebar click to get a preview is something we all like.
    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.
    cgWerks
Sign In or Register to comment.