# How to deal with gentoo's poor kernel security?

## tholin

The linux kernel (and userspace) is a quagmire of security vulnerabilities. Just using the most recent stable kernel isn't enough because it can take a month before security fixes are backported to the stable branch.

As an example CVE-2016-8655 is a local root exploit that has been in the kernel for a bit over 5 years and was fixed in commit 84ac726023 Nov 30 2016. The fix will be in 4.9 when it's released but as of this writing it still hasn't been backported to stable. It's in the stable queue and will probably be in 4.4.38 whenever that is released.

http://seclists.org/oss-sec/2016/q4/607

Other distributions cherrypick security patches and backport them to their kernels but what about gentoo? The most recent stable gentoo-sources (not ~amd64) is 4.4.26. It contains a standard linux-4.4.tar.xz tree and a set of genpatches. The genpatches contains the stable patches up to 4.4.26 but I don't see any cherrypicked security fixes after that.

As far as I can see gentoo-sources-4.4.26 are vulnerable to CVE-2016-8655 and that's not all. Commit 1c109fabbd fixed an information leak in the upstream kernel. It was incorrectly backported to v4.4.22 in commit 9d25c78ec0 and introduced a "trivial root exploit" there. That was eventually fixed in 4.4.29. Since stable gentoo-sources use 4.4.26 it should also be vulnerable to that.

https://lwn.net/Articles/705220/#Comments

A less serious problem is the unprivileged kernel memory corrupting bug resulting in denial of service, fixed in commit 22f2ac51b6 on Sep 30 2016. It was eventually backported to stable in 4.4.28, 28 days after being fixed in upstream. But since stable gentoo-sources use 4.4.26 it's probably vulnerable to that also.

Is there anything I, as a user can do about this besides switching distribution or operating system? Compiling upstream git kernels daily is not a practically approach and neither is keeping up to date and patch every security vulnerability myself.

----------

## Ant P.

 *tholin wrote:*   

> Compiling upstream git kernels daily is not a practically approach and neither is keeping up to date and patch every security vulnerability myself.

 

If you're putting yourself in situations where you're a lucrative target for attacks like these, then too bad: you're going to have to start doing that.

But I suspect this is just a strawman you made up to justify blindly trusting "stable" labels. Use some common sense.

----------

## asturm

Why bother with patching when you can use ~arch sources that are usually in Gentoo from day 1. The Gentoo stable label really doesn't add much to kernel sources.

----------

## Hu

Regarding CVE-2016-8655, the commit you identified as fixing it is not marked as security sensitive in any way that would make it easy to spot using text searches.  It makes no mention of obvious words such as exploit, privilege, escalation, CVE, or even root (which would need a lot of manual review due to its non-exploit uses).  It does not include a Cc: stable@kernel.org note.  It does mention use-after-free, but as a non-kernel-developer reading only the commit message, it is not obvious to me that the use-after-free can be used to do anything beyond crash the kernel.  The Gentoo kernel security situation might be better if it was more practical for the Gentoo maintainers to find the important patches.  As is, they either wait for the kernel.org stable kernel or they repeat a lot of the work that goes into identifying patches for those.

As asturm suggests, you could probably get a shorter turnaround by tracking the kernel.org "stable" series instead of using the Gentoo kernels, though that comes with the cost of not having anyone from the Gentoo project do even basic smoke tests on the kernel before you use it.

----------

## Tony0945

 *Hu wrote:*   

> As asturm suggests, you could probably get a shorter turnaround by tracking the kernel.org "stable" series instead of using the Gentoo kernels, though that comes with the cost of not having anyone from the Gentoo project do even basic smoke tests on the kernel before you use it.

 

That's basically what the ~arch kernels are, gentoo-patches applied to kernels that kernel.org has declared stable. I always keep the latest Gentoo stable kernel as a fallback but added gentoo-sources to accept_keywords on an otherwise stable system. I considered changing to full ~amd but that would require compiling about 900 packages.

----------

## tholin

 *asturm wrote:*   

> Why bother with patching when you can use ~arch sources that are usually in Gentoo from day 1. The Gentoo stable label really doesn't add much to kernel sources.

 

I already get new kernels from kernel.org as soon as they are available. That way I don't have to wait a day for portage snapshots to update. The reason I used the stable gentoo-sources as an example was because it's the kernel most people use so if any ebuild get cherrypicked fixes it should be that one.

Even if I use upstream stable it could still take a month for the stable maintainers to backport security fixes. I've seen people claim this is not such a big problem because people use distribution kernels with backported fixes anyway but that doesn't seem to be true for all distros.

https://www.phoronix.com/forums/forum/software/general-linux-open-source/916195-new-kernel-vulnerability-allows-local-root-for-unprivileged-processes?p=916205#post916205

A glimmer of hope popped up on planet gentoo. Seems like stable gentoo-sources is getting backported fix for CVE-2016-8655 at least. 

http://www.mpagano.com/blog/?p=263

 *Hu wrote:*   

> Regarding CVE-2016-8655, the commit you identified as fixing it is not marked as security sensitive in any way that would make it easy to spot using text searches.  It makes no mention of obvious words such as exploit, privilege, escalation, CVE, or even root (which would need a lot of manual review due to its non-exploit uses).  It does not include a Cc: stable@kernel.org note.  It does mention use-after-free, but as a non-kernel-developer reading only the commit message, it is not obvious to me that the use-after-free can be used to do anything beyond crash the kernel.

 

The reason I found out about it was by reading hacker news. Not the most reliable source for vulnerability disclosure. Kernel developers have a habit of intentionally neglecting to mention security implications in commit messages and I don't know what distributions can do about that. Perhaps the security teams of different distributions can work together to piece together which patches are candidates for hasty backports?

https://lwn.net/Articles/704231/

----------

## ct85711

The thing you need to remember, is that gentoo's stable does not follow upstream.  If you pay attention to upstream on when they release patches, they always apply it to the current versions, then if someone has the time and it's not too big of a change it will get ported down to older versions.  This does not mean, porting to other versions is an easy process, as the devs need to make sure the patch doesn't screw something else up on each version they port to.  Lastly, keep in mind that no one is being paid to do this stuff over here.  So there is nothing forcing the devs to even look at the older versions if they don't want to.

----------

## khayyam

 *ct85711 wrote:*   

> [...] keep in mind that no one is being paid to do this stuff over here.  So there is nothing forcing the devs to even look at the older versions if they don't want to.

 

ct85711 ... in which case the label on the box should be revised: "Welcome to gentoo, an overextended, source-based Linux distribution that becomes just about any system you need [if that need happens to correspond with the needs of developers] -- and much less". Also, "get involved" should be provided the proviso: "your contributions will be valued less than ours", and the charter: "for whatever we want, by us who do all the actual work". ;)

best ... khay

----------

## asturm

 *tholin wrote:*   

> I already get new kernels from kernel.org as soon as they are available. That way I don't have to wait a day for portage snapshots to update.

 

Waiting a day (usually it's much less than that) is perfectly fine imo. If that's not fast enough, you also won't care about any stabilisation process whatsoever.

 *tholin wrote:*   

> The reason I used the stable gentoo-sources as an example was because it's the kernel most people use so if any ebuild get cherrypicked fixes it should be that one.

 

Even when fixes are backported, there is no way for Gentoo to enforce the kernel being in use. Remember, installing and configuring the kernel image for your next boot is entirely your own responsibility. And there is no way for Gentoo to provide more testing than what is done @upstream already, so whatever breakage there may be, there's a big chance it is known already, and if not, you may be using rare hardware that may as well be broken on any 'stable' sources. Take my laptop, e.g., where I could not use any kernel version between 3.7 and 4.0 because a timing bug left me with a blank screen 3 out of 4 times, and is now broken again (in another way) with anything >4.7. In my opinion, just because I'm facing that bug with my docking station, it makes no sense to block stabilisation for everyone else. So when it comes to the kernel, to me it has always been an exception package (or even no package) handling regardless of whatever Gentoo keywords it had.

The only way a backport makes sense to me is when there is no fixed upstream version around. And that, usually, also happens swiftly when necessary.

 *khayyam wrote:*   

> ct85711 ... in which case the label on the box should be revised: "Welcome to gentoo, an overextended, source-based Linux distribution that becomes just about any system you need [if that need happens to correspond with the needs of developers] -- and much less". Also, "get involved" should be provided the proviso: "your contributions will be valued less than ours", and the charter: "for whatever we want, by us who do all the actual work". 

 

Actions > Words

----------

## khayyam

 *asturm wrote:*   

>  *khayyam wrote:*   ct85711 ... in which case the label on the box should be revised: "Welcome to gentoo, an overextended, source-based Linux distribution that becomes just about any system you need [if that need happens to correspond with the needs of developers] -- and much less". Also, "get involved" should be provided the proviso: "your contributions will be valued less than ours", and the charter: "for whatever we want, by us who do all the actual work". ;) 
> 
> Actions > Words

 

astrum ... the use of language is an activity, if you can achieve the later without the former, then you might have a point. Such a rejoinder is nothing but a way to dismiss criticism ... being a "non-acting" (boo!!!!) member of the community I haven't earned the right to say anything ... which, ironically, confirms the criticism I was making, so thanks for that, but no thanks for all the work I have provided the community (such as forum posts, bug reports, ebuilds, irc support, etc, etc) ... I really am a useless burden, sucking the life out of the community, yadda-yadda, words, words, words, and I bow to your superior action.

best ... khay

----------

## 1clue

@tholin,

You seem to be knowledgeable in terms of kernel patches, CVEs and the inevitable process of applying patches downstream, but you appear not to get the time frame involved with any CVE. I see that a lot, so forgive me if I'm making an incorrect assumption.

Bugs:

Exist as soon as the code is written.

Are found by white hats (the good guys)

Are found by the black hats (the bad guys)

Are added to the CVE database

Are added to the software vendor bug database

Get verified by a developer

Get fixed by a developer

Get tested by "testers"

A patch is released

The patch is pushed to the public by the software vendor

The CVE is updated with patch information

Various downstream entities pull in the patches based on perceived importance

At some point, the consumer updates the software on their individual system(s)

The thing is, items 2-8 may not be in the above order. The black hats might get news of the bug first and create exploits before any white hat knows of a problem.

Moreover, the list above is a human-driven list. Each step involves human interaction to some degree.

My point is this: Getting your patch moments after its release does not save you from vulnerability. A black hat who reads about the CVE and develops an exploit probably needs more than a day to do it, and the chances of them hitting your site first is pretty slim.

It's my understanding that the CVE database has a public version and a private version. It's my understanding that, especially with serious issues, the maintainers of the database will attempt to notify the maintainers of the code in question so they have a chance to make a patch before the bug becomes public. I don't know this to be true, but if I were maintaining the list I would certainly make an effort to make it true.

----------

