Editing Vulnerabilities
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1,655: | Line 1,655: | ||
=== CR0.WP protection === | === CR0.WP protection === | ||
At least since | At least since firmware 6.51 Sony instrumented all instructions that write to the CR0 register with checks for attempts to clear CR0.WP (Write Protect), which is necessary for patching the kernel. This is what it looks like in 6.51 kernel: | ||
a1b79: 0f 22 c0 mov cr0,rax | a1b79: 0f 22 c0 mov cr0,rax | ||
Line 1,666: | Line 1,666: | ||
Bypasses (in chronological order): | Bypasses (in chronological order): | ||
* | |||
* Use kernel write to give your process JIT permissions, allocate JIT memory, and put entirely custom code there (avoids the problem altogether, as it is specific to ROP) | * Use an "unintended" mov to cr0 in the middle of another instruction (e.g. instruction "call $+0x220f1c" (e8 17 0f 22 00) contains an unintended "mov cr0, rax" (0f 22 00)) | ||
* Since the IDT | * Use kernel write to give your process JIT permissions, allocate JIT memory, and put entirely custom code there (avoids the problem altogether, as it is specific to ROP) | ||
* Since the IDT is writable on FreeBSD and PS4, it is possible to overwrite an exception handler without clearing CR0.WP first. One can overwrite the handler of #UD with a gadget of their choice (a stack pivot, or a "add rsp, ... ; ret", or whatever else), and the UD2 instruction in the mitigation code will happily jump to it instead of the real handler, with CR0.WP cleared. | |||
== Secure Modules == | == Secure Modules == |