Latest stable sys-kernel/hardened-sources-2.6.32-r9 is exploitable giving a root access to unprivileged user Reproducible: Always Steps to Reproduce: test@brat-sas /tmp $ ./robert resolved symbol commit_creds to 0xffffffff81058850 resolved symbol prepare_kernel_cred to 0xffffffff81058700 mapping at 3f80000000 UID 0, EUID:0 GID:0, EGID:0 sh-4.0# uname -a Linux brat-sas 2.6.32-hardened-r9 #1 SMP Tue Aug 31 13:38:30 EEST 2010 x86_64 Quad-Core AMD Opteron(tm) Processor 2372 HE AuthenticAMD GNU/Linux sh-4.0# id uid=0(root) gid=0(root) groups=0(root)
More information from https://bugzilla.redhat.com/show_bug.cgi?id=634449: This bug is a CVE-2007-4573 regression. Reintroduced in v2.6.27-rc1 via commit d4d67150. Patches: http://git.kernel.org/linus/36d001c70d8a0144ac1d038f6876c484849a74de http://git.kernel.org/linus/eefdca043e8391dcd719711716492063030b55ac
comfirm this bug: slep@mini ~ $ ./a.out resolved symbol commit_creds to 0xffffffff810651e0 resolved symbol prepare_kernel_cred to 0xffffffff810658d0 mapping at 3f80000000 UID 0, EUID:0 GID:0, EGID:0 sh-4.1# id uid=0(root) gid=0(root) группы=0(root) sh-4.1# uname -a Linux mini 2.6.35-gentoo-r5-1.04 #1 SMP PREEMPT Sun Sep 5 04:09:31 EEST 2010 x86_64 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux sh-4.1#
Patches included in gentoo-sources versions: 2.6.32-r17, 2.6.34-r10 and 2.6.35-r7
The grsec patch in hardened-sources-2.6.32-r18 and hardened-sources-2.6.34-r6 address this.
Created attachment 248243 [details, diff] Fix CVE-2010-3301 on the current stable kernel I have adapted the solution implemented in vanilla kernel to the current Gentoo Hardened kernel, 2.6.32-hardened-r9. I have applied the patch on my own servers and am using it in production. Please release a GLSA with this patch ASAP... We shouldn't have to wait for the normal stabilization process of a new kernel to get a critical security fix.
In the meantime, removing access to the kernel symbols is an important mitigation to this problem. Enable CONFIG_GRKERNSEC_HIDESYM (Security options -> Grsecurity -> Grsecurity -> Address Space Protection -> Hide kernel symbols) to restrict access to the symbols table only to users with the CAP_SYS_MODULE capability (effectively, root). This effectively breaks the publicly known proof-of-concept by Ben Hawkes, as well as the more malicious exploit by "Ac1dB1tch3z", as they are unable to obtain the addresses of the kernel functions they use in order to alter their task's privileges. Of course, the underlying vulnerability is still there. Relying on obscurity alone will not solve the problem. The patch I submitted was tested using the aforementioned known exploits, and it solves the problem. We need a GLSA with the fix, please...
(In reply to comment #5) > Please release a GLSA with this patch ASAP... We shouldn't have to wait for the > normal stabilization process of a new kernel to get a critical security fix. > There is no such thing as a GLSA for the kernel. Both the kernel and hardened-kernel teams are testing the new sources and will call for stabilization asap.
(In reply to comment #7) > (In reply to comment #5) > > > Please release a GLSA with this patch ASAP... We shouldn't have to wait for the > > normal stabilization process of a new kernel to get a critical security fix. > > > > There is no such thing as a GLSA for the kernel. > Both the kernel and hardened-kernel teams are testing the new sources and will > call for stabilization asap. > I've ask hardened users to test 2.6.32-r18 and 2.6.34-r6 and I've been using both since the 18th. I have hit no issues yet. a3li, is it okay to ask for stabilization this soon? I was going to wait another week at least. Nonetheless, keep in mind that even with access to the symbol info on unpatched 2.6.32-r9, if you enable CONFIG_PAX_MEMORY_UDEREF=y, the exploit fails. Hardened users with UDEREF are safe on current stable. The problem comes for those users which have to disable UDEREF for other reasons (eg for virtualization.)
(In reply to comment #8) > > I've ask hardened users to test 2.6.32-r18 and 2.6.34-r6 and I've been using > both since the 18th. I have hit no issues yet. a3li, is it okay to ask for > stabilization this soon? I was going to wait another week at least. You have our blessing for stabilizing it as soon as you deem it ready.
Whether it's called a GLSA or not, this is not something that can possibly wait for the normal stabilization processes. One week is one week too late; other distributions have already taken action. This is a very real root compromise, albeit a local one. There are known exploits in the wild. Surely the Gentoo Hardened team, with its commendable and very valuable effort towards maintaining a high standard of security, on which so many of us have come to rely, would want to have a quick response time to such a serious security threat when a fix is readily available. In my humble opinion, three days with a known fix is already long enough...
(In reply to comment #10) > with its commendable and > very valuable effort towards maintaining a high standard of security, on which > so many of us have come to rely, would want to have a quick response time to > such a serious security threat when a fix is readily available. > > In my humble opinion, three days with a known fix is already long enough... > Rushing to a fix is often worse than the problem you are trying to avoid. The fix was in the tree only 1 day after the CVE announcement. Only some configurations of stable hardened are vulnerable. I immediately tested and informed the gentoo-hardened@ list about how to protect until the fix hit the tree. For all of the above reasons, your criticism is unfair. Please help out by testing 2.6.32-r18 and 2.6.34-r6 and reporting back. In the mean time, I'll start a stablereq.
> > In the mean time, I'll start a stablereq. > See bug #338273.
(In reply to comment #11) > > Only some configurations of stable hardened are vulnerable. I immediately > tested and informed the gentoo-hardened@ list about how to protect until the > fix hit the tree. I wouldn't say that it's so few configurations... to my knowledge, unless someone has specifically enabled the restrictions on symbol addresses (kallsyms), or the PAX_MEMORY_UDEREF protection mentioned by Anthony, they are vulnerable. Even then, the kallsyms restrictions aren't, in my opinion, any kind of solution. They provide obscurity and work as defense in depth, but there's no guarantee that some smarter exploit doesn't exist, which doesn't need so much information. Same for the usermode addresses prevented by UDEREF. I am not implying that you don't already know this, or that you haven't taken this into consideration. My point is only that the problem may affect many systems, and given the seriousness of what can happen, the threat is very grave indeed. > > For all of the above reasons, your criticism is unfair. Please help out by > testing 2.6.32-r18 and 2.6.34-r6 and reporting back. > Please do not take my comments as a form of criticism; that was not my intent. I would not be using Gentoo Hardened if I didn't appreciate the effort and quality of your work, as I tried to note in my previous comment. I was only attempting to point out what I believe to be the need for very urgent action, independently of other improvements that might be in the pipe. It just seems unintuitive to me that a serious security fix should have to wait for testing and stabilization of a tree that contains other features. I did try to help, by providing the code fix which I used against the current kernel. Unfortunately my Hardened boxes are all in production right now (which was why I had to patch the stable kernel in the first place), and I don't have much time in my hands to setup a test system for the new kernels. > In the mean time, I'll start a stablereq. > Thank you for your efforts.
Doesn't this problem also impact non-hardened users? While clearly it has gotten more attention from the hardened problem, I think the current stable non-hardened kernel is completely vulnerable under any configuration that enables 32-bit execution. It doesn't have any of the mitigating factors that the hardened variant has, either. If I'm misinformed let me know, but this seems like a pretty high-profile issue, and judging by the reactions of other distros most would seem to agree.
> Doesn't this problem also impact non-hardened users? Yes, it does. Yes, it is a high profile issue (perhaps exacerbated further by the fact that the solution to this vulnerability was reversed out two years ago). In my view, all the stops should be pulled out in order to fast-track rectified ebuilds to stable and, while kernel vulnerabilities are not subject to the GLSA process, this would merit a general announcement - as did the vmsplice issue for instance. Let's take stock of the situation. In terms of vanilla kernels, these are fixed: 2.6.35.5 2.6.32.22 (a long term stable branch) Those using any other 2.6.X.Y branch shouldn't hold their breath. In terms of genpatches: >= 2.6.35-8 (that's gentoo-sources-2.6.35-r7 which is still ~arch keyworded) As per the comments that have passed, this is no way a criticism, but I would also urge that the matter be expedited as quickly as possible, particularly in those situations where the patches introduced are proven and tested fixes and/or upstream stable patches, as is likely the case here. With hardened-sources it is perhaps more tricky because each new instance of the grsecurity patch will contain various changes and, in this case, the fixes have been consumed via said patch.
Hardened-sources 2.6.32-r18 and 2.6.34-r6 have been marked stable for amd64 in the tree. See bug #338273. Please please please test! I realize the urgency to stabilize, but I feel uncomfortable with the fact that these were marked stable before they'd had time to mature.
(In reply to comment #16) > Hardened-sources 2.6.32-r18 and 2.6.34-r6 have been marked stable for amd64 in > the tree. See bug #338273. > > Please please please test! I realize the urgency to stabilize, but I feel > uncomfortable with the fact that these were marked stable before they'd had > time to mature. > Thank you for your prompt action regarding this, Anthony. I understand your concern for stability. I think that's important and it's one of the reasons why I like Gentoo so much. May I ask, out of curiosity, if you had considered releasing a hardened-sources-2.6.32-r9a, where the only change from stable 2.6.32-r9 would be the ~10 lines in ia32entry.S necessary for the security fix? That could have been fastracked for stability without so much concern, and it would avoid having to stabilize all the unrelated changes in -r18 ahead of time. That was the suggestion I was trying to make before; perhaps I didn't make it as clear as I could have. I believe I can place one blade on the new 2.6.32-r18 for testing, and leave the rest of the production servers with my patched version of 2.6.32-r9. Hopefully all will go well; if I find any weird behavior I will report it.
Forgot to mention... I don't know what the policy is on security announcements for the kernel. I don't know the specific reasons for there being no GLSAs here, but given the impact of this exploit, I believe it would be a good idea to follow Kerin's suggestion and warn the general public about this update, much in the same way as was done for vmsplice. Also, is there any idea on the status of this fix for the non-hardened gentoo-sources? Those users are also very much vulnerable to the problem, as Richard indicated -- in fact, they are much more exposed, since they don't have the features that protected us from the known PoC in hardened.
Re: Comment 16 - As you probably know, I don't use hardened-sources anymore. However, for what it's worth, I have recently deployed kernels patched with grsec-2.6.32.21-201009171945 to four servers without issue. Re: Comment 18 - Essentially, gentoo-sources-2.6.35-r8 is effectively pending stabilisation (with -r7 also being safe to use). On the other hand, no iterations of gentoo-sources-2.6.35 are currently keyworded stable. If the intention is for 2.6.34 to remain the stable keyworded branch for the near future then we need a new release there. I can see that Mike has committed the necessary patches in trunk [1] but there needs to be a tagged release of genpatches and a revised 2.6.34 ebuild to accompany it, assuming that the 2.6.34 patches are not merely for the benefit of other ebuilds which brings me on to my next point ... It should be borne in mind that gentoo-sources is not the only sys-kernel/* ebuild that consumes genpatches and this bug cannot be closed for as long as vulnerable kernels remain in the tree. Therefore, some backporting work may well be prudent. In order to be able to take a clear view of the situation, I will endeavour to post a concise but comprehensive summary of affected kernels and their status in due course. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/linux-patches/genpatches-2.6/trunk/2.6.34/
(In reply to comment #19) > there needs to be a tagged release of > genpatches and a revised 2.6.34 ebuild to accompany it, assuming that the > 2.6.34 patches are not merely for the benefit of other ebuilds which brings me > on to my next point ... mpagano stated that they were in the tree in comment #3... genpatches 2.6.34-12 was tagged and released on sept 16. It was available as 2.6.34-r10 the same day. It is however lagging the same stablereq.
Firstly, my apologies to Mike as my previous comment about gentoo-sources-2.6.34 still needed a new release was, of course, in error (as Robin has just pointed out) ... duh. I've now performed a fairly detailed review of the kernel ebuilds currently in the tree. I'm aware that not all of these are officially supported for security purposes but have not chosen to omit any packages (except where noted) on the basis that their respective maintainers may see fit to address this bug of their own accord. I should start by mentioning that the lower bound for acceptable genpatches releases for the 2.6.32, 2.6.34 and 2.6.35 branches is as follows: >= 2.6.32-20 >= 2.6.34-12 >= 2.6.35-8 A breakdown of kernel ebuilds that consume genpatches follows ... LEGEND: -- UNPATCHED / ASSUMED VULNERABLE ** PATCHED VIA GENPATCHES ++ PATCHED INDEPENDENTLY -- ck-sources-2.6-34-r1 [genpatches-2.6.34-3] -- ck-sources-2.6-34-r2 [genpatches-2.6.34-9] -- ck-sources-2.6-34-r3 [genpatches-2.6.34-10] -- ck-sources-2.6-35-r1 [genpatches-2.6.35-2] -- ck-sources-2.6-35-r2 [genpatches-2.6.35-6] -- gentoo-sources-2.6-27-r8 [genpatches-2.6.27-10] -- gentoo-sources-2.6-27-r10 [genpatches-2.6.27-12] -- gentoo-sources-2.6-28-r6 [genpatches-2.6.28-9] -- gentoo-sources-2.6-29-r5 [genpatches-2.6.29-7] -- gentoo-sources-2.6-29-r6 [genpatches-2.6.29-8] -- gentoo-sources-2.6-32-r7 [genpatches-2.6.32-8] -- gentoo-sources-2.6-32-r15 [genpatches-2.6.32-18] -- gentoo-sources-2.6-32-r16 [genpatches-2.6.32-19] ** gentoo-sources-2.6-32-r17 [genpatches-2.6.32-20] ** gentoo-sources-2.6-32-r18 [genpatches-2.6.32-21] -- gentoo-sources-2.6-33-r2 [genpatches-2.6.33-3] -- gentoo-sources-2.6-33-r3 [genpatches-2.6.33-4] -- gentoo-sources-2.6-34-r1 [genpatches-2.6.34-3] -- gentoo-sources-2.6-34-r6 [genpatches-2.6.34-8] -- gentoo-sources-2.6-34-r7 [genpatches-2.6.34-9] -- gentoo-sources-2.6-34-r8 [genpatches-2.6.34-10] -- gentoo-sources-2.6-34-r9 [genpatches-2.6.34-11] ** gentoo-sources-2.6-34-r10 [genpatches-2.6.34-12] -- gentoo-sources-2.6-35-r4 [genpatches-2.6.35-5] -- gentoo-sources-2.6-35-r5 [genpatches-2.6.35-6] -- gentoo-sources-2.6-35-r6 [genpatches-2.6.35-7] ** gentoo-sources-2.6-35-r7 [genpatches-2.6.35-8] ** gentoo-sources-2.6-35-r8 [genpatches-2.6.35-9] -- hardened-sources-2.6-28-r9 [genpatches-2.6.28-9] -- hardened-sources-2.6-32-r9 [genpatches-2.6.32-13] -- hardened-sources-2.6-32-r16 [genpatches-2.6.32-19] -- hardened-sources-2.6-32-r17 [genpatches-2.6.32-19] ++ hardened-sources-2.6-32-r18 [genpatches-2.6.32-19] -- hardened-sources-2.6-34-r4 [genpatches-2.6.34-10] -- hardened-sources-2.6-34-r5 [genpatches-2.6.34-10] ++ hardened-sources-2.6-34-r6 [genpatches-2.6.34-11] -- tuxonice-sources-2.6-32-r17 [genpatches-2.6.32-20] -- tuxonice-sources-2.6-34-r6 [genpatches-2.6.34-12] ** tuxonice-sources-2.6-35-r3 [genpatches-2.6.35-8] -- xen-sources-2.6-31-r11 [genpatches-2.6.31-11] -- xen-sources-2.6-31-r14 [genpatches-2.6.31-11] -- xen-sources-2.6-32-r1 [genpatches-2.6.32-9] -- xen-sources-2.6-34 [genpatches-2.6.34-2] -- xen-sources-2.6-34-r3 [genpatches-2.6.34-9] ----------------------------------------------------- A breakdown of kernel ebuilds that do _not_ consume genpatches follows ... NOTE: patches can be bulled from "linux-patches/genpatches-2.6/tags" in CVS, courtesy of Mike Pagano. See the top of this post for the precise versions. Omitted: * git-sources * vanilla-sources -- mips-sources-2.6.29.1 -- mips-sources-2.6.31.12 -- mips-sources-2.6.34 -- mm-sources-2.6.28_rc2-r1 (*) -- openvz-sources-2.6.27.6.1-r1 ++ openvz-sources-2.6.27.7.1 ++ openvz-sources-2.6.32.9.1 -- pf-sources-2.6.31_p9 -- pf-sources-2.6.32_p16 -- pf-sources-2.6.33_p4 -- pf-sources-2.6.34_p7 -- pf-sources-2.6.35_p7 -- zen-sources-2.6.30_p11 -- zen-sources-2.6.31_p12 -- zen-sources-2.6.32_p6 -- zen-sources-2.6.32_p7 -- zen-sources-2.6.32_p7-r1 -- zen-sources-2.6.33_p1 -- zen-sources-2.6.33_p2 -- zen-sources-2.6.33_p2-r1 -- zen-sources-2.6.33_p3 -- zen-sources-2.6.34_p1 -- zen-sources-2.6.34_p1-r2 -- zen-sources-2.6.35_p2 (*) In my view, mm-sources is a candidate for last-rites as it is of extremely limited public interest at this point in time.
CVE-2010-3301 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3301): The IA32 system call emulation functionality in arch/x86/ia32/ia32entry.S in the Linux kernel before 2.6.36-rc4-git2 on the x86_64 platform does not zero extend the %eax register after the 32-bit entry path to ptrace is used, which allows local users to gain privileges by triggering an out-of-bounds access to the system call table using the %rax register. NOTE: this vulnerability exists because of a CVE-2007-4573 regression.
Cleaning up a little behind our faulty new bot. Kerin, thanks for the elaborate kernel listing.
Been running 34-r10 for a bit on amd64 now - seems stable. Not sure what the plans are - do we intend to stabilize this (or something else) or backport the patch?
Here's another report. This one shows which are keyworded stable of all the ebuilds that have been fixed so far (with vanilla-sources included): gentoo-sources-2.6.32-r18 : TESTING gentoo-sources-2.6.34-r10 : TESTING gentoo-sources-2.6.35-r8 : TESTING hardened-sources-2.6.32-r18 : STABLE (for x86/amd64) [1] hardened-sources-2.6.34-r6 : TESTING [2] tuxonice-sources-2.6.35-r3 : TESTING openvz-sources-2.6.27.7.1 : TESTING openvz-sources-2.6.32.9.1 : TESTING vanilla-sources-2.6.32.22 : TESTING vanilla-sources-2.6.35.5 : TESTING The situation could be better. Putting hardenened-sources aside (and the ebuilds which remain vulnerable), I would encourage the maintainers of other releases to take a view as to whether they wish to target their newest releases for stabilisation and, if not, to bump and patch their existing stable instances. The latter is a trivial process as Mike has already made the patches available. I've also applied the latest "1700_retruncate-rax-after-ia32-syscall.patch" to a vanilla 2.6.27 tree without issue so apparently, even for the oldest affected release, no backporting work is required. I'd also like to point out that 2.6.32 is the current long-term stable branch [3]. Of all the upstream releases that exist, it is the epitome of stablility and that will remain the case for the forseeable future. Apart from the long-term stable branch, the only branch that can really be depended upon to receive fixes would be whatever is current (2.6.35 at present). Certainly, that has always been the pattern exhibited by upstream [4]. Looking at the versions of vanilla-sources that _are_ keyworded stable, it appears to make no sense. For instance, no 2.6.32.x version is marked stable whereas 2.6.34 is, albeit none of of the 2.6.34.x stable versions. I would assume that no arch testing is performed on vanilla releases and so, if any policy is going to be applied, I would suggest that all new 2.6.32.x releases are automatically keyworded stable. Then again, now that I've written that, it occurs to me that this concern ought to be raised elsewhere so I'll do that. [1] In general, only the x86/amd64 arches are keyworded stable for hardened-sources releases. [2] All 2.6.34 versions are ~arch keyworded so this is not an issue. [3] http://www.kroah.com/log/linux/stable-status-01-2010.html [4] Case in point, no official 2.6.34.x release carries the patch, whereas both 2.6.32 and 2.6.35 received new stable patches containing the CVE-2010-3301 fix at exactly the same time.
Stabilization of sys-kernel/gentoo-sources-2.6.34-r10 sys-kernel/vanilla-sources-2.6.34.7 is handled in bug 338855.
> Stabilization of > > sys-kernel/gentoo-sources-2.6.34-r10 > sys-kernel/vanilla-sources-2.6.34.7 2.6.34.7 is vulnerable! If anything, please stabilise 2.6.35.5. See bug 338739 also.
Are there any plans to resolve this issue? We're going on three weeks now with a local root exploit in stable, and a fix sitting in portage...
(In reply to comment #28) > Are there any plans to resolve this issue? We're going on three weeks now with > a local root exploit in stable, and a fix sitting in portage... > I'm sorry but I think this one is really sad for Gentoo. I am and have always been an avid defender of Gentoo, for I agree with the philosophy behind it, the practicality of the rolling release, the unrivaled flexibility of Portage, the consistent high quality work of the developers and maintainers, the second-to-none documentation, and I could go on. But when we have a local root exploit, with a known fix, that clings on for this long, it's just sad. The fix could have easily been backported to the stable kernels, and a new intermediary stable release could have been launched. I even went to the trouble of submitting the patch, made against stable hardened (not to mention stable gentoo-sources, which doesn't even have any of the mitigation measures provided by Grsecurity). As noted earlier, the fix was in Portage something like the next day after the CVE came out. So why then was it not backported, instead of waiting for stabilization of a new version (and eventually forcing a possibly premature fast-track)? Every major distribution had a fix for this very important problem within a couple of days; it tarnishes the otherwise magnificent security efforts undertaken by the Gentoo dev team that 3 weeks later the exploit is still there. Yes, there were mitigating security measures *on the hardened sources*, which broke the *publicly known* exploits. It is still hiding one's head in the sand to assume that just because the symbols are hidden, no one else might come up with a cleverer exploit. Just think back to the original flaw from 2+ years ago, and the exploit techniques that scanned the memory looking for function signatures, for example. Yes, Grsecurity provides an additional layer of defense in depth, *on hardened-sources*, but that's it: it's only a stop-gap measure, a best effort in case a vulnerability appears, to minimize the possibility for damage until the vulnerability gets fixed. Then there's the case of gentoo-sources, which has no Grsecurity and therefore no mitigation whatsoever. Surely the users of the normal kernel (including myself on my home PC, for example) aren't mistaken for expecting that the high standard of quality, stability and security provided by Gentoo will still apply to them...
We do appear to have fallen at the last post. It is indeed the case that hardened-sources (or, indeed, any other stable instance of a kernel release) could have been bumped with the sole addition of the patch in question and fast-tracked to stable. Versions of gentoo-sources that contain the fix remain ~arch keyworded. Not having conducted a second review I would, notwithstanding, assume that the situation remains largely unchanged with other ebuilds in the sys-kernel family. Furthermore, while this bug has received considerably more attention in the Gentoo scene, let us not lose sight of bug 337659 "IA32 Emulation Stack Underflow (CVE-2010-3081)", which has similar implications. While this is largely subjective, I would say that: * amd64 is a very popular arch * most users employ multilib and would not think of disabling IA32 emulation * the majority of the userbase has limited appreciation and/or awareness of kernel related security issues and, by extension, a naive approach to kernel maintenance in general The solution is at hand, the work has largely been done, but the critical process of propagating that work so that the entirety of the userbase will benefit appears to have derailed. It is not as though there is even an easy means of dissimenating this information. What are we collectively doing to raise awareness of this issue in the interim? I don't see anything at gentoo.org and, while I may have missed a post, a quick search of the planet.gentoo.org archives didn't yield anything. The GLSA process does not apply to kernel bugs and, even if it did, I don't think it would help (I can forsee this bug staying open for a long time). On my part, I've done what I can - produced the above report; updated the topic of the -server channel, posted on the associated mailing list with instructions on hot-patching [1], jumped up and down and waved my arms a little etc. What then is the plan to see through these bugs to eventual closure? I, for one, think that the maintainers of all affected ebuilds should be encouraged to apply the necessary fixes through to stable - even those that define K_SECURITY_UNSUPPORTED. I think it would be the responsible thing to do as there would be so much benefit for comparitively little effort. Encouragement is one thing but, as the old saying aptly goes, you can lead a horse to water but you can't make it drink. [1] In case any casual reader is interested in these instructions, they are here but they do not encompass CVE-2010-3081: http://archives.gentoo.org/gentoo-server/msg_4d22ff74ae0655c79f0442f6436b86f7.xml
Wow. I really didn't believe it when I read Gentoo took 3 weeks to patch this. So glad I jumped ship to a distribution that actually gives a shit about the security of its users' machines. What a joke. :/
(In reply to comment #31) This is a bug tracker, not a discussion forum. Kindly refrain from posting any comments that do not pertain to the resolution of this issue.
