
MacOS Caches Data from Encrypted Hard Drives - oedmarap
https://objective-see.com/blog/blog_0x30.html
======
miles
> _But in a recent macOS version, Apple has added a new feature to Finder
> called QuickLook. This feature allows users to hold down the Space key while
> having a file selected and view an image-like preview of the document 's
> content._

QuickLook was added back in 2007, to OS X 10.5 Leopard:
[https://en.wikipedia.org/wiki/Quick_Look](https://en.wikipedia.org/wiki/Quick_Look)

~~~
maxxxxx
This is one of my favorite features for sifting through a large number of
pictures.

~~~
ClassyJacket
I love it too and was disappointed to read recently on HN it's not easy to do
on Linux, as I intend to switch to Ubuntu on a desktop soon. If anyone knows
the best way to set it up I'd like to hear it.

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.

~~~
coatmatter
I'm fairly sure the default file explorer in Ubuntu/Fedora (nautilus) offers a
preview spacebar function but I don't use it enough to know whether it's
limited to images.

I haven't looked to see whether there's a keyboard shortcut to jump to the
next image. It's not up/down arrow.

------
mbell
Unless I'm misunderstanding what is happening here, it stores the thumbnail
cache in a subdirectory of `$TMPDIR` which at least on my machine is
`/var/folders/.......`.

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.

~~~
tivert
> 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.

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.

~~~
pvg
If the first one is a problem, you have much bigger problems. Not sure what
the second concern you're describing is. 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. Maybe there are others but I haven't seen them described in
this thread.

~~~
tivert
> If the first one is a problem, you have much bigger problems.

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.

~~~
pvg
If the encryption on your root drive is broken or breakable, it's game over
for that kind of system. The scenario 'I'm plugging in random encrypted drives
into my system which is itself not encrypted' is not a sane one any OS maker
is going to spend time mitigating. Your editor could have left stuff in a
backup. The file contents might be sitting in swap. You copied the file over
and forgot to delete it. Or you deleted it but not securely. Etc, etc, etc.

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.

------
anderiv
It should be noted that using FDE software like the built-in Filevault2
mitigates this leak.

~~~
jiveturkey
it does? the entire premise is that this leaks encrypted data

~~~
anderiv
Yes, it does. If you read through the researcher's post, they have an
encrypted volume (VeraCrypt-style) which they mount on an otherwise
unencrypted filesystem. Data can leak from inside the encrypted volume, to the
cache location outside the encrypted volume.

If you're using Filevault2, the entire hard disk is encrypted, including the
cache location.

------
21
There are so many other things that could leak besides thumbnails:

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.

------
trasz
Caches it where, on the root filesystem? Which is encrypted by default
since... ages?

~~~
klodolph
It’s not encrypted by default. FDE is something you have to enable.

~~~
Reason077
It's the default in the macOS installer. You have to uncheck a check box to
turn it off.

~~~
kstrauser
You don't see an installer when you buy a new Mac. I just installed 5 new
computers in an office, and none of them had a mechanism for enabling
FileVault other than going into sysprefs and turning it on myself.

~~~
madeofpalk
Wow, I'm actually surprised this is true. I didn't believe you, except I went
into System Preferences on my new Mac and saw that FileVault wasn't enabled.
That greatly surprises me because I've definitely seen the FileVault FDE
option, with it being on by default, in the setup wizard before.

Does anyone know where/when this occurs? If you install macOS from scratch on
a computer?

~~~
Reason077
As others have pointed out, it seems that FileVault is not enabled by default
on new Macs. You have to go to System Preferences and find the option enable
it.

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.

~~~
coatmatter
> _I guess there are valid reasons why Apple don 't ship new Macs with
> FileVault enabled from the factory._

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...](https://www.troyhunt.com/apples-desensitisation-of-the-human-race-
to-fundamental-security-practices/)

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

------
gruez
but what did you expect, that macos can magically determine which mount point
is encrypted or not? what about "sensitive" SMB/NFS/SSHFS mounts?

~~~
Nullabillity
I would expect it to store the thumbnails together with the files. Then again,
this is Apple we're talking about...

------
walrus01
historically there have been _a lot_ of jpg/photo album/image thumnail/image
viewing and browsing software packages that autogenerate tiny thumbnail files.
I've seen it as far back as 1997 and on Windows, Linux and on OSX. The main
difference as I see it is that most of those put the tiny thumbnails in the
same directory as the images they were browsing. In this case if you have an
encrypted drive mounted the thumbnails are going somewhere else on a volume
that may not necessarily be full disk encryption.

------
peterburkimsher
Yes, it's a security risk, if having an encrypted drive is your only security
measure.

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.

[https://macscripter.net/viewtopic.php?pid=191939#p191939](https://macscripter.net/viewtopic.php?pid=191939#p191939)

------
ryanlol
This is to be expected on essentially any OS.

~~~
Osiris
Is it? Couldn't the previews be stored on the same volume as the original?
Windows stores "thumbs.db" in the same directory as the original image.

~~~
gruez
and that's how you end up with annoying shit like __MACOSX and ._caches
folders everywhere

~~~
cptskippy
You don't like sacrificing 1% of your SD Card space to Finder?

~~~
mort96
It's not that the files take up space, it's that they're there.

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](https://github.com/search?q=filename%3A.DS_Store)

~~~
cptskippy
I'm annoyed equally by the space they take up and their presence.

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"?

~~~
mort96
Wow, that's 12.5% of the card, not 1%. I had no idea Finder's files would get
that large.

~~~
chungy
A 1GB SD card is likely to be formatted with FAT16. Even a "one byte" file
must take up 32KB in the file system because that's just how big the clusters
will be.

------
armitron
More low SnR spam from Patrick Wardle.

------
ddtaylor
That rm command won't clean anything you would need to use shred first.

~~~
Buge
You're right that rm won't be enough, and the "Success!" isn't really a
success.

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.

~~~
garblegarble
>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?

~~~
Buge
Generally I don't believe that TRIM securely erases anything.

[https://security.stackexchange.com/questions/109916/does-
the...](https://security.stackexchange.com/questions/109916/does-the-ata-trim-
command-irrecoverably-delete-data-on-an-ssd)

------
danieldk
Blogspam for:

[https://wojciechregula.blog/your-encrypted-photos-in-
macos-c...](https://wojciechregula.blog/your-encrypted-photos-in-macos-cache/)

~~~
dang
Thank you. We changed to that from
[https://www.bleepingcomputer.com/news/apple/macos-breaks-
you...](https://www.bleepingcomputer.com/news/apple/macos-breaks-your-opsec-
by-caching-data-from-encrypted-hard-drives/).

Edit: actually the other original source it links to seems to have more
information, so maybe we'll use that instead.

------
ThbTs4wbXC9Qjv
Is this vulnerability defeated if you use a APFS/HFS disk password that no
specific OSX user accounts are authorized to bypass, as is the case when you
encrypt the whole hard drive and then install OSX versus activating File Vault
only on a per account basis? In other words, if I don't have the hard drive
disk password, but I do have a single user account login/password, nothing is
capable of being leaked in this case, correct?

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.

------
Skunkleton
Seems like a low quality article to me.

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.

~~~
dang
We changed the URL after this was posted.

