Hacker News Reader

Comment by alexgartrell | Hacker News Reader

If you can change libc then you have equal to or greater permissions than the calling process. So this strengthens the security model.

View on HN

Does 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?

Statically linked programs automatically lose this protection, apparently.

Partly. If they jit, or have shellcode injected, that code is not mappable with syscall privilege.

No. 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.)

Then isn't Animats' point valid?

The point of doing this is not to protect against people bringing their own bad libc.

This is a flag in the ELF binary section headers, if you don't want it, flag your entire binary as "syscalls allowed".

But 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.

No, because the calling address would be wrong.

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.

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.

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”.

Should be noted, that by default on OpenBSD, an RWX page is impossible, mprotect() will fail and the process will get killed trying.

Surely there is an “out” for JITs that have not yet adopted W^X?

An opt in actually, to request looser checks.

Can't you make page temporarily RW, JIT, then switch back to RX?

You can, but the application needs to support this.

Reply on news.ycombinator.com