Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
Status
Not open for further replies.
Proceeding his SMAP Bypass PS5 Vulnerability disclosed last year, security researcher m00nbsd announced via Twitter today the disclosure of a PlayStation 5 Remote Kernel Heap Overflow Vulnerability on PlayStation Bug Bounty site HackerOne.com which affects PlayStation 5 consoles up to 4.03 PS5 Firmware alongside PlayStation 4 consoles through 9.00 PS4 Firmware. :sneaky:

While this latest PlayStation H1 disclosure has already been patched by Sony in both PS5 4.50 Firmware and PS4 9.03 Firmware, since the 9.00 PS4 Jailbreak Exploit release developer @SpecterDev on Twitter reminds the PS4Scene that:

"PPPoE bug patch in PS4. As can be seen, patched in 9.03 on the right. Probably not worth attempting to exploit this on PS4 as it won't move firmware forward. Also probably would end up less stable than exFAT exploit because mbuf zone corruption kinda sucks."

As for progress in the PS5Scene, @zezu420 aka Znullptr Has Been Working on PS5 Development with some updates HERE since the PS5 4.03 ROP Userland Exploitation proceeding the PS5 4.03 Webkit Exploit implementation, PS5 Kernel Exploit (ExFAT Bug), PlayStation 5 Debug Settings & Root Keys, 4.03 PS5 Kernel Build String and the PS5 4.03 ROP Userland (Webkit Execution) Exploitation in anticipation of PS5 Game Dumps and homebrew whenever a full PlayStation 5 Jailbreak exploit arrives publicly.

🔥 Without further ado, here's what is included in the Remote Kernel Heap Overflow Report disclosure to quote:

Summary

The PlayStation has a kernel PPPoE driver, that originates from NetBSD. This driver has a kernel heap overflow vulnerability, that an attacker can remotely trigger over the LAN, with the ability to control both the contents that are overflown and their sizes.

Technical Details

PPPoE Protocol


In short, the PlayStation (PS) will:
  1. Send a PADI packet.
  2. Expect to receive a PADO packet.
  3. Send a PADR packet.
  4. Expect to receive a PADS packet.
The Vulnerability

I determined that the PS' PPPoE driver originates from NetBSD. In that PPPoE driver, there is a vulnerability in the way PADR packets are allocated:
Code:
static int
pppoe_send_padr(struct pppoe_softc *sc)
{
    [...]

    /* Compute packet length. */
    len = sizeof(struct pppoetag);
    if (sc->sc_service_name != NULL) {
        l1 = strlen(sc->sc_service_name);
        len += l1;
    }
    if (sc->sc_ac_cookie_len > 0) {
        len += sizeof(struct pppoetag) + sc->sc_ac_cookie_len;
    }
    if (sc->sc_relay_sid_len > 0) {
        len += sizeof(struct pppoetag) + sc->sc_relay_sid_len;
    }
    len += sizeof(struct pppoetag) + sizeof(sc->sc_id);
    if (sc->sc_sppp.pp_if.if_mtu > PPPOE_MAXMTU) {
        len += sizeof(struct pppoetag) + 2;
    }

    /* Allocate packet. */
    m0 = pppoe_get_mbuf(len + PPPOE_HEADERLEN);
    if (m0 == NULL)
        return ENOBUFS;

    /* Fill in packet. */
    [...]
}

static struct mbuf *
pppoe_get_mbuf(size_t len)
{
    struct mbuf *m;

    MGETHDR(m, M_DONTWAIT, MT_DATA);
    if (m == NULL)
        return NULL;
    if (len + sizeof(struct ether_header) > MHLEN) {
        MCLGET(m, M_DONTWAIT);
        if ((m->m_flags & M_EXT) == 0) {
            m_free(m);
            return NULL;
        }
    }
    m->m_data += sizeof(struct ether_header);
    m->m_len = len;
    m->m_pkthdr.len = len;
    m_reset_rcvif(m);

    return m;
}
The flow is:
  • pppoe_send_padr():
    • It wants to send a PADR packet.
    • It computes the packet length, and calls pppoe_get_mbuf().
  • pppoe_get_mbuf():
    • If the length is larger than MHLEN, it allocates an mbuf cluster, of size MCLBYTES=2048.
    • It returns that mbuf cluster.
  • pppoe_send_padr():
    • It fills in the mbuf cluster.
The vulnerability here is that the packet length could actually be bigger than MCLBYTES, in which case the filling of the packet will overflow the mbuf cluster.

Constraints

To have a length that is larger than MCLBYTES, the sc_ac_cookie_len and sc_relay_sid_len values need to be large enough.

Both of these values are actually extracted from PADO packets that the PS previously received: they are the lengths of the ACCOOKIE and RELAYSID tags that were embedded in the PADO packets. The attacker can control these lengths.

There is a constraint on the MTU: given that the PS' maximum MTU is 1500, the attacker cannot directly send just one PADO packet with sizes larger than MCLBYTES. To work around that constraint, the attacker just has to send two PADO packets, one with a big ACCOOKIE tag, and another with a big RELAYSID tag. After the second packet, the PS will send a PADR packet combining both big tags, which will overflow the mbuf cluster with the contents of the second tag.

Attack Scenario
  1. The PS sends a PADI.
  2. The attacker sends a PADO, with a ACCOOKIE tag whose size is 1400 bytes.
  3. The PS sends a PADR. This one is fine, there is no overflow here.
  4. The PS waits for a PADS packet.
  5. The PS times out, and resends a PADI.
  6. The attacker sends a PADO, with a RELAYSID tag whose size is 1400 bytes.
  7. The PS Sends a PADR. The overflow occurs here: the PS tries to embed the two tags (1400x2=2800 bytes) into a 2048-byte mbuf cluster.
Setup / PoC / Discussion
  • Enable PPPoE on the PS:
    • Settings -> Network -> Set Up Internet Connection -> Use a LAN Cable -> Custom
    • IP Address Settings: PPPoE
    • Enter whatever in the two User/Password fields, click Next
    • DNS Settings: Automatic
    • MTU Settings: set 1500
    • Proxy Server: Do Not Use
  • Connect a Linux laptop to the PS with an Ethernet cable.
  • On the Linux laptop:
    • cc -o poc poc.c -Wall
    • sudo ifconfig eth0 mtu 8000
    • sudo ./poc eth0
  • On the PS: click Test Internet Connection. This will initiate the PPPoE connection.
To see what happens:
  • Open WireShark on the Linux laptop, and look at the packets that are being exchanged with the PS. You can see that the PS sends 2844-byte PADR packets.
  • Actual exploitation/introspection will require a debugger, which I do not have. :'(
  • ███████
Impact

Possible RCE. I did my tests only on a friend's PS4, but I suspect that the PS5 is affected as well.
PS5 Remote Kernel Heap Overflow by M00nbsd, Patched in 9.03 PS4 Firmware.png
 

Comments

@simonwest Why?

I don't get the rush/need to play backup PS4 games on a PS5, just use your PS4 for that. Or is it because there's nothing worth playing on PS5 at all?

Asking as i still haven't opened my PS5 from xmas last year...
 
It's faster on ps5 with the ssd and I bought a m2 too, so I can play ps4 games and enjoy the speed of loading.

Just look on YouTube how much faster it is.. Like rdr2 or other games and it runs smoothly.
 
Massive thanks to m00nbsd, hackerone and sony for allowing disclosure and anyone else that gets involved in turning it into a jailbreak on ps5
 
Time to play horizon forbidden west for ps4 if we get ps5 jailbreak that mean we can dump ps4 disk on ps5 hdd... So if we don't get 9.03 jalibreak evan we can play new ps4 games
 
@blimblim04
I've been wondering about this too. From a system architecture standpoint, is it possible to create FPKG for higher firmware PS4 games on a theoretically jailbroken PS5?

Like, if you can play 9.03+ fw PS4 game discs on a 4.03 fw PS5, and a PS5 exploit is found, can you make FPKGs for 9.03+ PS4 games via PS5 and backport them to 9.00?
 
Status
Not open for further replies.
Back
Top