5 ms·
If you can change libc then you have equal to or greater permissions than the calling process. So this strengthens the security model.
by alexgartrell 7y ago
If you can change libc then you have equal to or greater permissions than the calling process. So this strengthens the security model.
- jacquesm 7y agoDoes that mean that linking against libc is mandatory and that applications are not allowed to bring their own version of libc along for instance when linked statically?
- saagarjha 7y agoStatically linked programs automatically lose this protection, apparently.
- ori_b 7y agoPartly. If they jit, or have shellcode injected, that code is not mappable with syscall privilege.
- tedunangst 7y agoNo. There's nothing special about libc. (Oh, double checked, and uh, maybe. ld.so does treat libc specially if it finds it in the library list, but at that point, you are linking with libc. But afaik there's no requirement you use the system ld.so either.)
- jacquesm 7y agoThen isn't Animats' point valid?
- tedunangst 7y agoThe point of doing this is not to protect against people bringing their own bad libc.
- throwaway2048 7y agoThis is a flag in the ELF binary section headers, if you don't want it, flag your entire binary as "syscalls allowed".
- quietbritishjim 7y agoBut surely applications can make syscalls directly without invoking libc at all, by setting up the registers directly and directly executing the processor instruction that causes the right software interrupt? In which case the parent comment's point still stands: you can bypass checking that's at the libc level in a way you can't bypass checking within the kernel.
- saagarjha 7y agoNo, because the calling address would be wrong.
- jacquesm 7y agoWhy? 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.
- throwaway2048 7y agoIf 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.
- saagarjha 7y agoIf 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”.
- throwaway2048 7y agoShould be noted, that by default on OpenBSD, an RWX page is impossible, mprotect() will fail and the process will get killed trying.