JSJitInfo are abused to get access to generated code.
Categories
(Core :: JavaScript Engine: JIT, enhancement, P3)
Tracking
()
People
(Reporter: nbp, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: sec-audit)
While looking at how people get access to the executable pages, I noticed in https://github.com/bjrjk/CVE-2024-29943/ that one way is to use JSJitInfo.
Given that all JSJitInfo classes are supposed to be compiled as read-only data, this suggest that one might have created a new version of an existing one with a different native pointer. However, any newly created JSJitInfo would live in read-write memory instead of being in read-only memory.
Maybe we could find a way to assert the use of read-only placement before making use of JSJitInfo in the JIT compilers, hopefully without using a fault handler.
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 1•1 year ago
|
||
Reading more the content of the exploit, this is not the JSJitInfo which is being abused as documented in the slides, but the fixed slot of the JSFunction which holds the pointer to the JIT-ed function.
So, this kind of issues can only be solved by using pointer authentication (PAC), such as Bug 1904546.
Description
•