Some Linux kernel security vulnerabilities [LWN.net]

Some Linux kernel security vulnerabilities

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

The last one is an actual logic error: the kernel checks whether you can execute a file, and then reads it into your address space without checking whether you can read it.

That isn't per se an error. Unix is designed to have it possible for a file to be loaded into your address space that you don't have read permission to -- an execute-only file.

Maybe the designer here thought that it would be impossible for the user to see the contents of the address space; i.e. that the program interpreter could be execute-only like any other program.

I can't tell from the paper just what the bug or the exploit is, so I can't say what the real nature of the error is, though.

(Log in to post comments)

Some Linux kernel security vulnerabilities

Posted Nov 12, 2004 17:57 UTC (Fri) by iabervon (subscriber, #722) [Link]

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.

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