Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
PS4 Jailbreaking       Thread starter PSXHAX       Start date Oct 26, 2016 at 8:12 PM       21      
Yesterday we reported on research being done by PlayStation 4 developers and enthusiasts to uncover the Chaitin Tech PS4 4.01 Kernel Exploit, and today @SpecterDev shared another Tweet which sheds more light on the suspected CVE-2016-1885 (Exploit-DB) vulnerability. :geek:

Below is a brief excerpt, and be sure to check it out in it's entirety on his Latest PS4 Dev Blog entry!

To quote: "My ultimate goal of the lower half of this article is to show a little snippet of the complexity of such an exploit to be developed, so whenever something is found, don't expect an exploit to be released right away.

If and when such a POC is released, be thankful and respectful to the developer, after all many in this scene are doing this work for free."

From also comes a log from #ps4dev on iRC via @B7U3 C50SS, as follows:
[12:32] <HI_Ricky> but .env is encrypt
[12:32] <HI_Ricky> XD
[12:34] <HI_Ricky> not yet to know what it did when check system update from beta test user
[12:35] <HI_Ricky> hidusbpower look like hidden usb power
[12:35] <HI_Ricky> hid_config look like hidden config, XD
[12:36] <flatz_> why do you need env?
[12:36] <HI_Ricky> for downgrade?
[12:38] <HI_Ricky> i dont know XD
[12:39] <HI_Ricky> so why beta test user can check beta fw and rls fw at same time
[12:49] <maxton> hid_config sounds like human interface device config to me
[12:49] <HI_Ricky> right XD
01[12:54] <Fimox> the "magic CVE" is CVE-2016-1885 ?
01[12:54] <Fimox> has it been confirmed ?
[12:56] <maxton> not necessarily. that is just a denial of service vulnerability. it is difficult or impossible to get kernel code exec with that
01[12:57] <Fimox> have you read "8.1. FreeBSD amd64_set_ldt Integer Signedness Vulnerability" on that link ?
01[12:58] <Fimox> not that easy to understand in 30 seconds, but it can help a lot I think
01[13:00] <Fimox> it shows how to run that "heap overflow"
[13:00] <maxton> it's a heap overflow but it's only able to write zeroes to a certain range of addresses
01[13:01] <Fimox> "zero overflow" ? I go read slower :)
[13:01] <maxton> "This signedness error will ultimately lead to a heap overflow in the FreeBSD kernel when the bzero() function is later called with a huge value as its len parameter"
[13:02] <maxton> bzero is basically alias for memset with 0 as the byte
[13:04] <maxton> anyway, it doesn't matter for later FW. Cturt has said sony removed set_ldt completely after 1.76
01[13:07] <Fimox> yes yoy're right, this exploit leads to "622 bzero(&((struct user_segment_descriptor *)(pldt->ldt_base))"
01[13:07] <Fimox> I'm pretty sure today or tomorow we will know what vuln they used :)
01[13:17] <Fimox> but bzero could erase a "conditional test" in the kernel, can it give a privilege escalation ?
01[13:18] <Fimox> Cturt is THE king, but he's human, maybe he didn't test it right ?
[13:25] <rck`d> test what right? Cturt said they straight removed the code, I'm inclined to believe him
01[13:26] <Fimox> he said "set_ldt was used in BadIRET and patched"
[13:28] <xorloser> hm looking at that cturt tweet someone posted, it appears to be his post from march. so not a recent one pertaining to this exploit?! crurt mentions set_ldt, but not amd64_set_ldt. and the exploit writeup specifies that it was an amd64 specific bug, so perhaps amd64_set_ldt is still used somewhere (havent looked myself)
01[13:31] <Fimox> set_ldt = i386_set_ldt = amd64_set_ldt
01[13:32] <Fimox> but "set_ldt was used in BadIRET and patched" <> "sony removed set_ldt completely after 1.76"
01[13:33] <Fimox> do you really think they removed everywhere set_ldt after 1.76 ? too much work !
[13:35] <rck`d> "Sony removed set_ldt altogether following BadIRET."
[13:35] <rck`d> that's from his tweet.
[13:35] <rck`d>
01[13:36] <Fimox> I think he was meaning following the BadIRET vuln ?
[13:36] <rck`d> badiret is the 1.76 exploit, was patched with 2.00
[13:36] <rck`d> so 2.00 and on should not have set_ldt anymore
[13:37] <rck`d> and xorloser, that was in response to the info about the exploit that was 'revised' with chaitain's new thing
01[13:37] <Fimox> Yes so maybe he only wanted to say that Sony patched the BadIRET vuln (and removed set_ldt)
[13:37] <rck`d> they found it to still be vulnerable
[13:37] <rck`d> yes? and?
[13:37] <rck`d> if they removed set_ldt, it can't be exploited
01[13:38] <Fimox> because you think set_ldt is used only in that BadIRET section ?
[13:39] <rck`d> "Sony removed set_ldt altogether"
[13:39] <rck`d> key word: altogether
01[13:40] <Fimox> ok
[13:40] <rck`d> I don't have the capability to test past 1.76 currently, but I believe cturt to have correct info
[13:40] <rck`d> anyone who has a <= 4.00 beta 2 PS4 can test it
[13:41] <rck`d> if it hangs, then it's still present, if it doesn't, it's gone
[13:41] <xorloser> so perhaps cn guys lied so as to not have to release their exploit :)
[13:41] <rck`d> lied about what? they submitted a valid patch, it's just not the one relevant to their 4.01 exploit
[13:41] <rck`d> *submitted a valid issue
[13:41] <xorloser> seems they presented at some conference where rules dictated they disclose their exploits they used
[13:41] <rck`d> I don't think they ever came out and said "this is our exploit"
[13:41] <rck`d> someone saw it and connected them
[13:42] <rck`d> but it's clearly not
[13:42] <xorloser> wasnt it released under their name?
[13:42] <rck`d> yes, but it's a company
[13:42] <rck`d> companies do many things
01[13:42] <Fimox> but set_ldt hasn't been removed from FreeBSD, and if Sony reintroduced set_ldt by error on FW > 2.xx ?
[13:42] <rck`d> then someone can test it
[13:42] <rck`d> rop is possible all the way up to 4.00 beta 2
[13:44] <rck`d> I personally have PS4s on 1.76 and 4.01, I'm not about to upgrade 1.76 without something functional currently, best I could pick up a new PS4 eventually
01[13:45] <Fimox> rck`d: the way things are going, the future will be 3.50 3.55 or 4.01
[13:46] <rck`d> which is fine
01[13:46] <Fimox> do you really think that now there will have new progress on 1.76 ?
[13:46] <rck`d> no, but I actively dev and do other things with my 1.76
[13:47] <rck`d> I mean, 1.76 is broken completely now, so it's useful
01[13:47] <Fimox> ok I understand :)
[13:47] <rck`d> I did testing and research on 3.55 and 4.00 beta 2, but that was on my gaming PS4 so that went away since I keep that one on latest
[14:54] <BadC> Cturt is a king, and has definiatly put life into the scene with his article. But he has made mistakes. i would either inquire with him, if he is 100% sure on removal, or test XD.
[14:54] <BadC> I too have 1.76 and 4.01 XD
[14:55] <BadC> On Cturts article he mentions ptrace will restart the process removing patches after reading / writing to memory, this is not entirely correct... the process "re-starts" not restarts, and patches stay.
[14:55] <BadC> Take all info with a grain of salt ;)
[15:33] <WhiteHex> BadC, nice find! +1 Beer
PS4 Developer Specter on CVE-2016-1885 Vulnerability.jpg


i am not surprised at the chaitin group; surprisingly they seem to love authority, they don't see the bigger picture, they like being rubbed on the back by sony... something most of us would be smart enough to avoid
Even if they release nothing or devs know now that there is a jailbreak available so I know our devs will find "if not found already" the way to jailbreak and we will have it soon
I read online that this was part of a private exploit Aboshi2011 commented about a while back, being found months ago.

The CVE alone is enough to get us started on the right path to a full exploit that could lead somewhere great. don't ya think?