Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Some Linux kernel security vulnerabilitiesSome Linux kernel security vulnerabilitiesPosted Nov 10, 2004 23:35 UTC (Wed) by iabervon (subscriber, #722)In reply to: Some Linux kernel security vulnerabilities by NAR Parent article: Some Linux kernel security vulnerabilities
Some of the bugs are failures to handle short reads correctly, which would apply to any system (not language; it's a question of the behavior of the code) which could return some data without returning all of it.
Some are returning a non-error when responding to an error condition. This is reasonably easy to do if you're catching exceptions, but less likely because you can just declare the exception in your throws clause and avoid resignalling the error. It is still possible to end your catch block with "return;" instead of "throw e;" when you want to do something in the error path but resignal the same error.
There's something leading to a minor memory error, which would probably be blocked in Java.
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.
It would be interesting to see if sparse could be extended to know whether the kernel has any good reason to believe strings to be terminated. Off the top of my head, it seems like it could keep track of this, assuming you want to be paranoid, which is wise in any case.
(Log in to post comments)
Some Linux kernel security vulnerabilities Posted Nov 12, 2004 2:01 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 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.
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).
|
|||||||||||