Live data from Hacker News

MacOS FileVault2 Password Retrieval

blog.frizk.net

71–80 of 90 posts

Re: MacOS FileVault2 Password Retrieval

#71
post #4

Things like this are a reason I unhesitatingly recommend that people stick with their OS's built in FDE: 1. FDE is extremely limited. This particular attack is a clever abuse of sleep/reboot cycles, but of course people intimately familiar with FDE know that if a laptop is sleeping but not shut down it's already perilously close to the boundary at which FDE breaks down. And, of course, once it's woken up and unlocked…

> And, of course, once it's woken up and unlocked --- which every attacker who actually challenges FDE can arrange for, all bets are off. I'm not sure what you mean by that? Do you mean that the attacker can force you to wake up and unlock the computer? In that case FDE is not moot anyway, no? For me, the reason I use FDE is in the case I lose or forget my computer somewhere, I do not want the legal liabilities with…

> Do you mean that the attacker can force you to wake up and unlock the computer? In that case FDE is not moot anyway, no?

The Windows lockscreen has had a law enforcement backdoor since at least Windows XP. This effectively makes FDE worthless on Windows if you only put your computer to sleep instead of a full shutdown.

Re: MacOS FileVault2 Password Retrieval

#72
post #26
post #22

I'm interested in how this was fixed. Is the update an EFI update which disables DMA or does it with IOMMU? Or is the memory just overwritten on boot? I'm also quite surprised they leave the password in memory in multiple locations. - Assuming the password is only used to derive the KEK for the actual key.

This interests me, too. I can only assume, since disabling DMA would imply a huge performance hit (and quite likely many broken devices?), that the update enables the IOMMU right from the system start, probably directly in the firmware, and has nothing/only a whitelist mapped, with further mappings only explicitly enabled by drivers?

I wonder if the chipset can't do a sort of DMA emulation, or DMA with conditions versus the sort of free-for-all stuff you'd see with things like FireWire.

Re: MacOS FileVault2 Password Retrieval

#73

Good hack, good on Apple for getting fixes out. But what worries me somewhat is that the tools for mitigation for these families of attacks include a lot of technologies that are traditionally opposed by the community here on the grounds that it "takes away control from the user. I'm not sure how we balance out those tensions, but attacks like this sure as heck concern me about my homebuilt machine. I do my best not…

What encryption are you using? I was under the impression that FV2 (or any other full disk encryption solution) does not work on a Hackintosh

Re: MacOS FileVault2 Password Retrieval

#74

Good on Apple for "completely" fixing this, according to the authors. But am I wrong to wish for more plain-English acknowledgement of the problem and reassurance in Apple's 10.12.2 release notes? i.e. https://support.apple.com/en-ca/HT207423 Anyways, at this point in time it's nice to read (from the authors of the exploit): "The mac is now one of the most secure platforms with regards to this specific attack vector.…

I read through the release notes, and I didn't see any mention of this issue at all. The fix must have been a EFI firmware update (my Mac did restart multiple times during the update, so this sounds plausible), but nothing is mentioned about this anywhere.

Re: MacOS FileVault2 Password Retrieval

#75
post #26
post #22

I'm interested in how this was fixed. Is the update an EFI update which disables DMA or does it with IOMMU? Or is the memory just overwritten on boot? I'm also quite surprised they leave the password in memory in multiple locations. - Assuming the password is only used to derive the KEK for the actual key.

This interests me, too. I can only assume, since disabling DMA would imply a huge performance hit (and quite likely many broken devices?), that the update enables the IOMMU right from the system start, probably directly in the firmware, and has nothing/only a whitelist mapped, with further mappings only explicitly enabled by drivers?

[deleted]

Re: MacOS FileVault2 Password Retrieval

#76
post #26

Earlier quoted context omitted.

This interests me, too. I can only assume, since disabling DMA would imply a huge performance hit (and quite likely many broken devices?), that the update enables the IOMMU right from the system start, probably directly in the firmware, and has nothing/only a whitelist mapped, with further mappings only explicitly enabled by drivers?

I wonder if the chipset can't do a sort of DMA emulation, or DMA with conditions versus the sort of free-for-all stuff you'd see with things like FireWire.

That's what an IOMMU does.

Without an IOMMU devices on extension buses directly address physical memory.

With an MMU the host CPU creates a virtual address space for devices and can thus limit access to the main memory (conveniently also allows passing devices to VM guests), much like virtual memory for processes/VMs.

Re: MacOS FileVault2 Password Retrieval

#77
post #13
post #4

Things like this are a reason I unhesitatingly recommend that people stick with their OS's built in FDE: 1. FDE is extremely limited. This particular attack is a clever abuse of sleep/reboot cycles, but of course people intimately familiar with FDE know that if a laptop is sleeping but not shut down it's already perilously close to the boundary at which FDE breaks down. And, of course, once it's woken up and unlocked…

I don't know about Apple but Microsoft has a pretty nasty way of handling user's Bitlocker keys. If you use a Microsoft account, your key is automatically backed-up in Microsoft's cloud. Red flag #1. Also, as the recent Bitlocker bypass "bug" showed us, Microsoft has some way of bypassing Bitlocker encryption when it performs updates on the system. I don't know if they have some kind of key escrow or what, but either…

It is possible to suspend Bitlocker. This works by writing the key somewhere on the disk. Then when you reenable it the key is removed again. This is necessary if you normally store the key in the TPM chip and you're going to do something that will break its trust, like updating the BIOS.

The recent update would suspend Bitlocker during the installation which is not a nice thing to do automatically.

It doesn't mean Microsoft has the keys though.

Re: MacOS FileVault2 Password Retrieval

#78
post #9

Earlier quoted context omitted.

> And, of course, once it's woken up and unlocked --- which every attacker who actually challenges FDE can arrange for, all bets are off. I'm not sure what you mean by that? Do you mean that the attacker can force you to wake up and unlock the computer? In that case FDE is not moot anyway, no? For me, the reason I use FDE is in the case I lose or forget my computer somewhere, I do not want the legal liabilities with…

Even though the computer may be “locked”, if the OS is running and accessing the disk, it means that the key is present somewhere in memory. There are various methods of accessing this key, the fallback brute-force method being the ( https://en.wikipedia.org/wiki/Cold_boot_attack ). The method from the article only removes the need to physically remove and cool the memory chips.

There are no memory chips to remove on recent Macs, making this attack much harder if not impossible to perform.

Re: MacOS FileVault2 Password Retrieval

#79
post #73

Good hack, good on Apple for getting fixes out. But what worries me somewhat is that the tools for mitigation for these families of attacks include a lot of technologies that are traditionally opposed by the community here on the grounds that it "takes away control from the user. I'm not sure how we balance out those tensions, but attacks like this sure as heck concern me about my homebuilt machine. I do my best not…

What encryption are you using? I was under the impression that FV2 (or any other full disk encryption solution) does not work on a Hackintosh

It unfortunately doesn't work on the boot volume of a Hackintosh, but pretty sure it does on other volumes.

Re: MacOS FileVault2 Password Retrieval

#80

Although this is an exploit and should be fixed, FDE rarely works if your computer is on / sleeping. Same thing with the iPhone. Even though it has solid FDE, there have been exploits if the phone is on (even with a passcode, etc). Turning off your device is the best protection, even if you have FDE.

What do you mean ? This was a bug, but FV2 is clearly designed as FDE that works even if the computer is sleeping.
Post reply on HN