MacOS Caches Data from Encrypted Hard Drives
objective-see.com
objective-see.com
QuickLook was added back in 2007, to OS X 10.5 Leopard: https://en.wikipedia.org/wiki/Quick_Look
cached images go in /var on the boot drive
Something so commonly-known that even I, not exactly a Darwin kernel dev, knew that. Another comment called TFA "blog spam", and I can't argue strongly that they're wrong.
too bad the original blog (if it is the original) is undated.
side-bar: how do you know this? is the information about the file structure of linux available somewhere? I've only ever run into this type of thing circumstantially.
However, it's become a pain lately anyway in that it doesn't work for images [maybe over a certain size?] stored in iCloud (unless it's already downloaded) which includes the desktop folder and therefore screenshots (because letting you store screnshots anywhere else by default would be logical and we can't have that). Nor does it show anything to indicate this, it just appears to randomly work or not work. I wish they'd send a lower res version for previews, or something, as more and more stuff moves to the cloud.
I haven't looked to see whether there's a keyboard shortcut to jump to the next image. It's not up/down arrow.
defaults write com.apple.screencapture location ~/Screenshots
killall SystemUIServer
So it would seems this is only a concern if you had a secondary drive that was encrypted but a root volume (or some other volume mounted to `/var/folders`) that was unencrypted.
I don't think this is much of an issue TBH, if you're concerned about data access your root volume should be encrypted already.
Not really. It's also a concern if:
* the encryption to your root volume is broken somehow (either through one of the APFS encryption bugs, you've been compelled to hand over the keys, etc.), or
* the secondary drive is not available or was destroyed,
* etc.
Not necessarily. Your primary drive could have been otherwise clean of things you wanted to hide. If you have data you need to keep safe, full disk encryption isn't a panacea that allows your opsec to get sloppy in other areas.
> Most of the scenarios I can think of where this is behaviour is bad are not really the sort of thing FDE is supposed to solve.
I agree, I was responding to a comment that also said this:
>>> I don't think this is much of an issue TBH, if you're concerned about data access your root volume should be encrypted already.
As I said, I can't think of a non-contrived scenario in which this is an issue and to me, the one you're describing is strictly in the contrived category.
It's game over if there was malicious software on the computer that cared to read your plaintext data, what about the rest of the cases?
Even for the library scenario it could be important: A whistleblower going to the library, sending off some leaked documents to journalists, and later having the MiB pick up the library computer for forensics.
That's not a good idea, an encrypted filesystem is only as secure as the computer you decrypt it on. Yes, of course, if you're carrying a USB drive around with you, it's strictly better that it's encrypted than not (protection against theft and loss), but it's not exactly difficult to imagine that a public computer should have malware installed.
For the leaker/whistle-blower scenario, disk encryption is your absolute last line of defence. When the MiB comes knocking, you absolutely want all your drives fully encrypted, but the vast majority of your security efforts should be spent on not getting identified in the first place. But what you don't want is for the MiB to find out that you're using the computers in a certain library, go there and install keyloggers and only come to your house once they have your passphrase.
If you're using Filevault2, the entire hard disk is encrypted, including the cache location.
When you opened that image from an encrypted volume in an image viewer portions of the memory could have been written to swap.
All kinds of things will be logged to system log files: what programs you invoked, who knows what else.
Opening an encrypted volume on an unencrypted computer is just asking for trouble.
If you really need security you should open it on a fresh fully encrypted install of your OS that you dispose after.
Does anyone know where/when this occurs? If you install macOS from scratch on a computer?
Of course I like to poke around a new system and reconfigure everything only to immediately forget I made that change.
I started using full drive encryption as soon as I started getting faster devices (i.e., not the Nexus 4) - in fact I've only not too long ago reformatted an external backup HDD (WD Green - unremarkable) to use LUKS encryption, and haven't really noticed a noticeable performance hit (Phoronix has some good benchmarks on various types of disk/folder encryption). It's laughable now to think I left it on the floor ("secured" by the 5-pin tumbler lock in my front door) without any kind of data/identity theft* protection for so long.
* As an aside, here's a vaguely-relevant #1 trending story in Australian media for the past few days (related in a general security sense which most people neglect - not necessarily disk encryption): https://www.smh.com.au/business/companies/masterchef-finalis...
However, when running the macOS installer, either when installing a fresh copy of macOS or when performing an upgrade, the default is to turn FileVault on unless you uncheck it.
I guess there are valid reasons why Apple don't ship new Macs with FileVault enabled from the factory. But it is strange that it doesn't at least prompt you / encourage you to enable it in the initial setup wizard, like the macOS installer does.
Should we assume that when it could also be likely there's no good reason? Especially given common practices like this - which I also experienced when I had my entire 2016 MBP in for a battery (and therefore full topcase) replacement: https://www.troyhunt.com/apples-desensitisation-of-the-human...
(In own my case, after questioning, I gave them a non-admin test account after I modified ~/ permissions away from 744 - yet, it was I who felt like the crazy one for not simply handing over all my active browser/email login sessions. Imagine what a great attack vector that would be for most Apple customers.)
Encrypted PDFs don't show their contents in QuickLook (just a lock icon).
QuickLook is useful though, especially when used from the command line. I use it to convert DOC and PPT files to HTML, and then to TXT, without needing MS Office.
In later versions, Explorer stores all thumbnails in %LocalAppData%\Microsoft\Windows\Explorer, which can very well be on a different volume than the original file.
One example I've seen was that if you filled out a form in Okular, it would store the form data in a dot file in your home directory rather than in the original PDF or a file adjacent to the PDF. Not sure if that was ever fixed.
Have a look of how many repositories on GitHub which include a completely unrelated .DS_Store file: https://github.com/search?q=filename%3A.DS_Store
We pulled an old camera out to donate the other day and I popped the SD card in my laptop to see what might be on the card. It was a 1GB card "full" of photos my kid took on one of our vacations. I say "full" because there was a 125mbs of files Finder left wasting space on it.
That's easily 25 photos that weren't taken. What shots did we miss because the SD card was "full"?
But likely shred won't even work, because SSDs overwrite other blocks when you perform a write operation, for wear leveling. I'm not sure if there's any hope of erasing something from an SSD besides physically destroying the SSD.
I was under the impression that TRIM/UNMAP would erase the flash blocks currently associated with some sectors, is that not the case?
https://security.stackexchange.com/questions/109916/does-the...
Edit: actually the other original source it links to seems to have more information, so maybe we'll use that instead.
As the Quicklook database is never decrypted unless you have the disk password in this case, I don't think it is, but would like validation of my thought process as it seems like this mostly pertains to mounted encrypted image files or non-system encrypted drives, not whole disk system drive encryption.
However, if you use something like the MacFort app that stores resting app program data (like your Photos Library file) in an encrypted disk image only decrypted/mounted when you open the Photos app itself (and provide proper password) and then is closed/unmounted immediately after the app that called for it is closed, is this vulnerability still valid? I'm thinking it is in this case, as the encrypted files are at one point mounted on the file system in an unencrypted state and QuickLook can then cache contents as described, but again, I'm curious for validation.
1. If you have leaked data to an unencrypted partition, then simply deleting it will not hide it from forensics experts.
2. There are many vectors in which an _application_ (because that is what we are talking about) can leak data to unexpected locations. This isn't even one of the more subtle ones, in fact it is expected, and probably present on every major os.
3. The article baits fear mongering and conspiracies.