Some Linux kernel security vulnerabilities [LWN.net]

Some Linux kernel security vulnerabilities

Posted Nov 12, 2004 17:57 UTC (Fri) by iabervon (subscriber, #722)
In reply to: Some Linux kernel security vulnerabilities by giraffedata
Parent article: Some Linux kernel security vulnerabilities

IIRC, you should only be able to access a --x file by calling exec on it, which will cause the process to be replaced with the code loaded from the file. It replaces your address space, so it's never in "your" address space ("you" in this case being code of your choice; the address space will be still associated with your uid). The bug here is that you can cause a program with your code (rwx) to try to use a --x file as a dynamic linker. When it crashes, which it probably will as a --x file isn't going to be intended as a dynamic linker, the contents are in the core dump. If it doesn't crash, the program can read it.

(Log in to post comments)

exec-only ELF interpreter

Posted Nov 13, 2004 18:38 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

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.

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