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.
These slimebags are just like google, facebook and the rest of the traitors. You can't even search your fucking mail if you don't let them dig around in your filesystem. They do this bullshit under the facade of being helpful. It's really just asshole design.
we shouldn't connect an encrypted external drive to a non-fully-encrypted macOS drive?
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
Surf with a device that has no UEFI BIOS. Use encrypted folders on a F2FS formated thumb drive. And run BleachBit on a Linux OS.
Nazi pigs
Nazi pigs
Whatcha gonna do
When nobody wants to sieg heil you
MacOS don't get the security attention that iOS does and it now has 10% market share which makes mass exploitation viable and profitable so it's getting attention from people mad that the mac mini hasn't been updated for years.
But I never knewed it was my opsec. I didn't even knowed I had a opsec. Apple. Why did you broked my opsec?
> 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...
The article states that "in a recent macOS version, Apple has added a new feature to Finder called QuickLook". Well, it was released along with OSX 10.5 Leopard, and Leopard was released in October 2017. I wouldn't call that a *recent* macOS version.
Thunderbird searches mail fine without spotlight...
> 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!
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).
#DeleteFacebook
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.
What is wrong with Apple users that they can't wait another 0.0002 seconds for icons to load off the local drive? I think that is the real matter at heart here.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Linux, especially Ubuntu, works the same. I thing the service is called gfinder, or something like that.
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.
Is this a Trump-esq "dot dot dot"? Editing out the bit that you didn't like?
"... in a known location and can be easily retrieved by malware or forensics tools, revealing some of the..."
You can move those back on the encrypted drive/folder with a simple link.
~/.cache/thumbnails -> ~/mnt/private/.thumbnails/
Be or ben't
LIKE MY #MARS https://m.facebook.com/MARS-21...
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.
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
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 seek all over the disc.
What this means to the end user is that every directory ends up with this thumbs.db file that potentially confuses them and takes up space, even long after they may be interested in viewing contents of that directory (unlike a cache directory that can be cleaned by the system).
Don't think it's confusing? Take a look at the results of this Google search...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
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.
Some people set up their machines such that the OS is not encrypted.
An encrypted OS of a known version serves as an enormous "plaintext" for encryption breaking purposes. Encrypting the OS drive is normally a mild vulnerability, but Apple has managed to make the alternative worse.
Courage! (TM)
I cant safely look at tumblr porn without seeing a past flashback when I launch tumblr. Its porn so no big deal but it could have been safari with secret launch codes in the thumbnail
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
Have more than one encrypted drive? Then you will need to point the link to one of the other drives. Otherwise the link will likely prevent all thumbnails from being generated because the target location does not exist. Removing the drive should not recreate the security risk.
~/.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.
On older MacOS operating systems, the Resource Fork, the predecessor to the .ds_store, would occasionally store the file's data.
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.
Not true. Spotlight only affects searching, thumbnails and file info will work regardless.
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. I thank you for your insight, and whatever moron modded you up.
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.
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.
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.
You are wrong, thumbs live in /var.
The researchers made no such claim, the reporter from Bleeping Computer made that claim.
They are well knwn and respected in the the Mac security field.
The security warning was about an unencrypted root volume.
My advice to you is learn how to read and stop speaking out of your ass.
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.
In Windows, it is pretty bad. It has normally kept a thumbs.db in the same directory, but it also keeps thumbdata in another generic place. CCleaner will mention it when cleaning stuff out.
Linux it depends on the file browser you are using, and the answers are usually "yes" and "under a dot-name directory in your home directory, such as .cache"
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
Superfag Kendall has no idea how anything works except bragging about surface-scratching babyshit knowledge on topics he considers himself an expert of, because Republicanism. New Orleans INCEL chapter leader right there.
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.
C:\Users\...\AppData\Local\Microsoft\Windows\Explorer\thumbcache_XXXX.db
https://www.raymond.cc/blog/wh...
Nautilus does.
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
The problem is when your root volume is not encrypted but your secure volume is. For example, you take your encrypted thumb drive to a client site to give a presentation. You don't expect that images of your other confidential presentations on that thumb drive are stored on the laptop of the guy who hooked his computer up to the projector.
dom
This is an idiotic statement, akin to- since a car crash is dangerous, why bother wearing seat belts?
Incorrect on both counts. It is more like saying "if you drive your car into a wall, you might die. So maybe don't drive your car into walls". And in a story that is attempting to claim "if you drive your Apple car into a wall [...]" where the obvious implication is that non-Apple cars do not suffer from this problem, it is absolutely not an idiotic statement to point out "hey, this impacts non-Apple cars too".
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
Then to be absolutely blunt, you are an idiot.
Especially if I have taken the precaution of letting my tmp directory get wiped on shutdown.
I take that back. You are not an idiot, you are worse. You are a confident idiot.
So do Konqueror, Dolphin, and Thunar.
To ~/.thumbnails
Another apple "expert" heard from.
One, you shouldn't be swapping to disk stuff that originated from disk. Two, it wouldn't be a bad idea to have the OS tag encrypted data in the same way it tags pages containing security keys so they aren't swapped out; this also means programs that work with such data should consider marking most of their pages as such as they process such data. Three, this is actually more of a reason to turn off swap. Except for hibernation, these days there's very little reason for most people on any modern hardware to use swap. It makes more sense to just spring for 16GB or 32GB RAM.
PS - Yes, there's invariably some people who actually need more than 16GB of RAM or hardware that doesn't support that much, but that's very much the exception. At this point, I'd argue it makes sense to only support swap in a fashion that appears infrequently and help users chart when/why swap is happening because we're no longer in the situation where it should be a common occurrence. That way users could figure out if they need to buy more RAM, if it's really that once in a blue moon situation where they've went over their RAM total and a little swapping won't hurt, or if it's really just some rogue program that needs to be killed. My experience has been 90% number 3.
You might try reading the actual article yourself before accusing others of not doing so.
âoeBut in a recent macOS version, Apple has added a new feature to Finder called QuickLook.â
Thats pretty unequivocal in my book. They could maybe be amongst those people who still think snow leopard was the last OSX worth using and disavow the existence of any since. But that just makes them even more a pair of asshats and definitely not anyone who should be listened to in the here and now.
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,
OUCH! msmash down-voted my post but not the parent that I quoted from. How childish.
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.
The greatest lesson I learned through my years in college, the one thing that I paid $60k for is this:
If your plan requires a human to "do the right thing" then it is destined to fail. They should be engineered out.
Doesn't matter what you think the user should or should not do. You should be preparing for this and "if you don't then it's your own damn fault".
Also, does your Windows work differently than mine? I have my Win10 drives encrypted. Not once was I ever asked for nor shown an encryption key/passphrase.
Tip your head back a smidge and wiggle it slightly from side to side. Tim Cook's cock should slide right on down with no gagging.
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.
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
Butt hurt much?
As I said, that is from the Bleeping Computer article, not the article written by the security researchers.
https://objective-see.com/blog/blog_0x30.html
You need some remedial reading comprehension.
It's part of the functionality of the Finder. You can flush them with a tool like Onyx, and if you use a Mac you should on the regular as it improves performance, as well.
To be fair it's probably best to be using whole disk encryption rather than partitions or containers and you definitely want the system disk, home disk etc covered by WDE. I think the whole "only encrypt part of my system" concept was debunked as a bit stupid some time back. You simply cannot control where shit ends up in various processes so just encrypt the bloody lot - especially now SSDs are mainstream.
Seriously dude. Just say fucking. Fake censoring yourself like that may have been a staple of some good '70s SciFi. But it's not what made '70s Niven good. And its one trope that should have stayed in the 1970s.
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.
I have Spotlight disabled on my Downloads folder, yet I can see thumbs and Get Info works. I have Spotlight disabled on an external disk holding images, yet I can see thumbs and Get Info works.
Huh? It's literally called "Bleeping Computer" in case you didn't RTFuckingA.
per the (updated) blog post, disable the QuickLook cache entirely with
"qlmanage -r disablecache"