Slashdot Mirror
macOS Breaks Your OpSec by Caching Data From Encrypted Hard Drives (bleepingcomputer.com)
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.
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?
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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.
Well... Windows creates them on the drive itself. But I thought that was what MacOS was doing as well so I could be totally off on that.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
All the helpful GUI ways around encryption.
Domestic spying is now "Benign Information Gathering"
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
> 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.
Imagine all the people...
To make the GUI look nice and have the GUI be more responsive sooner the OS has a nice easy way to show the thumbnails on file the user looks over in their encrypted external drive.
More at the linked "Cache Me Outside" AC.
https://objective-see.com/blog...
Domestic spying is now "Benign Information Gathering"
> 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.
Write boring code, not shiny code!
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.
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...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm pretty sure users have to wait a whole second for the thumbnails to be generated if the Thumbs.db file cannot be written to the media.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
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.
I browse on +1 so AC's need not respond, I won't see it.
You can move those back on the encrypted drive/folder with a simple link.
~/.cache/thumbnails -> ~/mnt/private/.thumbnails/
Be or ben't
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.
Your ad here. Ask me how!
And what happens if you remove the encrypted drive?
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
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.
Your ad here. Ask me how!
Right.. Because Steve Jobs wouldn't have done it that way. Apple must save hundreds of thousands in development costs by expecting everyone to use their systems the same way. Using MacOS is an exercise in using someone else's workflow that Apple feels is right.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
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.
Knowledge = Power
P= W/t
t=Money
Money = Work/Knowledge so the less you know the more you make
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.
Custom electronics and digital signage for your business: www.evcircuits.com
Which has nothing to do with this. The thumbnails are not created by the kernel but by the Finder, which is not open source.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
Custom electronics and digital signage for your business: www.evcircuits.com
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 also opens the thumbs.db upon opening the folder, and keeps the file open even after navigating away, or by default even after closing the explorer window (the default settings run all explorer windows in the same single process, although often this behavior is changed just for stability purposes so one can force quit a given explorer.exe process and not take out all of them)
I suppose keeping all the cache data locally in one place may have been an attempt to keep storage servers clean and not have these always-open hidden files littered everywhere, but they even fail at that task.
OS X used to create a hidden folder itself named ".DS_Store" that behaved similarly, though I think was to store folder attributes instead of thumbnails. It was a bit worse to cleanup after too, as this hidden folder contained one hidden file per actual file in the original folder.
Windows based archival tools like 7zip and even the built-in zip function in explorer know to exclude the thumbs.db files, but would always include the hidden ds_store folders.
You'd think in this day and age we would finally have file systems capable of storing meta data properly instead of (ab)using normal files for this purpose...
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.
If less than a year for a major OS release is no longer "recent" for you, consider cutting back on the LSD.
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!
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 knows what it's doing. Most of the time that is.
We suffer more in our imagination than in reality. - Seneca
Parent made a typo. Leopard was released on October 26, 2007.
After 12 years and a few days, I finally gave in to the dark side and joined slashdot.
Leopard was released October 2007 (clearly simply a typo on your part).
~/.cache/thumbnails -> /dev/null
But then that makes no thumbnails work. Worst solution ever!
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Christ, you fail hard, man.
You do know the entire OS isn't open source, right?
In particular, go ahead and show me the source for Finder.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
October 2007 according to https://en.wikipedia.org/wiki/...
Another issue, even for those who do have encrypted system drives, is that the cache is world read/writeable. Anyone else with an account on your machine can read that cache, so even an encrypted system drive doesn't help if you have multiple users or the guest account is enabled (and we've seen bugs in the past that allowed it to be enabled without signing in to an admin account, so don't trust that disabling it is enough).
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
The AC must have mistyped - October 2007 according to https://en.wikipedia.org/wiki/...
Or multiple users. The cache is world read/writeable.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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).
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
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.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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 in a predictable location, and they are easy to access. No special tools needed.
All security can be defeated, but the barriers are not all equally high.
It's amusing they highlight "political regimes" when it's really your spouse/SO/Geek Squad who you're likely worried about.
Make sure everyone's vote counts: Verified Voting
So do Konqueror, Dolphin, and Thunar.
To ~/.thumbnails
>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.
-- "This world is a comedy to those who think, a tragedy to those who feel."
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 with hidden folders instead of using FS-level mechanisms for keeping data together.
That, and the loss of meaningful OSTypes and Creator Codes are sometimes what I miss the most about the classic Mac OS system software.
Hire a Linux system administrator, systems engineer,
Linux is a kernel, it has no reason to cache thumbnails and the equivalent subsystems in macOS and Windows don't either.
The various file managers for each desktop system are independent. Nonetheless, several major file managers such as Nautilus, do indeed cache thumbnails.
You are not alone. This is not normal. None of this is normal.
Nonsense. Having an unencrypted swap isn't driving your call into a wall. Having an unencrypted swap is a potential security leakage for applications that may have disk data unencrypted in their ram. It's not some magical interface to the encrypted disk.
Here's your sign.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
False. I have spotlight disabled and I can't get image dimensions from the finder. Dimensions display as "--".
#DeleteFacebook
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\...
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.
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.
Your ad here. Ask me how!
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.