Richard Freeman | 26 Sep 2010 12:31
Picon
Favicon
Gravatar

Kernel Security Update Target Delay?

Gentoo has been vulnerable to a highly-publicized (Guardian, Slashdot,
the works) local privilege escalation for almost two weeks now.  (Well,
it has been vulnerable for years, but of course we didn't know about it
until two weeks ago.)

In the bugzilla thread tracking the problem it has been mentioned a few
times that the kernel does not receive GLSA support:
http://bugs.gentoo.org/show_bug.cgi?id=337645

Looking at the security webpage, it seems to me that while we don't
PUBLISH GLSAs for the kernel, the intent is to still fix problems (to do
otherwise would seem quite insane).

Looking at the normal GLSA process, this would rate as a A1 criticality
problem (local escalation in a system component), with a target
resolution of 3 days.  We're going on 10 days now on bug 337645 with no
mention of even targeting any particular release for stabilization.

Obviously the current bug will get done when it gets done, and it isn't
any skin off my back as I've upgraded (and in the likely event that
34-r10 gets called for stable I can keyword it without further testing).
 However, for the longer term it seems like something needs to change in
the process.  I don't see how kernel vulnerabilities can sit around for
days.  Most distros pushed out patches to stable users same-day or
within a day or two.

Perhaps a mitigating solution might be to open a security bug as soon as
Gentoo hears about a problem, and notify the package maintainers.  Then
the maintainers must either call for stabilization within 48 hours, or
publish a plan for how they will get the fix stabilized within the
(Continue reading)

Volker Armin Hemmann | 26 Sep 2010 13:51

Re: Kernel Security Update Target Delay?

On Sunday 26 September 2010, Richard Freeman wrote:
*gentoo-sources-2.6.32-r18 (21 Sep 2010)

  21 Sep 2010; Mike Pagano <mpagano <at> gentoo.org>
  +gentoo-sources-2.6.32-r18.ebuild:
  Linux patch 2.6.32.22. Includes fix for CVE-2010-3301.

*gentoo-sources-2.6.35-r8 (21 Sep 2010)

  21 Sep 2010; Mike Pagano <mpagano <at> gentoo.org>
  +gentoo-sources-2.6.35-r8.ebuild:
  Linux patch 2.6.35.5. Includes fix for CVE-2010-3301.

*gentoo-sources-2.6.35-r7 (16 Sep 2010)
*gentoo-sources-2.6.34-r10 (16 Sep 2010)

  16 Sep 2010; Mike Pagano <mpagano <at> gentoo.org>
  +gentoo-sources-2.6.34-r10.ebuild, +gentoo-sources-2.6.35-r7.ebuild:
  Fix for exploit: IA32 Syscall Entry Point Privilege Escalation
  (CVE-2010-3301)

date:
So 26. Sep 13:48:41 CEST 2010

so there has been roughly a week so far.

And the bug is not that dangerous - except when you insist on running unsecure 
32bit software on a 64bit system.

(Continue reading)

Richard Freeman | 26 Sep 2010 14:16
Picon
Favicon
Gravatar

Re: Kernel Security Update Target Delay?

On 09/26/2010 07:51 AM, Volker Armin Hemmann wrote:
> so there has been roughly a week so far.

Agreed - 10 days was the figure I mentioned.  So far we're 7 over the
target of 3.  Most major distros did it in less than 1.

> 
> And the bug is not that dangerous - except when you insist on running unsecure 
> 32bit software on a 64bit system.
> 

I didn't realize that multilib amd64 wasn't a security-supported
configuration of Gentoo.  Perhaps that should be documented somewhere -
like the amd64 handbook, and the multilib howto.  The security page
probably should also be updated - to indicate that amd64 is a supported
arch only without multilib.

Note that you don't need to RUN any 32-bit software to be insecure - you
merely need to have support for it enabled in the kernel config.

Look, either multilib is supported, or it isn't.  If it isn't, that's a
pretty big caveat that we don't document ANYWHERE.  If it is, then we
have to fix bugs in line with the security guidelines.

I'm just asking for us to be up-front with our policies, and to follow
them.  If we don't support multilib amd64, fine.  If we do support it,
then we need to support it.

Rich

(Continue reading)

Robin H. Johnson | 26 Sep 2010 18:56
Picon
Favicon
Gravatar

Re: Kernel Security Update Target Delay?

On Sun, Sep 26, 2010 at 08:16:22AM -0400, Richard Freeman wrote:
> On 09/26/2010 07:51 AM, Volker Armin Hemmann wrote:
> > so there has been roughly a week so far.
> Agreed - 10 days was the figure I mentioned.  So far we're 7 over the
> target of 3.  Most major distros did it in less than 1.
It WAS well within the 3 day target. The turnaround to the first fix was
just over 4 hours.

From the bug:
====
-- Comment #3 From Mike Pagano 2010-09-16 18:34:02 0000 [reply] -
Patches included in gentoo-sources versions: 2.6.32-r17, 2.6.34-r10 and
2.6.35-r7
====

Even hardened-kernel was fixed within 2 days of bug opening.

The delay is in stabilization, and I don't know why that's been held up.

--

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Richard Freeman | 26 Sep 2010 20:17
Picon
Favicon
Gravatar

Re: Kernel Security Update Target Delay?

On 09/26/2010 12:56 PM, Robin H. Johnson wrote:
> Even hardened-kernel was fixed within 2 days of bug opening.
> 
> The delay is in stabilization, and I don't know why that's been held up.
> 

Agreed, but if it isn't stable then it isn't fixed.

I can keyword stable at anytime on amd64 (well, assuming 34-r10 is the
one to go stable - for anything else I'd have to test it first) - just
waiting for the package maintainer to request stabilization...

Rich

Alex Legler | 27 Sep 2010 00:10
Picon
Favicon

Re: Kernel Security Update Target Delay?

Excerpts from Richard Freeman's message of Sun Sep 26 20:17:24 +0200 2010:
> On 09/26/2010 12:56 PM, Robin H. Johnson wrote:
> > Even hardened-kernel was fixed within 2 days of bug opening.
> > 
> > The delay is in stabilization, and I don't know why that's been held up.
> > 
> 
> Agreed, but if it isn't stable then it isn't fixed.

Bug 338855 was just filed, handling stabilization for g-s and v-s.
--

-- 
Alex Legler <a3li <at> gentoo.org>
Gentoo Security/Ruby
Calum | 26 Sep 2010 19:28
Picon

Re: Kernel Security Update Target Delay?

On 26 September 2010 11:31, Richard Freeman <rich0 <at> gentoo.org> wrote:
> Gentoo has been vulnerable to a highly-publicized (Guardian, Slashdot,
> the works) local privilege escalation for almost two weeks now.  (Well,
> it has been vulnerable for years, but of course we didn't know about it
> until two weeks ago.)
>
> In the bugzilla thread tracking the problem it has been mentioned a few
> times that the kernel does not receive GLSA support:
> http://bugs.gentoo.org/show_bug.cgi?id=337645

Kernels used to be covered in GLSAs.
I mourned the loss of kernel GLSAs quite a while back.
http://blog.gmane.org/gmane.linux.gentoo.security/month=20070401

Kernels used to be included, but apparently it was too much work
getting all the version kernel versions in sync.
I used to have script that emailed me applicable GLSAs, and I never
heard that they stopped including the kernel, so I was miffed when I
found out.

I still don't understand why there isn't a single security alert point
of reference that covers everything on a Gentoo box though.
What would it take to get kernels included again?

/meh.

PS. Hardened Gentoo still rocks though.

Alex Legler | 26 Sep 2010 23:42
Picon
Favicon

Re: Kernel Security Update Target Delay?

Excerpts from Calum's message of Sun Sep 26 19:28:01 +0200 2010:
> On 26 September 2010 11:31, Richard Freeman <rich0 <at> gentoo.org> wrote:
> > Gentoo has been vulnerable to a highly-publicized (Guardian, Slashdot,
> > the works) local privilege escalation for almost two weeks now.  (Well,
> > it has been vulnerable for years, but of course we didn't know about it
> > until two weeks ago.)
> >
> > In the bugzilla thread tracking the problem it has been mentioned a few
> > times that the kernel does not receive GLSA support:
> > http://bugs.gentoo.org/show_bug.cgi?id=337645
> 
> Kernels used to be covered in GLSAs.
> I mourned the loss of kernel GLSAs quite a while back.
> http://blog.gmane.org/gmane.linux.gentoo.security/month=20070401

I kindly request follow-up posters to not post +1's in this thread.

> […] 
> I still don't understand why there isn't a single security alert point
> of reference that covers everything on a Gentoo box though.
> What would it take to get kernels included again?

Kernel sources will not be included in the GLSA system again.
The whole process was designed for userland packages, not kernel
sources.

We hope to get the kernel-check [1] utility to serve this purpose one
day.

The invitation Kurt extended to contact us and help is still standing.
(Continue reading)


Gmane