[ruby-core:106367] [Ruby master Bug#18260] YJIT uses insecure mmap protections

["jeremyevans0 (Jeremy Evans)" <noreply@ruby-lang.org>]

Issue #18260 has been updated by jeremyevans0 (Jeremy Evans).

Status changed from Open to Closed

Fixed by commit:157095b3a44d8b0130a532a0b7be3f5ac197111c

----------------------------------------
Bug #18260: YJIT uses insecure mmap protections
https://bugs.ruby-lang.org/issues/18260#change-95002

* Author: jeremyevans0 (Jeremy Evans)
* Status: Closed
* Priority: Normal
* Assignee: maximecb (Maxime Chevalier-Boisvert)
* Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: DONTNEED
----------------------------------------
YJIT uses `mmap` with `PROT_READ | PROT_WRITE | PROT_EXEC` protections, which reduces security because it makes code injection attacks much easier, as the attacker only needs to be able to write their shellcode to the mapped memory region and then directly jump to the shellcode just written.

The security principle being violated here is referred to as `W^X` (W xor X). Basically, memory can be either writable or executable, but never both at the same.

OpenBSD has disallowed `mmap` with `PROT_WRITE | PROT_EXEC` by default since 2016.  NetBSD/Linux with PaX MPROTECT disallows this as well, as does SELinux unless you enable `allow_execmem`.

Fixing this generally involves initially mapping pages with `PROT_READ | PROT_WRITE`, and after writing executable code, using `mprotect` to switch to `PROT_READ | PROT_EXEC`.  This is the approach that Firefox takes for their Javascript engine starting in Firefox 46.  This makes code injection attacks more difficult as an attacker either cannot write the shellcode (if mapped `PROT_READ | PROT_EXEC`), or cannot jump directly to the shellcode after writing (if mapped `PROT_READ | PROT_WRITE`).



-- 
https://bugs.ruby-lang.org/