| |||||||||||||
|
| |||||||||||||
Some Linux kernel security vulnerabilitiesSome Linux kernel security vulnerabilitiesPosted Nov 10, 2004 22:42 UTC (Wed) by NAR (subscriber, #1313)In reply to: Some Linux kernel security vulnerabilities by ibukanov Parent article: Some Linux kernel security vulnerabilities In fact they would present if that code would be Python or Java etc. [...] So the question is what tools/techniques can help to track such bugs automatically? I'm way too sleepy to understand the mentioned bugs but it looks to me that the basic problem is that in C lots of functions use the return value to indicate error and to return valuable data. Its consequence is that it's easy to mess it up (classic examples are the atoi() and inet_addr()) while in e.g. Java, a call like read() returns the read data like in C, but when there is an error, it throws an IOException that the developer must handle.
(Log in to post comments)
Some Linux kernel security vulnerabilities Posted Nov 10, 2004 23:09 UTC (Wed) by clugstj (subscriber, #4020) [Link] No, not MUST handle, can handle. Imagine the chaos if an unhandled exception occurred in the kernel.
Some Linux kernel security vulnerabilities Posted Nov 10, 2004 23:27 UTC (Wed) by khim (subscriber, #9252) [Link] Java will not compile code with unhandled exceptions so, yes must handle indeed. Unfortunatelly there are some exceptions which can be ignored (like overflow in i++). Not sure if it's good thing or bad thing.
Some Linux kernel security vulnerabilities Posted Nov 10, 2004 23:35 UTC (Wed) by iabervon (subscriber, #722) [Link] 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.
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).
Some Linux kernel security vulnerabilities Posted Nov 10, 2004 23:57 UTC (Wed) by jwb (guest, #15467) [Link] I agree that this is a common trap in C programming. Instead of:
return_value_or_status = function(args);
I prefer to see:
status = function(&return_value, args);
Which also has the advantage that more than one value can be returned. read(2), in particular, is almost impossible to use, and this goes for all Unix across all time, not just for Linux. The conflation of the file position and the status of the result is very confusing. And, if read returns -1, there's absolutely nothing you can do about it without closing the fd and starting from scratch (because the file position becomes undefined).
Okay, the whole Unix API is hard to use, and so is C ;)
file position after error from read() Posted Nov 11, 2004 0:39 UTC (Thu) by jreiser (subscriber, #11027) [Link] And, if read returns -1, there's absolutely nothing you can do about it without closing the fd and starting from scratch (because the file position becomes undefined).In most cases (EAGAIN, EISDIR, EBADF, EINVAL, EFAULT, and non-POSIX EINTR) you can interpret errno and resume. Only for EIO or for POSIX EINTR is there the possibility of undefined position, and some of that is due to POSIX allowing the kernel a choice of what to do with EINTR. As long as the fd is seekable and the error condition is transient, then the program can recover by seeking to any previous known-good position [the program must track such positions] and resuming. Also, if the fd is seekable then the current position can be determined using lseek(fd, (off_t)0, SEEK_CUR). All in all, that is a long way from being forced to close the fd and start from scratch. In practice, read() on a disk file is very well behaved, especially for reads of 1 sector. [Reading from a socket is different.]
Some Linux kernel security vulnerabilities Posted Nov 11, 2004 3:58 UTC (Thu) by uriel (guest, #20754) [Link] As usual, this was fixed in Plan 9 many years ago.
Some Linux kernel security vulnerabilities Posted Nov 11, 2004 14:42 UTC (Thu) by melauer (guest, #2438) [Link] > As usual, this was fixed in Plan 9 many years ago.
The pencil and paper which I use as a word processor doesn't have these vulnerabilities either. Now that's secure design!
Some Linux kernel security vulnerabilities Posted Nov 11, 2004 16:06 UTC (Thu) by smurf (subscriber, #17840) [Link] > As usual, this was fixed in Plan 9 many years ago.
I don't know about the in-kernel stuff, but Plan9's basic read() system call doesn't differ much from common Unix semantics -- including short reads -- and thus I kindof doubt that the inside is different.
|
|
||||||||||||