Nytro Posted April 15, 2020 Report Share Posted April 15, 2020 Linux Kernel 5.3 solves the CR0 write exploit by making that register read only. Today let's discuss how we can write to the SyscallTable directly and not rely on the CR0 write exploit that we have been using. I heard about this method some time ago and I thought it had long been patched and wouldn't work . However as Nasm points out the ptr exploit still works and still has application. https://en.wikipedia.org/wiki/Control... https://outflux.net/blog/archives/201... From the site above: x86 CR4 & CR0 pinning In recent exploits, one of the steps for making the attacker’s life easier is to disable CPU protections like Supervisor Mode Access (and Execute) Prevention (SMAP and SMEP) by finding a way to write to CPU control registers to disable these features. For example, CR4 controls SMAP and SMEP, where disabling those would let an attacker access and execute userspace memory from kernel code again, opening up the attack to much greater flexibility. CR0 controls Write Protect (WP), which when disabled would allow an attacker to write to read-only memory like the kernel code itself. Attacks have been using the kernel’s CR4 and CR0 writing functions to make these changes (since it’s easier to gain that level of execute control), but now the kernel will attempt to “pin” sensitive bits in CR4 and CR0 to avoid them getting disabled. This forces attacks to do more work to enact such register changes going forward. (I’d like to see KVM enforce this too, which would actually protect guest kernels from all attempts to change protected register bits.) Quote Link to comment Share on other sites More sharing options...