| |||||||||||||
Kernel security, year to dateKernel security, year to datePosted Sep 9, 2008 21:40 UTC (Tue) by bfields (subscriber, #19510)In reply to: Kernel security, year to date by spender Parent article: Kernel security, year to date
RIP = 0, hence trivial arbitrary code execution How does that work? (Just curious.) It's very obvious that this problem is due to the development model they've decided to adopt. Despite its advantages in getting new features out to users more quickly, it has some serious disadvantages: particularly in stability and security. They reaffirm their decision to use this model by pretending the disadvantages don't exist, by trivializing the horrible security of these kernels. How is that obvious? (How do you know that less bugs would be generated with a different model?)
(Log in to post comments)
Kernel security, year to date Posted Sep 9, 2008 21:53 UTC (Tue) by spender (subscriber, #23067) [Link]
Read: http://seclists.org/dailydave/2007/q1/0224.html
As for why the development model being a large reason for the problem, the easiest comparison (if we cover our eyes and assume the numerous vulnerabilities I've mentioned on this site and elsewhere for which there is no CVE don't exist, like the SELinux remote DoS), is to compare the numbers of CVEs for 2.4 against those for 2.6 for this year:
For 2.6 we have 41
-Brad
Kernel security, year to date Posted Sep 9, 2008 22:17 UTC (Tue) by bfields (subscriber, #19510) [Link] Read: http://seclists.org/dailydave/2007/q1/0224.html Following that to the tarball, to the included README.... So the answer is just "mmap buffer at address 0", then trigger the bug that results in calling a function at 0 (or some small offset from that). OK. (Stupid question: are those low addresses always available? I would've thought you'd want to treat the first and last page of the address space specially, exactly to increase the chances of catching such a typical mistake.)
Kernel security, year to date Posted Sep 9, 2008 22:23 UTC (Tue) by paulj (subscriber, #341) [Link] Nah, RIP==0 implies the IP got corrupted (e.g. through stack overflow), which almost certainly means it can be manipulated..
Kernel security, year to date Posted Sep 9, 2008 22:45 UTC (Tue) by spender (subscriber, #23067) [Link]
Not necessarily: all the world isn't a stack overflow (they're actually
quite rare in the kernel). In this case it's much more likely that it was just jumping/calling through a null function pointer -- no tricks needed, just straightforward arbitrary code execution.
-Brad
Kernel security, year to date Posted Sep 9, 2008 23:02 UTC (Tue) by nix (subscriber, #2304) [Link]
Jumping through a null fp could have been a simple bug. There's no
requirement for the content of the pointer to be manipulable by external sources. (Of course it's quite possible, and even the nice case would still make it a DoS attack, and speaks of a missed case in testing, at least: but the kernel has so many configuration options, runs on such a variety of hardware, and makes such heavy use of function pointers that complete coverage of these situations is never going to happen. Alas.
It *is* interesting that most of the holes aren't in old crufty driver
Kernel security, year to date Posted Sep 9, 2008 23:21 UTC (Tue) by jreiser (subscriber, #11027) [Link] the kernel ... makes such heavy use of function pointers that complete coverage of these situations is never going to happen. Why not? Build an option to gcc that tests for zero at every invocation of a non-lexical function, then make that option the default when compiling for Linux kernel. Or, have every interrupt and syscall map a replacement if page 0 already has a user-level mapping.
Kernel security, year to date Posted Sep 10, 2008 8:57 UTC (Wed) by nix (subscriber, #2304) [Link]
Both of these options would be really really -really- expensive (especially the latter: page table manipulation is expensive). The first one has more promise: GCC already has *some* code to insert automatic tests against NULL, it just isn't hooked up in the right places
Kernel security, year to date Posted Sep 10, 2008 4:46 UTC (Wed) by paulj (subscriber, #341) [Link] I very deliberately used "e.g." rather than "i.e." wrt "stack overflow" (I've little idea about how exploits usually work). ;) How does this null function pointer attack work?
Kernel security, year to date Posted Sep 10, 2008 15:22 UTC (Wed) by spender (subscriber, #23067) [Link]
Though I specifically noted the stack overflow case, I was rejecting the general notion that the null ptr dereference was due to some attacker-influenced manipulation or control of kernel data.
These bugs generally crop up from having incomplete handling of all possible cases of working with a pointer. The most fruitful ones are the bugs where it involves using a null pointer to a structure containing a function pointer, or simply a null function pointer itself. The kernel has a ton of the first case: it's the way in which abstractions are made. These grant trivial arbitrary code execution on x86 (just map your code at address 0 and it gets executed in kernel context), whereas in other cases these bugs can be used to provide the kernel with trojaned data -- though the usefulness of this for DoS or privilege elevation has to be determined on a case-by-case basis.
-Brad
Kernel security, year to date Posted Sep 11, 2008 10:01 UTC (Thu) by nix (subscriber, #2304) [Link]
It seems like we should add CAP_LOW_MAP_FIXED to me, set off for virtually everything other than Wine (and the X server, and perhaps a few Lisp interpreters?), and deny MAP_FIXED mmap()s in the low megabyte or so of the address space to processes without that capability. It's not as though most programs would *want* to torpedo their own ability to segfault on null pointer dereferences!
Kernel security, year to date Posted Sep 11, 2008 14:14 UTC (Thu) by paulj (subscriber, #341) [Link]
Huh.. wow. I thought the kernel took care of setting RO mappings for page 0 (and more - the low "ASCII range" of addresses?) to ensure faults, as a security measure (for userspace primarily).
If not, wow. Bring back the seperate user/kernel address space..
Kernel security, year to date Posted Sep 9, 2008 22:31 UTC (Tue) by spender (subscriber, #23067) [Link]
The bugclass is larger than just allocating at 0, it involves all invalid
userland dereferences. So for example, there have been bugs where a pointer was used which had a magic poison value in it, and this poison value resulted in an address which was located somewhere in the middle of the userland address space.
Openwall implemented HARDENED_PAGE0, and a derivative of it has been
-Brad
Kernel security, year to date Posted Sep 9, 2008 22:28 UTC (Tue) by bfields (subscriber, #19510) [Link] As for why the development model being a large reason for the problem, the easiest comparison (if we cover our eyes and assume the numerous vulnerabilities I've mentioned on this site and elsewhere for which there is no CVE don't exist, like the SELinux remote DoS), is to compare the numbers of CVEs for 2.4 against those for 2.6 for this year: Yeah, unfortunately I think you'd have trouble convincing anyone that "number of CVE's" was a very useful statistic. (Unfortunate because it *would* be useful to be able to make those kinds of comparisons. I don't know what would be better. You could do audits of random samples of the code bases in question, but that sounds expensive. Statistics from the static analyzers and such might be better than nothing.)
Kernel security, year to date Posted Sep 9, 2008 22:42 UTC (Tue) by spender (subscriber, #23067) [Link]
Well, unfortunately, it's the same metric being used to gauge the quality
of the Linux kernel's security in the very same article here that you're commenting on. I completely agree that it's highly flawed (as I'd for instance put the actual number of vulnerabilities fixed this year at around 80-100. For every vulnerability that gets public recognition, there is at least one other than does not).
But at the same time, if we take into account the idea of silently fixed
You could also look at how many of the vulnerabilities affected 2.6 only --
-Brad
Kernel security, year to date Posted Sep 9, 2008 23:04 UTC (Tue) by nix (subscriber, #2304) [Link]
I'm not sure static analysis statistics are very useful, because bugs that
can be found by static analysis will have *been* found to some degree, and thus preferentially fixed.
The interesting set is that which no static analysis tool can yet detect.
Kernel security, year to date Posted Sep 9, 2008 23:33 UTC (Tue) by njs (guest, #40338) [Link]
Agreed on CVEs being an imperfect measure, but they're presumably better than nothing, especially if all you want to do is identify trends.
But are you suggesting that 2.6 should switch to the 2.4 development model? Not the original 2.4 development model, the current one -- bug fixes only for years on end. Or... what?
I'm not trying to mock, it's a serious question -- you come in ranting plausibly about security issues being a problem, and how "we" should do something about that, but it's not at all clear to me what -- specifically -- would be better. (And it's a bit off putting that you seem to blame "us" for not doing... well, something...)
There are trade-offs. If a four-fold increase in security holes were really the price of 2.6's improvements compared to 2.4, that actually seems amazingly cheap -- though the real ratio is certainly much worse. How do we do better?
Kernel security, year to date Posted Sep 10, 2008 0:11 UTC (Wed) by spender (subscriber, #23067) [Link]
Even for trends they're problematic: at most it gives you trends in what
gets publicly reported as security bugs; this is a level removed from the kinds of things you would actually want to know.
My personal preference was for the odd/even development model. The current
We had previously extensively discussed changes that could be made to the
At this point, I don't know what to tell you other than you should have
Since you asked though about what can be done to improve kernel security,
-Brad
Kernel security, year to date Posted Sep 11, 2008 9:58 UTC (Thu) by intgr (subscriber, #39733) [Link] The rest of your post I can mostly agree with, but this statement of yours is completely backwards: The PaX team recently has added a feature which prevents exploitation of refcount-based bugs (like the ptrace ones listed in the CVEs in this article). So there are always things that can be done with negligible impact, but don't hold your breath waiting for it to come from the kernel developers themselves. If there are security enhancements that have (supposedly) negligible overhead, then why are not they being pushed towards the mainline where they can benefit everyone? Expecting kernel developers to go to the PaX team begging for their patch is not the way mainline development works. You go as far as to imply that the mainline kernel developers should duplicate this effort -- why? Supposedly, getting patches into the kernel is easy with the current development model. Yes, they have different ideas about how security should be managed, but they are reasonable people. Why is the PaX team not interested in working with the mainline kernel?
Kernel security, year to date Posted Sep 11, 2008 13:47 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> If there are security enhancements that have (supposedly) negligible
> overhead, then why are not they being pushed towards the mainline where > they can benefit everyone?
why does something have to be in mainline to benefit everyone?
> Expecting kernel developers to go to the PaX team begging for their
any source for this (rather silly, i might add) allegiation? last time i checked, the PaX patches were out there freely available to everyone.
> Supposedly, getting patches into the kernel is easy with the current
my experience says otherwise:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...
(unfortunately vger's spam filter ate my mails, so you'll have to piece the story together from the quoted parts). the funny thing is that since last year, when CFS (by Ingo, no less) went into the kernel, it too became victim of the user_mode() mess in that now if you run an endless loop in v86 mode, its runtime will be accounted as system time, not user time. to quote Linus: 'Sad.'
> Why is the PaX team not interested in working with the mainline kernel?
it's the other way around: i've been told explicitly and got it even codified in DCO that anonymous submissions are not to be. i prefer my status over silly policies.
Kernel security, year to date Posted Sep 11, 2008 16:02 UTC (Thu) by pdundas (subscriber, #15203) [Link]
> why does something have to be in mainline to benefit everyone?
It doesn't have to be in mainline to benefit everyone.
> > Expecting kernel developers to go to the PaX team
> any source for this (rather silly, i might add)
I think you're missing the point he was making.
If you want patches to go into mainline (and we just saw
Possibly developing and testing their own code and
Kernel security, year to date Posted Sep 10, 2008 0:16 UTC (Wed) by clugstj (subscriber, #4020) [Link]
No, actually, the rate of CVEs creation could easily be worse than nothing. It could actually not be related to the actual number of bugs in the kernel. As long as there are enough bugs (which there are in any piece of complex software) to create CVEs, you could manipulate the CVE creation rate if you were so inclined.
Kernel security, year to date Posted Sep 9, 2008 22:47 UTC (Tue) by nix (subscriber, #2304) [Link]
A development model in which nothing ever changed would introduce no new
bugs. The current development model has a high change rate.
The remainder follows by induction.
(Not that it's very *useful*, but when was the last time you heard of a
Development model Posted Sep 10, 2008 21:28 UTC (Wed) by man_ls (subscriber, #15091) [Link] So true. And with the current rate of changes, any statistics are less than useful: the last development cycle may have produced some 170k new lines and maybe 20 vulnerabilities. That is one CVE per 8k lines of code, i.e. a needle in a haystack.A really useful study on vulnerabilities would have to contemplate (as our editor suggests) the rate of changes, the rate of introduction and the rate of removal; and compare with other development models. Anything else is just anecdotal evidence.
|
|||||||||||||