PSFree WebKit Exploit for PS4 6.00 to 9.60 & QuickHEN PS4 Incoming

This weekend PS4 Scene developer @CelesteBlue announced on Twitter news of a PSFree WebKit Exploit for PS4 6.00 to 9.60 crediting Sergei Glazunov and Maddie Stone (Twitter) of Project Zero for discovering the vulnerability, anonymous for writing the PSFree Exploit and himself for testing, porting and improvements alongside a QuickHEN PS4 collection incoming of WebKit exploits for PlayStation 4 System Software versions between 3.15 and 9.60 with Kernel exploits between 3.15 and 9.00 only albeit requiring more work.

Download: psfree-1.2.0.zip (39.93 KB) / GIT / PSFree Exploit (Live Demo) via @zecoxao on Twitter / psfree-beta2.7z (16.34 KB) via abc for 8.0x / psfree-beta3.7z (24.60 KB) via abc / PSFree Beta 3 Version (Live Demo) via Kameleonre_ / psfree-1.3.0.7z (30.30 KB) via abc / psfree-beta-140.7z (37.05 KB) via abc / PS5 Kernel Exploit 3.xx-4.xx (PSFree Integrated Live Demo) / PS5 Exploit Host via idlesauce / PSFree900-main.zip / PSFree900 GIT / PSFree 9.00 FW (Live Demo) via Kameleonre_ / 9.00 FW PSFree with GoldHEN (Live Demo) via ps3120 / 6.72 FW PSFree with GoldHEN via ps3120 / psfree-beta3-140.7z (37.92 KB) via abc / psfree-beta4-140.7z (37.93 KB) via abc / psfree700-main.zip (36.1 KB) / PSFree 7.02 FW via Kameleonre_

• PS4/PS5 exploit using CVE-2022-22620
• PS4 versions vulnerable: 6.xx-9.xx (tested 6.50-9.60)
• PS5 versions vulnerable: 1.xx-5.xx (tested 1.00-5.50)

This comes proceeding the PS4 NoBD: BD Driveless Updating & No BD Updater Payloads / PS4 NoBD Toolkit, HDD_Script.py to Retrieve Data from Any PS4 Console via SFlash Dump, PS4 CR0.WP Protection Kernel Security Bypass and pOOBs4: PS4 9.00 Jailbreak Exploit via ChendoChap with Updated Payloads previously released.

Here's further details from the included README.txt: PSFree version 1.2.0

PSFree is a WebKit exploit using CVE-2022-22620 to gain arbitrary read/write.

This exploit was initially for the PS4 firmware version 8.03. CelesteBlue has tested and confirmed that the original works on 7.00-8.52 and helped in making the patches for 6.00-6.72, 9.00-9.60, and PS5 1.00-5.50.

CREDITS:

• CelesteBlue from ps4-dev on discord.com for testing and porting to other firmwares
• Quentin Meffre (0xdagger) and Mehdi Talbi (abu_y0ussef) for the 6.xx buildBubbleTree() UaF exploit that served as the framework for this exploit
• Maddie Stone for the CVE writeup

Notes on reimplementing this project and testing on firmwares != 8.03:

• num_reuse and num_str must be changed if the proof-of-concept is failing
• 6.xx firmwares need a setTimeout() after a gc() for garbage collection to work. The duration may also need changing.

These values are at exploit.mjs. This implementation was tested on 8.03.

The values are implementation dependent. Even if you are on the same firmware and you test 2 different implementations, you may need to change the values.

For example, if you reimplement the project with setTimeout() callbacks instead of using Promises, even if you are on 8.03, you may need different values.

Changelog:

1.2.0:

• add support for PS4 6.00-6.20

1.1.0:

• add support for running ROP chains (PS4 8.03)
• add support for calling syscalls (PS4 8.03)

1.0.0 changelog:

• add proof-of-concept code to gain arbitrary read/write (PS4 6.50-9.60/PS5 1.00-5.50)

OLD README:

PSFree is a WebKit exploit using CVE-2022-22620 to gain arbitrary read/write.

This exploit is for the PS4 firmware version 8.03

Porting to other firmware versions:

The only non-portable parts of the exploit (assuming the firmware is vulnerable) are:

1. the size of SerializedScriptValue and the offsets of its fields
2. how to achieve an arbitrary decrement primitive

There also other objects used by this exploit such as StringImpl. They too are also subject to change between different firmware versions but are very stable hence why we did not list them.

Number 2 is used to corrupt the length of the JSArrayBufferView. This exploit manipulated the destructor ~SerializedScriptValue() to achieve the wanted result.

There is possibly a restricted free primitive via repeatedly corrupting any object that gets allocated at a JSArrayBufferView and changing its contents so that is frees another object.

For example you could modify a StringImpl to have its data pointer point to a target address and set its BufferOwnership to BufferOwned and have it destroyed.

The primitive is restricted as you can only fastFree() addresses known by the fastMalloc allocator. This means an address on the fastMalloc heap, regardless of whether it is free or not.

This means you can recreate any previous fastMalloc use-after-free exploit.

Spoiler: Related Tweets

 

[Chumdiddy1]

@krontekh
I don't think you actually read my post. If you did, I have serious doubts about your reading comprehension skills, lol. Let me break it down:

9.00 is great but 5.05 is better (IMO). Neither are hard but 5.05 is better because it's one button from your couch. It's one step and works about 90% of the time.
9.00 requires grabbing a USB stick, performing a task at the PS4, works about 75% of the time. Easy and awesome! But not as easy as 5.05.

Easy-er. Easy-ER. More easy. Not hard! Both easy and awesome but... Easier. Easy-er.

I hope this helps and best of luck to you. You seem real cool, lol.

 

[Tproc]

@turbo1point3, Seemingly so. If I am interpreting this correctly, it looks like we just need a new Kernel Exploit.

That will most likely not be a quick development, even if it was to be discovered this very second, it will most likely be disclosed to Sony (e.g. Like theflow0 does on HackerOne)

Which would take a while to be disclosed.

Yes, Userland WebKit Exploit, that is userland, we need a combination of Userland + Kernel Exploit to compromise the system beyond userland to get the tools working we know and love.

Provided a known exploit doesn't already work on 9.60??? (I don't think so, Sony would have patched that when it was disclosed)

This is my N00b point of view, Please correct me!

 

[lidscv]

Excited to see what comes of this

 

[Adonis43]

so how does this new webkit exploit differ from the old one? is it just that it works for a larger number of firmwares?

 

[Tproc]

@Adonis43
This new exploit in WebKit uses a different vulnerability that doesn't rely on a USB, as well as supporting a larger set of firmwares.

Being able to break/break out of userland with less physical interaction is always a plus!

Can run it from a couch, bed, etc and less risk of USB ports wearing out over time!

EDIT!!!: I am wrong, this does not affect or interact with the USB that is part of the current Kernel exploit, not the userland exploit.

 

[krontekh]

Yeah, sounds right to me. This userland exploit does not open any new doors right now. We still need a kernel level exploit for firmware > 9.0

For a jailbreak to happen, we need to chain the userland exploit + the kernel exploit. This announcement gives us only a userland exploit for fw 9.60

 

[QUEST1997]

Looking good, thank you developers!

 

[Eimaiskatouli]

cool

 

[Kulls]

nice news

 

[skwheeler]

Great work; nice to see some progress on > 9.00!