Safari, Hold Still for NaN Minutes!

Javier Jimenez and Vignesh Rao, vulnerability researchers at Exodus Intelligence, examine Safari's JavaScript engine, JavaScriptCore, and why it changes so often. They focus on one large upstream commit that reworked how for-in enumeration works, and show that it contained several bugs, some of which fed into their exploit. The opening covers how JavaScriptCore represents values using NaN boxing, how its tiers of compilation work, and how a differential fuzzer built on an existing tool was adapted to target the JIT.

The middle of the talk walks through the bugs. The first is a register spill mistake in the JIT that gave a limited information leak, found through fuzzing. The second, found by reading code near that bug, comes from floating-point values loaded from typed arrays that are not checked for NaN, letting an attacker craft an invalid pointer. The third is a mismatch in a strict-equality comparison in the optimizing compiler that the speakers turned into a brute-force oracle. Combining these, they defeat ASLR by brute force, then reduce the search space by exploiting pointer alignment and web worker heap layout, bringing the search down to a few seconds.

The closing section covers how the pieces combine into arbitrary read and write in the renderer, and notes that PAC and APRR mitigations would still need to be bypassed for full code execution. They end with takeaways: fuzzing and code auditing complement each other, large commits deserve scrutiny, and the browser landscape changes quickly with frequent upstream updates.