The PoC demo fails when using either Chromium or Firefox on HardenedBSD.
edit Add Chromium to the list.
New results: The PoC works against Chrome and Edge in a Win10 VM running on top of HardenedBSD (using bhyve as the hypervisor). So the PoC does indeed work in a virtualized environment.
The PoC is very platform-dependent, but it shouldn’t be much work to adjust AFAIU.
Or are you saying there are some hardening measures in HardenedBSD that you think ought to protect you?
Though I’m not claiming they do indeed fully/partially mitigate this particular PoC, but there’s a few HardenedBSD-specific things that could help. We randomize the location of per-thread stacks, mitigating thread-thrashing. In my specific cases, The amount of entropy we apply to the memory layout on amd64 is rather large. We also instruct the default heap implementation (jemalloc) to zero-fill by default. And we enable llvm’s variable auto-init (init to zero) by default. And there’s probably something I’m forgetting.
I’m wondering if the combination of all those helps harden against these kinds of attacks. I’d love to see an academic paper on that.
How quickly does yours fail? I keep messing around with the options but sometimes it just does nothing at all and other times it appears to be trying and reports a failure.
On Firefox, it took a few seconds. That’s likely because I’ve reduced the precision timer to 5 seconds on Firefox. On Chromium, the failure is instant.
Just another little update in case anyone cares: The only thing I have managed to do on MacOS (M1 Air) is the L1 Cache Timer part. At least it shows something on the graph. The Memory Layout Inference fails, stalls at running, or crashes Safari. Of course that means the actual demo doesn’t do anything either.
I can’t get it to do anything on OpenBSD-current in Chromium.
It’s definitely doing something on MacOS 11.2.3 in Safari but doesn’t seem to really work that well.