> 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.
And yet the exploit was known "for years" (so sez TFA). So which is it, security hole from a recently-added feature, or a "hole" that was an open secret for over a decade?
Both, because apparently a feature from 11 years ago is "recently added" per TFA. QuickLook has always worked this way (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.
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.
Personally, I know it like I know a lot of things: poking around one day, probably looking for something else in the /var directory ("is it /var/log, or /var/logs?"), and "'ello, wot's this?". Best I can recall, I've never had a practical reason to know this, or a lot of other things I know.
It depends on what kind of content you're exploring. If you try browsing many folders with hundreds or thousands of videos over the course of a few hours it'll eventually cause the whole system to crash. I've found that if a video has any kind of issue playing with QuickTime it usually causes huge memory leaks.
To be clear, when I say painfully slow, it isn't actually very slow. On i7 6700 and fast ssds that apple puts in macbooks it should be instant, but it's not - the small delay that quick view has is similar to uncanny valley for me, and it annoys me very much. Xnview works exactly as it should - instant.
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.
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.
As far as macOS goes, you can point the default screenshots location away from your iCloud drive. I did that fairly early on because uploading every random screenshot I take on a 1 Mbps upload connection is insanity.
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.
> 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,
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.
> 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.
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.
FileVault use largely happens on more or less insecure computers, so it is an interesting case.
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.
> FileVault use largely happens on more or less insecure computers, so it is an interesting case.
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.
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.
Where exactly is this feature leaking the data to if FDE is turned on? To the encrypted /var directory? It could potentially leak from an encrypted external storage device to a non-encrypted /var on the boot drive, but if you use FileVault to encrypt the boot drive the “leak” would be from one encrypted drive to another. An issue to fix, but not a major story.
Yeah... a lot of articles like this seem to equate poor security practices like "using an encrypted disk with a non-encrypted root" with major issues in the OS. I do agree that it's an issue that thumbnails stored should be wiped by default when the drive is disconnected unless the root is encrypted also but you're already open to compromise the second you access an encrypted disk from a system where the root isn't also encrypted. Having read access to an encrypted disk in any situation where you're not certain there's a secure chain is, by definition, insecure.
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.
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?
I thought it was the default too but now I'm thinking I've just been conditioned into accepting it as a sensible default* and might have automatically enabled it on my own accord after reading the instructions.
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...
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.
> 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...
(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.)
I could be mistaken, but I could have sworn it was a checked-by-default checkbox in the welcome to macOS app that runs when you open a new machine from the factory. I don't recall having to go into system preferences to turn it on with my most recently purchased machine.
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.
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.
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.
I won't speak for the file managers in particular, but on linux it is common practice for cached data to be stored in dot files like ~/.cache/ even if the original data is on a different encrypted mount. It is a pretty deeply engrained practice that can easily leak secrets if you aren't careful. Another example of how security is hard to bolt on after the fact.
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.
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"?
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.
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.
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.
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.
QuickLook was added back in 2007, to OS X 10.5 Leopard: https://en.wikipedia.org/wiki/Quick_Look