macOS Breaks Your OpSec by Caching Data From Encrypted Hard Drives (bleepingcomputer.com) 140
Apple's macOS surreptitiously creates and caches thumbnails for images and other file types stored on password-protected / encrypted containers (hard drives, partitions), according to macOS security experts Wojciech Regula and Patrick Wardle. From a report: The problem is that these cached thumbnails are stored on non-encrypted hard drives, in a known location and can be easily retrieved by malware or forensics tools, revealing some of the content stored on encrypted containers. On macOS, these thumbnails are created by Finder and QuickLook. Finder is the default macOS file explorer app, similar to Windows Explorer. Whenever a user navigates to a new folder, Finder automatically loads icons for the files located in those folders. For images, these icons are gradually replaced by thumbnails that show a preview of the image at a small scale.
Does Windows Explorer do it differently, or Linux (Score:2)
I can understand the security concern about thumbnail data especially encrypted data.
But for other systems with the feature Including Windows and Some Linux file managers, Do they handle it differently?
Re: (Score:3)
Re: (Score:1)
So Windows's strategy doesn't work on CD-ROMs? Or if you plug a drive with no space left? It's not clear which behavior is actually better. Mac and Windows just made different trade-offs.
Re:Does Windows Explorer do it differently, or Lin (Score:4, Insightful)
Re: (Score:2)
Until Windows XP, yes, Windows Explorer stored images in the thumbs.db file inside the related folder.
Having all these thumbs.db files being held open by Explorer, though, led to common problems being unable to rename folders, etc., so since Windows Fista they have been stored in your %LocalAppData%\Microsoft\Windows\Explorer folder, i.e.: inside C:\Users\username\AppData\Local\...
Re: (Score:2, Insightful)
The difference is you can find out exactly what a Linux file manager does, while how MacOS works is a proprietary trade secret.
But RedHad sqandered that advantage with systemd and Gnome 3
Re:Here's a pwned 133t h4x0r link to the OS X kern (Score:5, Informative)
Which has nothing to do with this. The thumbnails are not created by the kernel but by the Finder, which is not open source.
Re: (Score:2)
You do know the entire OS isn't open source, right?
In particular, go ahead and show me the source for Finder.
Re: (Score:2)
You can move those back on the encrypted drive/folder with a simple link.
~/.cache/thumbnails -> ~/mnt/private/.thumbnails/
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Insightful)
~/.cache/thumbnails -> /dev/null
Re: (Score:1)
Or better, use some other file manager that doesn't do thumbnails. On linux, you have choice. This file manager or that one or 5 other alternatives. The distro default may use thumbnails, but if you're setting up encrypted volumes, you may also want to change to a different file manager.
Of course some people replace the file manager (or turn off thumbnails) for performance reasons anyway. Linux is all about choice. Set up a super secure workstation or a snappier workstation - optimize for whatever you like.
Re:Does Windows Explorer do it differently, or Lin (Score:4, Informative)
I can understand the security concern about thumbnail data especially encrypted data. But for other systems with the feature Including Windows and Some Linux file managers, Do they handle it differently?
On Windows it uses thumbs.db, a hidden system file located in each folder that has thumbnails cached (not all do if they don't contain documents or images that get preview thumbsnails). You can also turn thumbnail caching off in explorer settings or via group policy.
Re:Does Windows Explorer do it differently, or Lin (Score:4, Informative)
Windows creates the thumbnails in a subdirectory of the original, so it should also be encrypted (or maybe it doesn't anymore.) And I believe the index is per drive. At any rate, there is a checkbox for "turn off thumbnails" and "turn off indexing" on a drive.
Re: (Score:1)
Windows creates the thumbnails in a subdirectory of the original, so it should also be encrypted (or maybe it doesn't anymore.)
This is still the current behavior. A hidden thumbs.db file is created in the folder with the images.
While this approach has a few other annoyances related to it, at least the thumbs.db file is covered by the same permission inheritance and encryption policies as the original files.
One tends to see these files littered all over a remote file share, with the occasional permissions errors from multiple users with access to the folder but using the "creator owner" group that prevents updates to it.
Explorer al
Re: (Score:2)
On older MacOS operating systems, the Resource Fork, the predecessor to the .ds_store, would occasionally store the file's data.
Honestly, I wish we were still using Resource Forks for this kind of thing. They were elegant so long as the underlying file system understood WTF was going on. The rise of the Internet and PC-interoperability meant the rise of Binhex and other rarer arcane formats, but it really does seem like Apple decided to drop Resource Forks at precisely the time other file systems were coming around to support forked files and additions were being made to low-level tools to deal with them.
Now Mac UDF disks are filled
Re: Does Windows Explorer do it differently, or Li (Score:3)
All modern filesystems (HPFS+, NTFS, ext4) support metadata. The issue isn't with the filesystems, it's with the tools and apps built on top. Most importantly, each FS has its own way of reading/writing metadata, so no cross platform tools can readily take advantage.
Re: (Score:2)
All modern filesystems (HPFS+, NTFS, ext4) support metadata. The issue isn't with the filesystems, it's with the tools and apps built on top. Most importantly, each FS has its own way of reading/writing metadata, so no cross platform tools can readily take advantage.
For NTFS, Microsoft removed the capability to actually *use* the metadata as part of a Windows Explorer plug-in after Windows XP. Microsoft said they did this because it was a "resource drag" but that is a load of bullshit when we have SSDs and 64-bit systems.
Re: (Score:2)
This is still the current behavior. A hidden thumbs.db file is created in the folder with the images.
It's only current behaviour if you're still on Windows XP. Windows Vista and later store them in your %LocalAppData%\Microsoft\Windows\Explorer\ folder.
Re: (Score:3)
Chrome stubbornly takes webpage screenshots and uses them as thumbnails for the websites I visit, including but not limited to my private NAS (which can display file names) and my banking website (which can display very sensitive data).
Re: (Score:2)
Windows would also create auxiliary files showing the original device where a file was created. They used to appear using some options for the "dir" command, but are immediately visible when viewing them using Linux.
Windows solution seems really terrible (Score:1)
But for other systems with the feature Including Windows and Some Linux file managers, Do they handle it differently?
I was also wondering so looked into how Windows approaches working with thumbnails...
Basically, what it does is puts a thumbs.db database into EVERY directory it's creating thumbnails for. How does it work for a CD? Well it assumes that whoever created the CD will also generate the thumbs.db file there, if not and you have a lot of images be prepared to wait a while for thumb generation to s
Re: (Score:3)
Linux does not cache things on disk. The only risk is swap, which you just encrypt at boot with a new, random key every boot.
Applications may do something else though.
Re: (Score:2)
Re: (Score:2)
That would be an application problem. I do not use file-manager on Linux.
The main difference is that Windows and MacOS both come with vendor-supplied and created file managers that are also installed by default. This is true for some Linux Distros and not for others and you usually can do without them.
Re: (Score:3)
So do Konqueror, Dolphin, and Thunar.
To ~/.thumbnails
Duh! (Score:2, Informative)
Unless, of course, your system drive is encrypted. Which is one of the first suggestions macOS will give you when you boot your mac for the first time. If you are worried about this kind of thins chances are your system drive will be encrypted and this chache stuff won't be a problem at all.
Re:Duh! (Score:5, Insightful)
Re: (Score:1)
What part of "you are asked when you first install" did you not read? :]
Re:Duh! (Score:5, Insightful)
Re: (Score:1)
Encrypted should be the default of ALL operating system installations, strong encryption too, the stuff that makes pigs get angry.
Re:Duh! (Score:5, Insightful)
and then when it crashes and you can't slave it into another system to get data from it, you're hosed.
Re: (Score:2)
Re: (Score:2, Insightful)
I live in a universe where the same people come to me each month for their email password. Let those people buy Macs with default encryption? They exist everywhere and you would have a PR nightmare. C'mon, this isn't a dreamworld we get to live in.
Re: (Score:2)
What are you talking about? You can decrypt a FileVault volume from any connected Mac machine [apple.com], if you know (or can guess) the password. I've personally done this, it works fine.
As far as brute-force protection, the PBKDF is set to about 250ms [iacr.org]. So depending on the entropy of the password [wpengine.com] could take anywhere from 20 computer days (or a few hours on a big AWS instance) to 8000 years (beyond all the computing p
Re: (Score:2)
Most people are more concerned with data loss than they are with "fuck da police", especially as for most people data loss is a real and genuine concern, while "pigs" are not.
Re: (Score:2)
Encrypted should be the default of ALL operating system installations, strong encryption too, the stuff that makes pigs get angry.
For many years now I have wondered what made the pigs so angry that they stole the eggs from the birds. Now I understand:
1) Birds use strong encryption on ALL operating system installs
2) Pigs get angry.
3) Pigs steal bird eggs
4) Angry Birds
Re: Duh! (Score:2)
Maybe seasoned Mac users might understand that the system drive needs to be encrypted, bT anyone coming from Linux or Unix is going to find that behavior extremely surprising. On Linux, one encrypts the home folder only in the vast majority of cases. Under normal desktop use, everything not in your home folder is open source, so encrypting is would be kind of insane.
Re: Duh! (Score:2)
You're smoking crack if you think the typical Linux desktop has whole disk partitioning.
Re: Duh! (Score:2)
To be clear, I'm talking about Linux DESKTOPS. No one runs Mac servers so comparing Mac security to Linux server security is worthless.
Re: (Score:2)
That was my first though too. This may be an issue worth pointing out .... but if you're really worried about securing your data from prying eyes, why wouldn't you just encrypt ALL drives you use? Why is the system disk being left unencrypted?
Surreptitious? (Score:2)
I don't think there's anything sneaky about it, it's pretty much done in the open. OS X does this differently than windows (thumbs.db in same folder), but it's not "surreptitious" anymore than memory allocation or hardware initialization is surreptitious.
The news is that the data is not being encrypted if it is located on an encrypted drive (and presumably, the main OS drive is not), and evidently had been a well kept secret that is being revealed now.
Re: (Score:3)
Used by forensics experts for some time, would it not be a place for governments and government created malware to look too?
Encryption becomes a joke.
Re: (Score:3)
Re: (Score:2)
Most users don't know a thing about the workings of their computer. If you are worried about encryption, as others said above, your system drive will be encrypted, and then you won't have to worry about this.
Re:Surreptitious? (Score:4)
Re: (Score:2)
Most users don't know a thing about the workings of their computer.
This sentence proves --:
If you are worried about encryption, as others said above, your system drive will be encrypted, and then you won't have to worry about this.
:-- this sentence is useless garbage.
Speaking of system drive, do you audit every computer you plug your device into? Most of us use external drives to move data around *between* computers. And sticking with the theme of most users don't know a thing about the workings of their computer, on a scale of drooling-stupor to "WTF man I'm calling the police" do you expect the expression on the other person's face to be when you start quizzing them on how well they have encrypted their comp
What does Windows do with a CD? (Score:2)
OS X does this differently than windows (thumbs.db in same folder)
Someone else raised the issue elsewhere, what does Windows do when you insert read-only media (like a CD or non-writable thumb drive)?
At some point the OS is going to have to write thumbnail data locally...
It seems like rather than this being a error, it's more a caution that if you are working with encrypted data to make sure that your main system drive is also encrypted - for Windows or OSX...
Re: (Score:2)
Re: (Score:2)
If the read-only media doesn't already have a thumbs.db, then there's no cache. Simple and secure. You can also just turn off thumbnails, if you don't like them.
Thought APFS could fix this... (Score:5, Interesting)
One of APFS's features is allowing for multiple keys per volume. What Apple should have done is store the cache data, but keyed to both the encrypted volume being used, as well as the system volume. This way, if there is no system volume encryption, things are protected still. If there is, it would require two keys to get to the caching info.
Hopefully this can be fixed. Apple comes up with some great stuff, but then misses the mark with other places.
Re: (Score:1)
Without Spotlight enabled, nothing can be searched. Mail, Finder, etc. Even the fucking image thumbnails won't work and file details either (ex: image dimensions).
Re: (Score:2)
False. I have spotlight disabled and I can't get image dimensions from the finder. Dimensions display as "--".
Re: (Score:3)
More at the linked "Cache Me Outside" AC.
https://objective-see.com/blog... [objective-see.com]
PRISM (Score:2)
Wait. What? (Score:4, Insightful)
> these cached thumbnails are stored on non- ... content stored on
> encrypted hard drives,
> encrypted containers.
This does not make sense. If the hard drives are encrypted by FileVault; the storage location for these thumbnails would be encrypted too. Where else is this cache supposed to live? I'm pretty sure that Apple does not add an extra, secret, non-encrypted drive to everyone's Macs so as to cache these silly little images. And as if the summary weren't bad enough, it gets worse when you read the article. QuickLook isn't new, as they claim. It was introduced as part of Leopard, more than a decade ago. And a quick check on my CLI shows that TEMPDIR is very much part of my encrypted root volume. I'm thinking these people are not the "macOS security experts" they claim to be; and msmash failed as an editor in not properly vetting the article he chose to post.
Re:Wait. What? (Score:5, Informative)
> these cached thumbnails are stored on non- ... content stored on
> encrypted hard drives,
> encrypted containers.
This does not make sense. If the hard drives are encrypted by FileVault; the storage location for these thumbnails would be encrypted too. Where else is this cache supposed to live? I'm pretty sure that Apple does not add an extra, secret, non-encrypted drive to everyone's Macs so as to cache these silly little images. And as if the summary weren't bad enough, it gets worse when you read the article. QuickLook isn't new, as they claim. It was introduced as part of Leopard, more than a decade ago. And a quick check on my CLI shows that TEMPDIR is very much part of my encrypted root volume. I'm thinking these people are not the "macOS security experts" they claim to be; and msmash failed as an editor in not properly vetting the article he chose to post.
I guess the issue is when you have your laptop drive not encrypted and you connect an encrypted USB-stick on it. It then creates thumbnails of what's on your USB stick and store them on your unencrypted system drive.
No need to be an expert. Common sense is enough.
Re:Wait. What? (Score:5, Interesting)
But that is true for anything. If you plug in an encrypted drive in an insecure system and decrypt it, the encryption doesn't matter. Your memory could be swapped to disk at any point in time regardless of your OS. Hence the need for FDE.
Re: (Score:1)
But that is true for anything. If you plug in an encrypted drive in an insecure system and decrypt it, the encryption doesn't matter.
This is an idiotic statement, akin to- since a car crash is dangerous, why bother wearing seat belts?
Security is not a boolean.
There is no such thing as a boolean true "secure" system. There are only shades of security. Arguing that all security should be thrown out because the system itself doesn't meet some standard or definition guruevi the wise has set is the pinnacle of silliness. Fuck it.
No, you're right. Fuck it. Removing all passwords and running a chmod 777 across the entire drive as we speak.
Re: (Score:2)
Here's your sign.
Re: (Score:2)
There is a huge difference. If I plug an encrypted drive into my unencrypted system and view a few images, and then take the encrypted drive out and shut my system down, I expect a very low risk of any decrypted information remaining on my machine. Especially if I have taken the precaution of letting my tmp directory get wiped on shutdown.
And I will definitely not expect decrypted information which will show up directly in the file manager, as immediately viewable.
But here, there will be. The thumbnails are
Re: (Score:2)
Re: (Score:2)
Leaks through caching are a common issue. Another example would be thumbnails in JPEG files. A lot of cameras add them to the JPEG file to make browsing thumbnails faster. When the image is edited in Photoshop, say to redact something, the thumbnail remains untouched.
The only solution is to encrypt everything and strip all metadata/hidden data when saving.
Re: (Score:2)
Re: (Score:2)
Some people set up their machines such that the OS is not encrypted. Those thumbnail files are stored on the OS disk, and are not deleted or encrypted if the actual files are. They are a permanent record of every image you have viewed.
Re: (Score:2)
And a quick check on my CLI shows that TEMPDIR is very much part of my encrypted root volume.
You have an encrypted root volume? Cool!
Re: (Score:2)
If less than a year for a major OS release is no longer "recent" for you, consider cutting back on the LSD.
Re: (Score:1)
Re: (Score:2)
The AC must have mistyped - October 2007 according to https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Leopard was released October 2007 (clearly simply a typo on your part).
Re: (Score:2)
October 2007 according to https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
>released along with OSX 10.5 Leopard, and Leopard was released in October 2017. I wouldn't call that a *recent* >macOS version.
I'm guessing you meant 2007.
I don't know the exact date but that sounds about right.
Impatient (Score:1)
Re: (Score:2)
It's not impatence or a design choice. It's pretty obviously a bug, because Apple didn't think of thie use case of unencrypted system drives and encrypted other drives.
Re: (Score:2)
Re: (Score:2)
If they didn't expect you to do it, they didn't expect it. I'm not sure why you think it was cost saving.... it's just unexpected.
You cannot expect anything. And if no one in the area did it, it's unlikely the software will support it.
Re: (Score:2)
Reading the whole disk to create thumbnails can be pretty slow. This is pretty much a non-issue though, whenever your OS runs low on memory, it will swap whatever is in memory to disk. If your disk isn't encrypted, you'd see a lot more than just thumbnails.
Noticed this years ago! (Score:2)
It's one of many reasons why you should do your pr0n browsing on a separate, encrypted user account (not that it's terribly easy to do since the introduction of FDE came with the removal of user account encryption) even if your stash is on an external drive.
Power efficiency or live en/decryption? (Score:2)
You can't have both. Naturally.
To be honest, I'll take power efficiency. HDD/SSD encryption protects you from the scenario of someone reading a disk he snatched off you. This is the most likely scenario and if some ageny want's to read my stuff remotely in real time I figure they'll do it one way or the other once they've snuck a troyan in.
Botton line:
The SSD still is safer than when not encrypted and if caching is faster and saves power it's a balanced design choice and a calculated IMHO. I figure Apple kn
Re: (Score:2)
Your pr0n stash may be discovered! (Score:2)
It's amusing they highlight "political regimes" when it's really your spouse/SO/Geek Squad who you're likely worried about.