begin quoting Andrew Lentvorski as of Fri, Aug 08, 2008 at 08:15:40AM -0700: > James G. Sack (jim) wrote: > >from a lwn link, this is interesting stuff about security aspects of > >file descriptors. The scenario painted by Drepper about a browser plugin > > is a convincing justification of recent kernel changes and recommended > >practices regarding use of close-on-exec. > > > >Ulrich Drepper (udrepper) wrote, > >@ 2008-08-01 16:24:00 > >Secure File Descriptor Handling > > http://udrepper.livejournal.com/20407.html > > Okay, that's a bit scary.
Meh. It's protection against sloppy coding, which is better protected against by using a more suitable language than C/C++. > I know that they say they've closed this, but doesn't this mean that > every single UNIX out there is susceptible to this? Certainly looks that way. How often has it been exploited, I wonder? You have to arrange for your exploit code to be invoked, so it would seem pretty tricky. > In addition, I hate to say it, but doesn't this really indicate that the > whole fork/exec/signals system is architecturally broken with respect to > security and that you simply *shouldn't use them at all* if you can? It's already the case that one should minimize code run in a signal handler; invoking fork() and exec() in a signal handler seems to violate this guideline. > Finally, the solution requires active effort to move from "default > shared" to "actively unshared". It is always a bad idea to be "insecure > by default". There should be a system call that is "Only share the > resources I choose to give you." Does that exist? This is the real problem. The fork/exec model presumes single-threaded code, where any resources *not* desired by the child process will be closed before the exec, and that resources will be allocated only while in use. And that the program always knows what resources are allocated at all times... The two examples are in a multi-threaded program (using threads instead of fork/exec for concurrent processes) or in a signal handler that invokes fork() and exec() of untrusted code. The former I see as a valid security concern, the latter I see as an attempt to protect against sloppy programming. And that the proposed (or implemented) "solution" still doesn't solve the problem. Let's say that you have a trusted plugin that needs access to a resource, and you have an untrusted plugin that is going to run some malicious code ... the first plugin does _not_ want close-on-exec semantics, while the second thread (or signal hander) requires such else this same "hole" is exposed. > I wonder how the OpenBSD guys are going to react to this? It looks like > they made FD_CLOEXEC changes several years ago; however, this really > looks like a far-reaching architectural issue. Well, there's the problem of using a web-browser as an application platform to start... I'd rather have a fd_closeall_except( int fd, ... ), as then that could be put into the new process code before the exec() (especially in the signal-handling code). There's probably still a race condition, however, so the real solution would probably be to rethink atomicity. Perhaps if we had some minimum timeslice that could not, ever, be interrupted, and still long enough to get useful work done, a lot of these problems would most likely go away. -- The problem is worth thinking about, even if the solution seems broken. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
