Re:OpenBSD system-call-origin verification
by jacquesm on Sunday December 22, 2019 @06:56PM
(#21860502)
Why? After all, if libc is optional then you could simply provide a statically linked binary and be done with it, there would be no way to change the addresses.
[ Parent
| on HN ]
Re:OpenBSD system-call-origin verification
by saagarjha on Sunday December 22, 2019 @07:10PM
(#21860571)
If you link against libc, that’s the only place you can enter the kernel from. If you statically link that is relaxed to “system calls can come from anywhere on your code”. The former has stronger protections, obviously, but as far as I can tell you still have protection from “wild shellcode in a RWX region can make syscalls”.
Re:OpenBSD system-call-origin verification
by throwaway2048 on Sunday December 22, 2019 @07:19PM
(#21860620)
Should be noted, that by default on OpenBSD, an RWX page is impossible, mprotect() will fail and the process will get killed trying.
Re:OpenBSD system-call-origin verification
by saagarjha on Sunday December 22, 2019 @07:22PM
(#21860637)
Surely there is an “out” for JITs that have not yet adopted W^X?
Re:OpenBSD system-call-origin verification
by tedunangst on Sunday December 22, 2019 @07:25PM
(#21860649)
An opt in actually, to request looser checks.
Re:OpenBSD system-call-origin verification
by lostmsu on Sunday December 22, 2019 @08:00PM
(#21860764)
Can't you make page temporarily RW, JIT, then switch back to RX?
Re:OpenBSD system-call-origin verification
by saagarjha on Sunday December 22, 2019 @08:24PM
(#21860845)
You can, but the application needs to support this.
Re:OpenBSD system-call-origin verification
by throwaway2048 on Sunday December 22, 2019 @07:09PM
(#21860566)
If you can provide a staticly linked binary, its already game over as far as these protections are concerned.
They are designed as a protection against stuff like ROP and other memory based, zero information attacks that hit already running processes.