29 ms·

MacOS Caches Data from Encrypted Hard Drives

176 points by oedmarap 8y ago

miles 8y ago
> 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 8y ago
  This is one of my favorite features for sifting through a large number of pictures.
  - iaml 8y ago
    What hardware do you have? On my mbp 2016 15' it's painfully slow compared to xnview when I want to browse through a lot of images.
    - maxxxxx 8y ago
      I have a 2014 13" MBP.
    - TheAceOfHearts 8y ago
      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.
      - iaml 8y ago
        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.
    - reaperducer 8y ago
      Sometimes it helps to "encourage" Spotlight to reindex your files, creating new Quicklook thumbnails.
  - ClassyJacket 8y ago
    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.
    - systemtest 8y ago
      Do you store the full iCloud contents on your drive or does it download on demand? I am not sure if Quicklook works on the latter
    - thisacctforreal 8y ago
      You can set the screenshot destination using: defaults write com.apple.screencapture location ~/Screenshots killall SystemUIServer There are a few handy things you can configure using defaults(1).
    - coatmatter 8y ago
      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.
    - coatmatter 8y ago
      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.
- mikestew 8y ago
  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?
  - JonathonW 8y ago
    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).
    - mikestew 8y ago
      Yeah, I was being somewhat rhetorical. :-) 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.
      - jiveturkey 8y ago
        blogspam is referring to the fact that TFA is regurgitating a blog (and capturing revenue) without adding value. too bad the original blog (if it is the original) is undated.
        wlesieutre 8y ago
        It says "17 days ago" and if you hover changes to "02 Jun 2018" (at least on desktop)
      - mr_spothawk 8y ago
        > cached images go in /var on the boot drive 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.
        cristoperb 8y ago
danieldk 8y ago
Blogspam for: https://wojciechregula.blog/your-encrypted-photos-in-macos-cache/ https://wojciechregula.blog/your-encrypted-photos-in-macos-c...
- dang 8y ago
  Thank you. We changed to that from https://www.bleepingcomputer.com/news/apple/macos-breaks-your-opsec-by-caching-data-from-encrypted-hard-drives/ https://www.bleepingcomputer.com/news/apple/macos-breaks-you.... Edit: actually the other original source it links to seems to have more information, so maybe we'll use that instead.
ryanlol 8y ago
This is to be expected on essentially any OS.
- Osiris 8y ago
  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.
  - bumblebritches5 8y ago
    Great idea, spam the shit out of every folder with useless files even more. that's just what we need.
  - niftich 8y ago
    That's in Windows XP. 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.
  - gruez 8y ago
    and that's how you end up with annoying shit like __MACOSX and ._caches folders everywhere
    - cptskippy 8y ago
      You don't like sacrificing 1% of your SD Card space to Finder?
      - ubercow13 8y ago
        Why would you want your OS to start writing to the SD card just because you browsed around it in Finder?
      - mort96 8y ago
        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
anderiv 8y ago
It should be noted that using FDE software like the built-in Filevault2 mitigates this leak.
- r00fus 8y ago
  Not if the Mac you're reading on (e.g. kiosk/library computer) is potentially compromised.
  - mseebach 8y ago
    If you decrypt an encrypted filesystem on an untrusted computer, it's game over already then. And assume that your passphrase is compromised as well.
    - fulafel 8y ago
      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.
      - mseebach 8y ago
        > 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.
gruez 8y ago
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 8y ago
  I would expect it to store the thumbnails together with the files. Then again, this is Apple we're talking about...
trasz 8y ago
Caches it where, on the root filesystem? Which is encrypted by default since... ages?
- klodolph 8y ago
  It’s not encrypted by default. FDE is something you have to enable.
  - Reason077 8y ago
    It's the default in the macOS installer. You have to uncheck a check box to turn it off.
    - kstrauser 8y ago
      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 8y ago
        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 8y ago
        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.
deleted 8y ago
[deleted]
mbell 8y ago
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 8y ago
  > 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.
  - deleted 8y ago
    [deleted]
  - pvg 8y ago
    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 8y ago
      > 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.
21 8y ago
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.
Skunkleton 8y ago
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 8y ago
  We changed the URL after this was posted.
ddtaylor 8y ago
That rm command won't clean anything you would need to use shred first.
- unilynx 8y ago
  Shred and similar tools may not work properly on SSD with all the sector remapping going on, and most current Macs have SSDs for their boot volumes
- Buge 8y ago
  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 8y ago
    >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 8y ago
      Generally I don't believe that TRIM securely erases anything. https://security.stackexchange.com/questions/109916/does-the-ata-trim-command-irrecoverably-delete-data-on-an-ssd https://security.stackexchange.com/questions/109916/does-the...
walrus01 8y ago
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.
ThbTs4wbXC9Qjv 8y ago
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.
peterburkimsher 8y ago
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
armitron 8y ago
More low SnR spam from Patrick Wardle.

176 points by oedmarap 8y ago

> 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 8y ago
This is one of my favorite features for sifting through a large number of pictures.
- iaml 8y ago
  What hardware do you have? On my mbp 2016 15' it's painfully slow compared to xnview when I want to browse through a lot of images.
  - maxxxxx 8y ago
    I have a 2014 13" MBP.
  - TheAceOfHearts 8y ago
    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.
    - iaml 8y ago
      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.
  - reaperducer 8y ago
    Sometimes it helps to "encourage" Spotlight to reindex your files, creating new Quicklook thumbnails.
- ClassyJacket 8y ago
  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.
  - systemtest 8y ago
    Do you store the full iCloud contents on your drive or does it download on demand? I am not sure if Quicklook works on the latter
  - thisacctforreal 8y ago
    You can set the screenshot destination using: defaults write com.apple.screencapture location ~/Screenshots killall SystemUIServer There are a few handy things you can configure using defaults(1).
  - coatmatter 8y ago
    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.
  - coatmatter 8y ago
    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.
mikestew 8y ago
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?
- JonathonW 8y ago
  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).
  - mikestew 8y ago
    Yeah, I was being somewhat rhetorical. :-) 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.
    - jiveturkey 8y ago
      blogspam is referring to the fact that TFA is regurgitating a blog (and capturing revenue) without adding value. too bad the original blog (if it is the original) is undated.
      - wlesieutre 8y ago
        It says "17 days ago" and if you hover changes to "02 Jun 2018" (at least on desktop)
    - mr_spothawk 8y ago
      > cached images go in /var on the boot drive 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.
      - cristoperb 8y ago

danieldk 8y ago

Blogspam for: https://wojciechregula.blog/your-encrypted-photos-in-macos-cache/ https://wojciechregula.blog/your-encrypted-photos-in-macos-c...

dang 8y ago
Thank you. We changed to that from https://www.bleepingcomputer.com/news/apple/macos-breaks-your-opsec-by-caching-data-from-encrypted-hard-drives/ https://www.bleepingcomputer.com/news/apple/macos-breaks-you.... Edit: actually the other original source it links to seems to have more information, so maybe we'll use that instead.

ryanlol 8y ago

This is to be expected on essentially any OS.

Osiris 8y ago
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.
- bumblebritches5 8y ago
  Great idea, spam the shit out of every folder with useless files even more. that's just what we need.
- niftich 8y ago
  That's in Windows XP. 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.
- gruez 8y ago
  and that's how you end up with annoying shit like __MACOSX and ._caches folders everywhere
  - cptskippy 8y ago
    You don't like sacrificing 1% of your SD Card space to Finder?
    - ubercow13 8y ago
      Why would you want your OS to start writing to the SD card just because you browsed around it in Finder?
    - mort96 8y ago
      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

anderiv 8y ago

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

r00fus 8y ago
Not if the Mac you're reading on (e.g. kiosk/library computer) is potentially compromised.
- mseebach 8y ago
  If you decrypt an encrypted filesystem on an untrusted computer, it's game over already then. And assume that your passphrase is compromised as well.
  - fulafel 8y ago
    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.
    - mseebach 8y ago
      > 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.

gruez 8y ago

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 8y ago
I would expect it to store the thumbnails together with the files. Then again, this is Apple we're talking about...

trasz 8y ago

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

klodolph 8y ago
It’s not encrypted by default. FDE is something you have to enable.
- Reason077 8y ago
  It's the default in the macOS installer. You have to uncheck a check box to turn it off.
  - kstrauser 8y ago
    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 8y ago
      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 8y ago
        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.

deleted 8y ago

[deleted]

mbell 8y ago

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 8y ago
> 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.
- deleted 8y ago
  [deleted]
- pvg 8y ago
  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 8y ago
    > 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.

21 8y ago

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.

Skunkleton 8y ago

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 8y ago
We changed the URL after this was posted.

ddtaylor 8y ago

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

unilynx 8y ago
Shred and similar tools may not work properly on SSD with all the sector remapping going on, and most current Macs have SSDs for their boot volumes
Buge 8y ago
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 8y ago
  >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 8y ago
    Generally I don't believe that TRIM securely erases anything. https://security.stackexchange.com/questions/109916/does-the-ata-trim-command-irrecoverably-delete-data-on-an-ssd https://security.stackexchange.com/questions/109916/does-the...

walrus01 8y ago

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.

ThbTs4wbXC9Qjv 8y ago

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.

peterburkimsher 8y ago

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

armitron 8y ago

More low SnR spam from Patrick Wardle.