PS4 Jailbreak: Hacker TheFloW drops big hint about the 7.55 exploit
Since TheFloW disclosed a kernel exploit for the PS4, compatible with firmware 7.55, the scene has been hard at work to try and reproduce the code (The disclosure process from Sony did not allow TheFloW to release a full proof of concept). Notably, Sleirsgoevy and SpecterDev have both shown they were actively looking into the vulnerability, with SpecterDev in particular regularly sharing his progress on twitch.
Nonetheless, progress has been slow since the vulnerability was publicly revealed in January, and TheFloW had remained pretty silent on the issue (it’ possible the hacker is under some NDA with the bug bounty platform used by Sony, as a condition for the rewards).
That was until today. On twitter, the hacker has shared what appears to be a hint related to the IPV6 vulnerability used for the recent exploit.
Tip: Leverage that with another bug. https://t.co/mel4apfaJl
— Andy Nguyen (@theflow0) March 1, 2021
The hacker is pointing to a different FreeBSD issue, a patch (source) for a buffer overflow in ip6_get_prevhdr. The issue, specifically, is described as follows:
Fix a buffer overflow in ip6_get_prevhdr. Doing mtod(m, char *) + len is wrong, an option is allowed to be located in another mbuf of the chain. If the offset of an option within the chain is bigger than the length of the first mbuf in that chain, we are reading/writing one byte of packet- controlled data beyond the end of the first mbuf. The length of this first mbuf depends on the layout the network driver chose. In the most difficult case, it will allocate a 2KB cluster, which is bigger than the Ethernet MTU. But there is at least one way of exploiting this case: by sending a special combination of nested IPv6 fragments, the packet can control a good bunch of 'len'. By luck, the memory pool containing clusters does not embed the pool header in front of the items, so it is not straightforward to predict what is located at 'mtod(m, char *) + len'. However, by sending offending fragments in a loop, it is possible to crash the kernel - at some point we will hit important data structures. As far as I can tell, PF protects against this difficult case, because it kicks nested fragments. NPF does not protect against this. IPF I don't know. Then there are the more easy cases, if the MTU is bigger than a cluster, or if the network driver did not allocate a cluster, or perhaps if the fragments are received via a tunnel; I haven't investigated these cases. Change ip6_get_prevhdr so that it returns an offset in the chain, and always use IP6_EXTHDR_GET to get a writable pointer. IP6_EXTHDR_GET leaves M_PKTHDR untouched. This place is still fragile.
Hopefully this will be useful for other developers who have been looking into the vulnerability.