Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 / PS5 PKGs.
Category PS4 Jailbreaking       Thread starter Thread starter PSXHAX       Date / timeStart date Oct 26, 2016 at 8:12 PM       Replies 21      
Status
Not open for further replies.
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 Pastebin.com also comes a log from #ps4dev on iRC via @B7U3 C50SS, as follows:
Code:
[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 ? http://www.securityfocus.com/archive/1/archive/1/537812/100/0/threaded
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> https://twitter.com/cturte/status/710173621386387457
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
 

Comments

Status
Not open for further replies.
Back
Top