| |||||||||||||
vmsplice(): the making of a local root exploitvmsplice(): the making of a local root exploitPosted Feb 12, 2008 19:40 UTC (Tue) by bronson (subscriber, #4806)Parent article: vmsplice(): the making of a local root exploit
Given how few userspace programs actually use vmsplice, is it safe to say that the largest user of this system call is the exploit? (Some quick google and koders searching implies this; please tell me if my impression is wrong.) I'm curious why nobody has been talking about purging this demonstrably scary call from the kernel. Why not redesign it so this sort of mistake will be easier to find in the future? Ultimately, I guess here's my question: is there any quantifiable reason to believe the current fix isn't a premature botch the way the previous fixes were?
(Log in to post comments)
vmsplice(): the making of a local root exploit Posted Feb 12, 2008 20:57 UTC (Tue) by nix (subscriber, #2304) [Link] The reason why it's not widely used yet is because it's quite new. Many people probably don't even have a glibc with this call in (it was added in 2.5), and there's a long lag time after that before applications can start relying on it (or even benefiting detectably from it).
vmsplice(): the making of a local root exploit Posted Feb 12, 2008 21:40 UTC (Tue) by tialaramex (subscriber, #21167) [Link] There's nothing particularly scary about this system call. To put this into perspective, dozens of calls with this sort of problem have been found in the history of Linux. Dozens in Windows NT. Dozens in official AT&T branded Unix. The problem was fixed and you're still using the relevant system calls. There are tools that are supposed to look for this sort of problem in your OS, but of course if you keep inventing system calls, someone has to update the tools to know about the new system calls, and if there were people being that vigilant, you'd hope that at least two of the three bugs that lead to this discussion would have been spotted before they got into the Linus kernel tree. What you're looking at here is boring human error. No interesting design lessons. No fundamental principles that ought to be reconsidered (unless you consider the hilarious proposals earlier in comments that Linux should be re-written in a dynamic type system where the OS would spend all its time validating your input parameters and not getting any work done...)
vmsplice(): the making of a local root exploit Posted Feb 12, 2008 22:32 UTC (Tue) by nix (subscriber, #2304) [Link] I think the intention was to model it on type-inferencing strongly typed systems, actually: but of course that sort of inferencing can't cross the separate-compilation-and-language abstraction boundary between the kernel and userspace (not to mention the privilege boundary, which is perhaps less significant in this case).
|
|||||||||||||