Needs to be running on the host already (nothing remote), achieves full system compromise by itself, but logs you out in the process. Can wait for logout though and is fast enough to run on shutdown/reboot until 10.13.1. On 10.13.2 it takes a fair bit longer (maybe half a minute) after logging out, so if your OS logs you out unexpectedly... maybe pull the plug? And maybe don't download & run untrusted software until the bug is patched (or, you know, ever)? Also, any decent antivirus shouldn't take long to add this to their malware definitions.
Not sure if this is HN-level, but... I hope it's understandable.
You can just press and hold the power button to shut a Macbook off. I assume this is a hardware level interrupt as I’ve never seen it fail. Granted not quite as satisfying as physically pulling the plug!
Apple actually creates some signatures in house with “XProtect”, but I’m not sure they do the same for raw privesc exploits. I’m also not sure how thorough they are with their signature creation...
Some of them. But mostly of prevent forwarding windows-malware. Most corporate-managed stuff has endpoint protection, and most end-users are covered by GateKeeper, XProtect and the standard Google safe browse whatever it's called thing. And since most of the basic users simply use webmail, that vector is covered as well. It's not as bad as it once was.
Looks like a Time of Check vs Time of Use (TOCTOU) type vulnerability. User controlled memory is read and used later by kernel space - time in between read and use can be used to overwrite it from user space, typically by exploiting and winning race conditions.
I haven't completed reading this one thoroughly but one example like this is kernel performing access checks on user requests asking it to perform some action - user space would ask for something it is permitted to do at first, kernel would read it and proceed to perform access check. User space meanwhile writes something different to the original memory area that specified the action - this time something privileged - kernel comes back successfully performing the access check for the older action and now executes the privileged action from the overwrite.
j00ru/project zero used modified Bochs (BochsPWN) to detect double memory fetch patterns to find similar vulnerabilities in the Windows kernel.
It's actually neither TOCTOU nor double fetch, it's not checking anything at all, it's just write-then-fetch using shared (untrusted) memory to store trusted information. Sure similar in nature, but not really fitting any common name...
It looks like a total system compromise is possible. Under what conditions? Any ways to ensure we don't get pwned?