RET2 Systems, a security research firm, writes about vulnerability research, exploitation, reverse engineering, and hardware hacking.
HN links it for technical security write-ups, such as the JavaScriptCore exploits, PAC discussion, and the Xbox JTAG hacking post.
There's not a lot of comments here, so I'll give a tl;dr:
They found a "use after free" bug in JavaScriptCore due to some asnyc GC and used it to get RCE in Safari at Pwn2Own. By making a large array of arrays, and then reversing them, they interfered with the "mark" part of "mark and sweep", resulting in some of the arrays not being marked and therefore being swept (freed) and used for other things. Pretty picture showing what's going on: http://blog.ret2.io/2018/06/19/pwn2own-2018-root-cause-analysis/#arrayreverse-considered-harmful
some more details:
- this was found with a fuzzing tool
- they make a large array of arrays (~20k)
- they map over the array of arrays and reverse the arrays inside it
- they print out the contents of all the arrays and find that some of the objects they are printing are not arrays, but are an entirely different javascript object: promises (this is a symptom of the bug)
- they use a very nice debugging tool[0] that let's them step backwards in time, this proves invaluable as they can start with the symptoms of the bug and then go backwards to see what has caused them
- they discover that the memory of the arrays is being marked as "not used", getting freed by GC, and then used by (unrelated) promises. this is a "use after free" bug and they're very serious (this one is used to get RCE at pwn2own)
- this happens because the GC is marking this as used in an async manner, so when they make their large array of arrays, not all of the memory…
Having grokked the abstract, I feel like can speculate a bit as to what is going on. Take this with a grain of salt; I have no clue what has actually been discovered.
I believe that the researchers have found a way to remove PAC as a barrier to exploitation by disclosing PAC verification results via speculative execution. This is only useful to attackers going after a target that uses PAC, and those attackers will need to have another vulnerability that enables them to hijack control-flow through modifying pointers to code that are located in memory.
The attackers can use this new Pacman vulnerability as a crash-free oracle that says whether their forged pointer worked, and once they find a working one, they can use that to hijack control flow.
PAC (or Pointer Authentication) is a security feature found in recent iPhones, the Apple Silicon Macs, and the Graviton3. It is intended as a defense against control-flow hijacks. It works by signing pointers found in memory with one of five keys that are known only to the processor. Before the pointer is used, the processor should be instructed to "authenticate" the pointer by checking the pointer's signature using its private keys. To prevent simple reuse of one authenticated pointer used in one place to a pointer used in another place in the program, code can provide a "context" value to be used during the authentication.
A great resource for learning about PAC and its usage in the Apple platforms is at [1] (it links to other…
Pointer authentication has been around for several years already. As with many things in hardware, though, it takes time for the software ecosystem around it to mature. Still, I've found it to be quite influential.
Here are a couple "real world" examples--
Project Zero had a blogpost about some of the weaknesses on the original Pointer Auth spec [0], and even had a follow up [1].
Here is an example of what some mitigation might look like, showing how gets(), which is a classically trivially vulnerable primitive, becomes not-so-trivial (but still feasible enough to do in a blogpost, obviously) [2].
Cost-wise, in terms of both hardware and software, it's rather cheap. The hardware to support this isn't too expensive, about on par with a multiplier. On the software end, like I said, it's taken some time to mature and gotten to a pretty good state IMO, with basically all compilers providing simple usage since 2019-- just turn on a flag!
ARM also did a performance vs. ROP gadget reduction analysis [3]. The takeaway is, as others have mentioned, while it doesn't completely mitigate, it does heavily increase the complexity for rather cheap.
In fact, I'm rather annoyed Amazon didn't include this feature on Graviton2, and to claim it as new or innovative on their end feels just like marketing speak. Any CPU that claims to be ARMv8.5-a compliant *must* have this feature, and that's been around for quite a few years now.
[0]:…
No. This one. [0].
Even before that, there are several other sandbox escapes that predated the one you posted. [1] [2] and this one [3] can be used to trivially escape its sandbox with either of these vulnerabilities.
So it is not the magical silver bullet one may easily think it is.
[0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645
[1] https://blog.ret2.io/2021/06/02/pwn2own-2021-jsc-exploit/
[2] https://issues.chromium.org/issues/40091185
[3] https://phrack.org/issues/72/10_md#article
HN hasn't focused on those topics in a long time, they rarely are on the front page. Skip the top 20 articles and you'll start to see some interesting content instead of all the VC & AI drivel.
Hackaday is a content aggregator site that usually has more content on these topics - https://hackaday.com
Or there are still some good old blogs out there with RSS feeds http://www.righto.com/ http://oldvcr.blogspot.com/ https://blog.ret2.io/
Check out:
https://blog.ret2.io/2018/09/11/scalable-security-education/ These guys have built an epic b0f research education platform - could be also sold as a cloud-based research platform for vuln developers
Another one is https://www.youtube.com/channel/UClcE-kVhqyiHCcjYwcpfj9w/videos for mostly C/C++ overflow type education