Super easily. I don't use it much now, but I had an app that had issues and was requiring me to kill and restart the coreaudio system -- set up an Alfred workflow and keyword, and could run the terminal command in well under 5 seconds at any time.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 'Quick Look' Bug Can Leak Encrypted Data Through Thumbnail Caches
- Thread starter MacRumors
- Start date
- Sort by reaction score
… and whining about people makes you so much better than them. Right?
While we are at fixing this Quick Look issue, could we possibly make QL work with other video file types please??? This is such an awesome feature but as soon as a video file isn't H264 you can't view it without using VLC or something... Lets fix that about Quicktime too.
R.I.P. Perian.
R.I.P. Perian.
This is news? I thought this had been brought up years ago?
It's unwise to use your main account for pr0n, even if your stash is on an encrypted external drive. Set up a separate user account for that. And if you're extra paranoid, with a bit of jiggery pokery you can store a user account inside an encrypted DMG that you mount before logging into it.
It's unwise to use your main account for pr0n, even if your stash is on an encrypted external drive. Set up a separate user account for that. And if you're extra paranoid, with a bit of jiggery pokery you can store a user account inside an encrypted DMG that you mount before logging into it.
It's not whining when it's as clear as day that it's a bug. It's people like you that ruin this site because you worship Apple and all that it does and see absolutely no wrong.
Is that your excuse when anything you have doesn't do what it should be doing? "Oh, you could fix it by doing ____." You must be a blast at parties.
Mac sales would not be flat if Apple bothered to launch new and upgraded models... I'm refering to Mac Mini, Mac Pro and MacBook Air (or another affordable Macbook).
The lock screen is not vulnerable, per se, it's just that other than preventing access to the GUI it serves no other purpose. (You can also lock your keychain when the lock screen activated but that isn't on by default and I doubt most change the default setting.) The hard drive encryption key is still in active memory and thereafter all the contents of the drive are accessible.
When putting the Mac to sleep the issue persists because the encryption key is still stored in memory (that's how you can wake the computer so quickly). You can change the sleep behaviour (read this document for the steps, it's easy to do but requires use of the Terminal); doing so dramatically increases the wake from sleep time so there's as tradeoff between convenience and security (as is always the case).
Are you certain this did not change with one of the recent OS upgrades, possibly Sierra, I would have to dig through Google but I remember reading that Apple altered something that prevented any access from sleep mode, remember how it was recommended to set up an additional password by stopping the Macbook upon rebooting, I believe it was a firmware password, this was part of that possible memory info leak, that was corrected, I think that pertains or applies to the problem you are referencing.
This warning seems like a bit of a hot mess. I mean it says that it’s an unencrypted collection but then says that if the drive is encrypted then so is the collection cause it’s part of the user data. So anyone that can access the computer to change the user password via terminal can get to all the files and doesn’t even need the Quick Look files. And no where does it say that this collection, unlike the other user data, can magically be accessed remotely, even when the rest of the data can not be. It would require either physical access or an open remote access port and access to the user (which again means you can access the original files anyway).
So what’s the ‘bug’ here. They really haven’t made that clear
[doublepost=1529433826][/doublepost]
That’s what it sounds like, or am I also missing something. Is this information in the system library perhaps. In which case it would not be encrypted with FileVault to my knowledge because that only covers user files. And a firmware password only stops some forms of booting, erasing and perhaps changing user passwords. If this data was in the system library even a firmware password might not encrypt it. But it would still require physical or open remote access to the computer
[doublepost=1529434158][/doublepost]
If someone breaks in and steals your computer and can access it to see the quick look files then they can probably access the main files also. So quick look being an issue isn’t really an issue now is it.
So what’s the ‘bug’ here. They really haven’t made that clear
[doublepost=1529433826][/doublepost]
That’s what it sounds like, or am I also missing something. Is this information in the system library perhaps. In which case it would not be encrypted with FileVault to my knowledge because that only covers user files. And a firmware password only stops some forms of booting, erasing and perhaps changing user passwords. If this data was in the system library even a firmware password might not encrypt it. But it would still require physical or open remote access to the computer
[doublepost=1529434158][/doublepost]
If someone breaks in and steals your computer and can access it to see the quick look files then they can probably access the main files also. So quick look being an issue isn’t really an issue now is it.
LOL "can leak"
Headline writer mispelled "LEAKS".
OS X is as chaotic and patchwork now as the hardware it runs on.
COME ON TIM time to emerge from your money counting room and do some CEOing.
Or step aside and give the helm back to a technologist.
It's not like you won't be farting through silk for the rest of your life anyway.
Why insist on running the company farther into the ground?
Headline writer mispelled "LEAKS".
OS X is as chaotic and patchwork now as the hardware it runs on.
COME ON TIM time to emerge from your money counting room and do some CEOing.
Or step aside and give the helm back to a technologist.
It's not like you won't be farting through silk for the rest of your life anyway.
Why insist on running the company farther into the ground?
Wouldn't this mean the cache remains even if external drive is physically disconnected from machine?
The only thing stopping you from viewing then would be you can't get at it via Finder...
It users are worried about this, then just think how Spotlight works by indexing the same way. I guess the 'attack surface' would be limited to your internal drive, in part.
The only thing stopping you from viewing then would be you can't get at it via Finder...
It users are worried about this, then just think how Spotlight works by indexing the same way. I guess the 'attack surface' would be limited to your internal drive, in part.
Yes.
…well, the real way to do so is to encrypt the drive, which you should probably be doing anyway.
No, Spotlight's index is on the specific volume.
Last edited by a moderator:
I'm pretty sure I'm correct; and that article on GitHub I linked to is kept up to date. However, please do reply if you find information that clarifies the issue as I am interested in reading it and also want to know if I'm mistaken.
I'm pretty sure I'm correct; and that article on GitHub I linked to is kept up to date. However, please do reply if you find information that clarifies the issue as I am interested in reading it and also want to know if I'm mistaken.
https://forums.macrumors.com/conversations/secure-erase-question.814314/
Check the last post, you could ask that poster as he is one of the few here that will take the time to help. He wrote that the issue was patched in OS Lion 10.7.2
Also check out https://security.stackexchange.com/...levault-2-while-the-computer-is-in-sleep-mode
This information posted there:
Apparently FileVault 2 is secure against a DMA Attack if the screen isn't unlocked, since 10.7.2 (so make sure you're running Lion). My guess is that on sleep the keys are encrypted with your password, rather than just left in memory.
I'm assuming that it also means it is protected against a Cold Boot Attack too.
The only sources I could find on it is this blog post.
And this:
In older versions of Mac OS X, an attacker with physical access to the machine could plug in via Firewire (or Thunderbolt) and use DMA attacks to gain access to memory. This would let the attacker slurp out your password and thus defeat FileVault 2's protection. However, this vulnerability was fixed in Mac OS X 10.7.2.
Later versions of Mac OS X have largely eliminated this vulnerability. The attack is still possible if a user is logged in and the machine is unlocked. However, when the screen lock kicks in, the OS enables extra protections that prevent this attack.
References:
- "OS X Lion disables DMA when the user is logged out/screen is locked. Attacking will only work while the user is logged in, or if user switching is enabled. The user switching trick only works for versions before 10.7.2, where the vulnerability is patched." http://www.breaknenter.org/projects/inception/
I think these are talking about slightly different things. One is acquiring the actual encryption key for the drive from memory, which OS X attempts to protect against. The other is whether the contents of the drive are readable because the encryption key is in memory (which is what we're talking about). It seems like the same thing, but it's not.
When the encryption key is in memory, the contents of the drive are readable so anyone with access to the computer at the time could get files off the drive. These articles are saying that OS X/macOS tried to protect against the encryption key itself from being retrieved from memory, but that doesn't change the fact that the key is still in memory and therefore the hard drive's contents are readable.
When the key is expelled from memory, the hard drive's contents are not readable.
By default, expelling the key from memory happens on shutdown. It does not happen during hibernate or sleep. The github article and that stack exchange thread talk about that. If you want the behaviour changed, you need to use the Terminal and pmset to configure different sleep behaviour and have the key removed during hibernate.
If you get the encryption key from memory, then you could pull the physical drive from the computer and decrypt it when and wherever you wanted. There are some protections in place to prevent this in the operating system.
What we're talking about is reading an encrypted drive that's unlocked and running on a computer. The encryption process happens at a low level so it's transparent to applications, users, etc. If the key is in memory the drive is readable. Including quick look caches.
No, the logic is not that FileVault doesn't provide protection. The logic is that to exploit the vulnerability it you need to local access. So technically FileVault in itself gives mitigation, however if someone by some means gets local access, information that you thought was gone (by deletion e.g.) can still be accessed.
Yes, FileVault is good and protects us, at the same time it's good to understand that information is stored that you might not want to have stored and it is accessible by local access.
[doublepost=1530291288][/doublepost]
Noone said that.