| |||||||||||||
Stable kernel 2.6.25.10
The 2.6.25.10 stable kernel update has been
released. "It contains a number of assorted bugfixes all over the
tree. And once again, any users of the 2.6.25 kernel series are STRONGLY
encouraged to upgrade to this release."
(Log in to post comments)
Stable kernel 2.6.25.10 Posted Jul 3, 2008 14:44 UTC (Thu) by Los__D (guest, #15263) [Link] Again a well-timed kernel release, just a few hours (3:58 UTC) after the Weekly Edition has been published. Sometimes one wonders if they do it on purpose, just to tease our #1. :)
Stable kernel 2.6.25.10 Posted Jul 3, 2008 15:34 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] ..and once again, users get the usual treatment of not actually being told why an upgrade is so strongly encouraged. it seems that in this episode of the -stable security fix coverup series (that's not to say that the corresponding vanilla commits got a better treatment), we got at least two fine examples of how such bugs should not fall victim of the kernel devs' full disclosure policy. as for the particular bugs: 1. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.... adds several checks against NULL function pointers, which is an immediate 'get direct ring-0 code execution' flag, unfortunately we don't learn whether this is actually possible or not, but one assumes the STRONGLY encouraged upgrade wasn't for nothing at least. 2. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.... is an even better one, it allows one to overflow the task struct refcount (a 32 bit atomic_t on the affected amd64) and cause its subsequent freeing with dangling references to it all over the place (including 'current' of the ptraced task itself). corresponding exploit avenues abound. Greg, instead of witchhunting on vendor-sec you guys should sit down and decide what you want for your disclosure policy for real. the next Kernel Summit would be a good opportunity i think.
Stable kernel 2.6.25.10 Posted Jul 3, 2008 17:07 UTC (Thu) by gregkh (subscriber, #8) [Link] > Greg, Once again, if you have any comments, questions, or concerns about how I and the other kernel developers are handling the -stable updates and notifications, please do so on the linux-kernel mailing list and I will be very glad to discuss them there, in public. > instead of witchhunting on vendor-sec I'm confused, what do you mean by this?
Stable kernel 2.6.25.10 Posted Jul 3, 2008 17:21 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] Greg, you probably misunderstood me. i do *not* care about the disclosure policy you choose (*that* discussion is something *you* kernel devs have to have, i have zero influence on it). what i do care about is that once you decided it, you stick to it and when you don't (remember, it's supposedly still 'full disclosure' as of now), i'll point it out. in any case, if you really really want me to get involved in all this (i very much doubt you do, but you can prove yourself now), start that thread yourself and CC spender and me. > > instead of witchhunting on vendor-sec > I'm confused, what do you mean by this? make the vendor-sec archives public and i'll explain. deal? ;)
Stable kernel 2.6.25.10 Posted Jul 3, 2008 17:51 UTC (Thu) by gregkh (subscriber, #8) [Link] > if you really really want me to get involved in all this (i very much doubt > you do, but you can prove yourself now), start that thread yourself and CC > spender and me. Sure, email addresses to cc:? > > instead of witchhunting on vendor-sec > I'm confused, what do you mean by this? make the vendor-sec archives public and i'll explain. deal? ;) I have no control over vendor-sec archives. If you disagree with this policy, bring it up on vendor-sec, where it can be discussed and possibly changed.
Stable kernel 2.6.25.10 Posted Jul 3, 2008 18:09 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] pageexec@freemail.hu (spender chose not to be CC'd in the end) > If you disagree with this policy, i don't agree with it (nor with the secrecy and corresponding unaccountability of other lists like the kernel security one) > bring it up on vendor-sec, where it can be discussed and possibly changed. it can be discussed, but it can't possibly be changed, and you know that full well. case in point, you guys decided against letting in individual researchers on vendor-sec. how could you possibly agree on opening up the same discussions these private researchers would have been privy to then? obviously you will never do that and there's no point in having fake discussions whose outcome has already been decided.
Stable kernel 2.6.25.10 Posted Jul 4, 2008 9:36 UTC (Fri) by PaXTeam (subscriber, #24616) [Link] > Once again, if you have any comments, questions, or concerns about how I > and the other kernel developers are handling the -stable updates and > notifications, please do so on the linux-kernel mailing list and I will > be very glad to discuss them there, in public. so, i did just that yesterday. note that you might want to fix your spam filters because i didn't see my mail show up in the archives nor did i get a bounce. but at least the individuals on CC (yourself included) should have got it. for reference for others in case it doesn't make it into the archives: On 3 Jul 2008 at 11:57, Greg KH wrote: > On Thu, Jul 03, 2008 at 10:29:14AM -0700, Greg KH wrote: > Adding 2 more addresses to this thread, as they were said to have > questions about this kernel release. not only this one, but every commit for the past few years that fixed bugs with security impact. for reference: http://lwn.net/Articles/285438/ http://lwn.net/Articles/286263/ http://lwn.net/Articles/287339/ http://lwn.net/Articles/288473/ > Again, if the above information is somehow insufficient as to what > exactly is fixed in the -stable releases, and anyone has questions about > how these release announcements are created, please let me know. what is the disclosure policy used for commits fixing bugs with security impact (both vanilla and -stable, especially if there's a difference)? what do you include/omit? how does it relate to what is declared in Documentation/SecurityBugs?
Stable kernel 2.6.25.10 Posted Jul 5, 2008 15:53 UTC (Sat) by bfields (subscriber, #19510) [Link] "note that you might want to fix your spam filters because i didn't see my mail show up in the archives nor did i get a bounce." Email postmaster at vger--I've had trouble with their spam filters once or twice and found them to be very responsive.
Stable kernel 2.6.25.10 Posted Jul 3, 2008 23:43 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Re: 1: "... unfortunately, we don't learn whether this is actually possible or not..." Pardon me, it doesn't matter if it could be exploited or not, the one doing the checking that it is not a real vulnerability could make a mistake, or a later change could make it exploitable. Better check. Re: 2: The kernel is the most privileged piece of software on the machine, mistakes that would be a minor annoyance elsewhere are very serious and potentially disastrous here. Nothing particular to disclose...
Stable kernel 2.6.25.10 Posted Jul 4, 2008 0:50 UTC (Fri) by jreiser (subscriber, #11027) [Link] The kernel is the most privileged piece of software on the machineIn some important ways the kernel has defered to the settings of the selinux policy that is in effect. In those areas, the selinux policy is the most privileged software in the machine; the kernel does whatever the policy says.
Stable kernel 2.6.25.10 Posted Jul 4, 2008 3:37 UTC (Fri) by spender (subscriber, #23067) [Link] Except for when you own the kernel and disable SELinux entirely. -Brad
Stable kernel 2.6.25.10 Posted Jul 4, 2008 9:30 UTC (Fri) by PaXTeam (subscriber, #24616) [Link] i'm not sure you entirely understand this whole userland/kernel separation thing and the issue of privilege elevation. the short story is that your CPU offers privileged instructions and a corresponding privileged operation mode (or modes) that are, well, privileged, not meant to be executed by normal userland because of their impact on the security model implemented by the kernel. think of, say, page table manipulation, modifying credentials information stored in kernel (read: privileged) memory, etc. if there is a bug in privileged code that userland can abuse in order to elevate its own privilege then that is called a security problem and people *do* care about them (whether you personally care about such security problems is your business of course, but you don't get to tell what others care about). since not all kernel bugs can be abused for privilege elevation, it is very important and in accordance with the disclosure policy declared by the kernel devs to disclose such information.
Stable kernel 2.6.25.10 Posted Jul 4, 2008 14:32 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Yes, I do understand this stuff. But I've also fixed bugs that turned out (later!) to be security vulnerabilities. Sure, "possible buffer overflow" (and other classes) is a big warning sign, but not a guarantee that it is exploitable. I much prefer kernel (and other) developers fixing bugs than running around finding out if bugs can be exploited. And a bug that can't be exploited today might become exploitable in the future due to changes elsewhere. Finding out if a bug is exploitable is a different skill than development.
Stable kernel 2.6.25.10 Posted Jul 4, 2008 14:54 UTC (Fri) by PaXTeam (subscriber, #24616) [Link] > Yes, I do understand this stuff. so what made you say that a refcount overflow or a null function pointer dereference are not security issues worthy of disclosure? if even you are aware of these exploitable bug classes, then certainly we can expect kernel devs dealing with security issues to know better as well. > But I've also fixed bugs that turned out (later!) to be security vulnerabilities. i wasn't talking about bugs whose security impact was realized only later. in this case both bugs are representative of well known exploitable bug classes, and at least one of them was discussed on vendor-sec, yet no CVE or any sort of disclosure is in sight. > Sure, "possible buffer overflow" (and other classes) is a big warning > sign, but not a guarantee that it is exploitable. in which case the prudent approach is to err on the side of safety and declare it as a potentially exploitable bug, not covering it up for good. > I much prefer kernel (and other) developers fixing bugs than running > around finding out if bugs can be exploited. you're welcome to read the previous threads as this has been discussed already: noone expects kernel devs to do this kind of evaluation. what people do expect from them is following Documentation/SecurityBugs and disclose security impact information when they're aware of it. besides, they're well aware of severaly exploitable bug classes, they don't have to find out anything to mention that detail in the commit. > And a bug that can't be exploited today might become exploitable in the > future due to changes elsewhere. are you suggesting that kernel devs leave bugs unfixed in the hope they become actually exploitable in the future? else the above doesn't make any sense, if a bug is known and fixed, how can it become exploitable in the future? > Finding out if a bug is exploitable is a different skill than development. agreed and it's not the subject of this discussion.
Stable kernel 2.6.25.10 Posted Jul 6, 2008 9:05 UTC (Sun) by avik (guest, #704) [Link] null function pointers are only exploitable if vm.mmap_min_addr is zero, which should not be the case on most installations. I imagine getting 4G references on a task_struct would be hard without root privileges.
Stable kernel 2.6.25.10 Posted Jul 6, 2008 10:49 UTC (Sun) by nix (subscriber, #2304) [Link] If they're in an array of structures and you can integer-overflow the array index, suddenly they're dangerous again.
Stable kernel 2.6.25.10 Posted Jul 6, 2008 10:55 UTC (Sun) by PaXTeam (subscriber, #24616) [Link] > null function pointers are only exploitable if vm.mmap_min_addr is zero, no, if a process has CAP_SYS_RAWIO it can also evade the 0 mmap restriction (and let's ignore the early implementation bugs of this feature). if a process doesn't yet have CAP_SYS_RAWIO, it can 'acquire' it by exploiting another that does have it (think of X for example or any suid root process). or alternatively, one has to use SELinux and make sure no process can be granted MEMPROTECT__MMAP_ZERO. and all of this breaks valid userland programs, so it's not a universal solution (it's default off for that reason). > which should not be the case on most installations. any statistics to back it up? remember, it needs both CONFIG_SECURITY and be set to some meaningful value. in any case, i'm not sure what you were trying to say, if a bug falls into a known exploitable bug class then it should be reported as such (or briefly explained why it's not what it looks like), regardless of what mitigation factors may apply in a given installation. such info belongs to vendor advisories at most, not a kernel commit message. > I imagine getting 4G references on a task_struct would be hard without > root privileges. the patch fixes a few ptrace commands that can be issued by any user, not only root. therefore it's triggerable and exploitable by any user who's not otherwise prevented from using ptrace. as for the technical feasibility of issuing 4G ptrace calls, on a core2 a single GETREGS takes less than 30 usec, that's less than 2 days of runtime.
Stable kernel 2.6.25.10 Posted Jul 6, 2008 14:02 UTC (Sun) by nix (subscriber, #2304) [Link] To me, the fact that it breaks GDB is more significant, but then I don't have dedicated maniacs attacking my systems with billions of custom-written ptrace()s (and if they did, it would take them days and there's no way I'd not notice even if I was on another continent).
Stable kernel 2.6.25.10 Posted Jul 7, 2008 2:35 UTC (Mon) by spender (subscriber, #23067) [Link] I wrote a working PoC for the vulnerability today. It only takes 20 minutes for me (inside a 3.3ghz single-processor VM). -Brad
Stable kernel 2.6.25.10 Posted Jul 7, 2008 6:48 UTC (Mon) by nix (subscriber, #2304) [Link] ... and if it took you twenty minutes, your average script kiddie would take weeks, if ever. (Of course, buying a copy from a blackhat with similar skills would probably be faster.)
Stable kernel 2.6.25.10 Posted Jul 7, 2008 7:49 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] the 20 mins was the runtime of the exploit, not its development time.
Stable kernel 2.6.25.10 Posted Jul 7, 2008 19:43 UTC (Mon) by nix (subscriber, #2304) [Link] I thought 20 minutes seemed awfully fast to write an exploit from scratch, but I'm not very good at that sort of thing so I thought maybe skilled people are faster. (Still, if a random blackhat tries to eat that amount of CPU time on any of my security-important systems all sorts of alarms would go off. But maybe that's more paranoia than most people show, and I suppose if the attacker knew about those monitoring systems he could distribute the computational work among numerous processes and a long stretch of time. Still, again, if an attacker knows that much, I'm dead anyway. Maybe this is significant to unmonitored systems with untrusted local users, and I suppose it makes it easier to escalate to root once you've got in via some vulnerable network service, but if the attacker's managed that, again, you're dead anyway: and most attackers these days don't *care* about escalation to root: all they care about is being able to spam like crazy, and being able to spy on the user, and an attack via, say, a browser vulnerability will give them all of that.)
Stable kernel 2.6.25.10 Posted Jul 4, 2008 11:01 UTC (Fri) by ledow (guest, #11753) [Link] Personally, I'm beginning to find the comments by PaXTeam on every single kernel release more than a little tiring, especially seeing as I don't see dialogue about these issues anywhere else. I'm only a user, but I *do* think PaXTeam may have a point (although for 99% of end-users, just the fact that they need to upgrade is sufficient, not the exact details of why). The problem is that PaXTeam is stating it very poorly and coming across as "superior to all", and doing so in the wrong place repeatedly. This is making people like myself tune such comments out. This is counter-acting any possible good they think they are doing by bringing this information to the world - the boy who cried wolf and all that. Please, do something other than post to random websites - put up a page on a blog listing your concerns that people who are interested can read, post links to it on the LKML, anything, but stop spamming every single kernel announcement on an otherwise relatively-spam-free website. You've been given an opportunity for dialogue several times and it looks like you've finally taken it up. Please let this be the end of the matter because anyone interested in the kernel maintainers responses can view them, or look for your website/blog and keep track.
Stable kernel 2.6.25.10 Posted Jul 4, 2008 14:31 UTC (Fri) by zakalwe2 (guest, #50472) [Link] For a start, he's not crying wolf. It's pretty clear from his posts that these issues are real. The majority of the people who understand these security issues are actively trying to abuse them. The kernel developers either wish to down play the situation so linux doesn't look bad, don't understand, or do understand but have undeclared motives. It's the PaXTeam and spender who are exposing the seriousness of the situation. Not only that, they are the ones that have been pioneering practical exploit mitigation for the last 7-8 years openly, and for free. PaX features have ended up in every other OS but end up in linux last and watered down. To label his comments on linux security as spam is ridiculous quite frankly. FWIW all my dealings with the PaXTeam and spender have been exemplary. Any issue I've had was answered or fixed unbelievably quickly. They are extremely helpful when approached, yet afaik no kernel developer has ever actually approached them. The only difficiency in their approach is that they spend time dealing with trolls like you. A certain kernel developer said that the kernel land ssp implementation would have mitigated the vmsplice exploit earlier in the year. The PaXTeam showed (on lkml) that it didn't even work as intended, fixed it and explained it's shortcomings. I don't think this has even been fixed upstream, months later. Also, this is not a "random website". It's a (the?) site dedicated to helping users and developers digest what's happening in the linux world and discuss it. Not everyone can follow lkml.
Stable kernel 2.6.25.10 Posted Jul 5, 2008 16:57 UTC (Sat) by tialaramex (subscriber, #21167) [Link] We know that they cry wolf because we've watched it happen. In http://lwn.net/Articles/286321/ I demolished spender's analysis of a "trivially exploitable" bug that hadn't been fixed in stable, and in the follow-up it was revealed that he hadn't even been looking at stable, but rather at an unreleased kernel tree. I'm no security expert, just an ordinary engineer who prefers to read for himself rather than trusting what he's told by self-declared experts. Spender offered no reply, do you think he'd have pointed out his (very serious) error voluntarily? Anyone who knows the status of PaX can judge for themselves whether a motive exists for PaX supporters to rubbish the 2.6 stable series here rather than actually engage with developers.
Stable kernel 2.6.25.10 Posted Jul 8, 2008 1:30 UTC (Tue) by hawk (subscriber, #3195) [Link] Well, I for one also find the recurring flood of comments by PaXTeam a bit tiresome. I'm not saying that they are wrong about there being a problem but there are some serious issues with their presentation and attitude. For one thing, why make this into some sort of conspiracy theory?! If they think that LWN is a good place to bring the subject up, I think they should consider writing and submitting an actual article instead of flooding the comment section of kernel release news items over and over and over and over and over and over and over and over and over and over and over again.
|
|||||||||||||