exec-only ELF interpreter [LWN.net]

exec-only ELF interpreter

Posted Nov 13, 2004 18:38 UTC (Sat) by giraffedata (subscriber, #1954)
In reply to: Some Linux kernel security vulnerabilities by iabervon
Parent article: Some Linux kernel security vulnerabilities

The dynamic linker gets called like any other program (you can exec() it if you want), so it's not obvious that e.g. /sbin/mount would crash if you named it as the ELF interpreter (dynamic linker) for your program /home/hacker/hack. It would just complain about nonsensical arguments. And since /sbin/mount will definitely not transfer control to the text of /home/hacker/hack, said program can't look at the text of /sbin/mount.

I believe there is some black magic that keeps the text of /sbin/mount from ending up in a core dump file if it is --x and you run it the normal way and it crashes. Maybe that black magic is missing for the case that /sbin/mount is running in place of the dynamic linker. I know the execute-only concept is fragile; people are warned not to rely on it.

It seems reasonable to me that Linux would be designed to allow for --x dynamic linkers.

(Log in to post comments)

exec-only ELF interpreter

Posted Nov 14, 2004 0:14 UTC (Sun) by iabervon (subscriber, #722) [Link]

You can exec() the dynamic linker if you want, but that's not what dynamically linked executables do. It's a bit confusing, because the dynamic linker these days is also a program which will dynamically link and run its argument. However, it doesn't work for everything: if you do /lib/ld.so /sbin/mount, it will complain that it can't read /sbin/mount (since it can't). For that matter, this doesn't give root priviledges to setuid programs, since the dynamic linker isn't setuid, and the program isn't being execed. Actually, the main reason that the dynamic linker is executable is so that ldd can call it to get the info. (Also, don't confuse this with the shell interpreter, where it execs the interpreter with standard in redirected from the file).

In fact, the kernel loads the interpreter as well as loading the program you called exec() on, and runs the program with the interpreter loaded into memory in a predictable way. Actually, I think a statically linked program which specified an interpreter would just have that file loaded for it, and could just read it without executing it.

I know that setuid programs don't dump core; non-readable ones might behave the same way (/sbin/mount is both).