Question about CVE-2023-4069

[18Fl]

Hey, @m-y-mo , sorry for bother u. I have seen u load the exp about |CVE-2023-4069|, but it run in d8 with flags, Is it possible to run it in chrome without any flags? Thx!

• https://github.com/github/securitylab/tree/main/SecurityExploits/Chrome/v8/CVE_2023_4069

[m-y-mo]

Yes, Chrome version 115.0.5790.98/99 should have maglev flag enabled in the renderer by default, so you don't need that flag if you are running it in Chrome. Because of the differences in heap layout in Chrome, you probably need some tweaks it to get it working:

1. arrAddr is a rough starting point to look for the oobDblArr. This probably needs changing. This would roughly be the address of oobDblArr, which should be fairly consistent across runs. Set addrAddr to something slightly less than this to allow for some margin.
2. You probably need to play around a bit with creating corruptedArr Try repeating corruptedArr = construct() a few times until you get something with a large length.
3. Shellcode needs changing, otherwise there won't be any visible effect, but you can probably still see a shell popping in a debugger.
4. I seem to remember that the gcSize threshold is different in v8 and in Chrome renderer, so you may only need to do this once in Chrome to trigger gc. Triggering gc twice may ended up wiping the stale objects and cause the poc to fail (corruptedArr length will ended up zero all the time). You can use the trace-gc flag to check if gc is triggered.
   Beware that launching Chrome renderer with a debugger affects the heap layout, so the addresses, offsets you get when launching with a debugger may not work when you try running without a debugger. Try to use %DebugPrint (in release build it should still print out object address) or attach a debugger the the renderer process afterwards to avoid this.

[18Fl]

Thx, I will try to do this! Man Yue Mo ***@***.***> 于2023年10月25日周三 18:00写道：

…

Yes, Chrome version 115.0.5790.98/99 should have maglev flag enabled in the renderer by default, so you don't need that flag if you are running it in Chrome. Because of the differences in heap layout in Chrome, you probably need some tweaks it to get it working: 1. arrAddr <https://github.com/github/securitylab/blob/main/SecurityExploits/Chrome/v8/CVE_2023_4069/poc.js#L52> is a rough starting point to look for the oobDblArr. This probably needs changing. This would roughly be the address of oobDblArr <https://github.com/github/securitylab/blob/main/SecurityExploits/Chrome/v8/CVE_2023_4069/poc.js#L52>, which should be fairly consistent across runs. Set addrAddr to something slightly less than this to allow for some margin. 2. You probably need to play around a bit with creating corruptedArr <https://github.com/github/securitylab/blob/main/SecurityExploits/Chrome/v8/CVE_2023_4069/poc.js#L83> Try repeating corruptedArr = construct() a few times until you get something with a large length. 3. Shellcode needs changing, otherwise there won't be any visible effect, but you can probably still see a shell popping in a debugger. 4. I seem to remember that the gcSize threshold is different in v8 and in Chrome renderer, so you may only need to do this <https://github.com/github/securitylab/blob/main/SecurityExploits/Chrome/v8/CVE_2023_4069/poc.js#L80> once in Chrome to trigger gc. Triggering gc twice may ended up wiping the stale objects and cause the poc to fail (corruptedArr length will ended up zero all the time). You can use the trace-gc flag to check if gc is triggered. Beware that launching Chrome renderer with a debugger affects the heap layout, so the addresses, offsets you get when launching with a debugger may not work when you try running without a debugger. Try to use %DebugPrint (in release build it should still print out object address) or attach a debugger the the renderer process afterwards to avoid this. — Reply to this email directly, view it on GitHub <#797 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAMGVRG2BFAEHMS5RMZEQC3YBDPKPAVCNFSM6AAAAAA6PBTXX6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TGNZZGUYTG> . You are receiving this because you authored the thread.Message ID: ***@***.***>