alias sleepsafe='sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25'
alias sleepfast='sudo pmset -a hibernatemode 0'
alias sleepdefault='sudo pmset -a hibernatemode 3'
Day-to-day, I use `sleepfast`, which is faster than the default hybrid sleep, because it doesn't spend time copying the contents of memory to disk.
I very rarely switch to `sleepdefault` which is the insecure and slower hybrid sleep.
This has been a known issue for years
Edit: After some time and some tries, idk why but it started working.
Commands that I used:
$ sudo pmset -a darkwakes 0
$ sudo pmset -a standby 0
$ sudo pmset -a standbydelay 0
Also check that powernap is disabled.
If the laptop is disconnected from AC, it hibernates. It will switch to hibernate if power is removed while already sleeping. If I want to force a hibernate manually, I just pull the power before closing the lid.
Are there any caveats that I should be aware of before just stealing this to use for myself?
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 --- which every attacker who actually challenges FDE can arrange for, all bets are off.
2. When flaws like this are found, the OS vendors have much more recourse than third parties do, which is why this post concludes by saying that Macs are now the most secure laptop platform with respect to DMA attacks against FDE.
Use FDE! Enable it on all your machines! But try not to rely on it, and don't waste too much time optimizing it.
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 way - red flag #2.
Of course, I'd say the bigger problem is that Microsoft doesn't even give the majority of Windows users the option to encrypt their computers, by restricting Bitlocker to expensive computers and Windows licenses, while every other operating system does. So the advice to "just use the built-in FDE" doesn't work for the majority of Windows users.
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.
My girlfriend was shocked at how easily I was able to "hack" her laptop and reset the forgotten password by changing whatever accessibility.exe to cmd.exe.
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 a thief accessing my customer's source code.
* Casual, opportunistic attackers who will steal any available laptop.
* Targeted attackers who want your laptop in particular.
Against a casual attacker, even if your laptop is stolen unlocked, it's not going to be carefully kept unlocked. Doing so requires sophistication, care, and extra risk. Instead, the laptop is just going to get wiped.
Against a targeted attacker, like the FBI when they took down Ross Ulbricht (who FDE'd his laptop), the attacker will simply wait until the laptop is unlocked.
 "On the afternoon of October 1, 2013, officers watched as Ulbricht entered the library and made his way up the stairs to work by the window at a desk in the science fiction section, Kiernan recalled. Meanwhile, sitting on a bench outside of the library, homeland security officer Jared Der-Yeghiayan — who had been working undercover as Silk Road employee "cirrus" — initiated a chat with Ulbricht, requesting that he log in to Silk Road's back end to fix a technical problem. As soon as Der-Yeghiayan could confirm that Ulbricht was logged into the site, FBI agents entered the library.
Two plainclothes FBI agents, one male and one female, walked up behind Ulbricht and began arguing loudly. This staged lovers' tiff caught Ulbricht's attention long enough to distract him from his laptop. As soon as Ulbricht looked up, the male agent reached down and slid the computer over to his female colleague, who quickly snatched it up and handed it over to Kiernan for further investigation."
In retrospect, it's a pretty obvious attack vector.
For the extremely security-conscious, it could even be a kind of fail-deadly (https://en.wikipedia.org/wiki/Fail-deadly) feature that wipes the phone.
The right approach is to recognize what FDE is good at (minimizing the risk that casual thieves will get data in addition to valuable parts, and protecting computers that can frequently be powered all the way off from even advanced attackers), and then use something better to protect sensitive data.
A potential counter measure is for the machine to periodically encrypt itself again and prevent use until a password/key is supplied ("clamming up"). This would prevent an attacker who snatched a logged-into computer from having unbounded carte blanche access to the machine. I'm envisioning something that every 10 minutes locks itself.
Does anyone know of such a solution?
I'd bet that if you turn all that stuff off, they keys are scrubbed. That could be a good compromise instead of turning the computer completely off all the time.
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.
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."
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 to keep any important keys there.
Hint: it probably won't.
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.
sudo firmwarepasswd -setpasswd -setmode command
enter in a password to lock down Option ROM, reboot. Now you're protected.
source, the hacker-now-Apple-developer: https://twitter.com/XenoKovah/status/809418554428657666
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.
Anyone who wants to stay secure should want to upgrade their system...
I'm still using it instead of Sierra because of Karabiner but this could force me to upgrade.
That vulnerability seems to be a pretty obvious oversight. I remember hearing about DMA (in the context of Firewire) as an attack vector since people first started talking of Truecrypt and Filevault and scrubbing the memory seems obvious... It's worrying that this could have been overlooked by Apple's engineers.
I haven't tried it because I can't find the wireless mouse that I needed Karabiner for, but my impression was it has most of the functionality running, especially the key/button remapping which seems to be their biggest use case.
I also have both Shift keys bound to () when pressed alone and Shift when pressed in combination with other keys.
Looks like it's not in master, but somebody has builds that do it.
This is the closest I can find on there to this issue and the fix is Sierra only:
Available for: macOS Sierra 10.12.1
Impact: A local attacker may be able to read kernel memory
Description: A memory corruption issue was addressed through improved memory handling.
CVE-2016-7608: Brandon Azad
Attribution on that doesn;t look right; TFA was by "Ulf Frisk" who was nowhere on that page.
Why would someone be using El Capitan still, some may ask. Well there is software not updated for Sierra yet. For example, GPG for Mac is not yet ported over.
A nice big finger from Apple to those of us that won't upgrade.
Chances that someone use that device to hack your computer: 0
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.
If it's not encrypted, connecting another computer to it with an appropriate cable will let you use it as a remote disk, leaving no real traces that it was touched.
But even in sleep mode, a FDE computer is still better than no encryption at all.
Not sure these are mitigating the OP issue though. Still, can't be bad to harden macOS a little bit.
This has always been the way to protect a computer that uses full disk encryption. Turn it off. Sleep mode will not protect you.