Re: Kernel update status

[Sylvain Beucler <beuc@debian.org>]

Hi,

On Fri, Sep 17, 2010 at 10:42:30PM +0100, Athanasius wrote:
> On Fri, Sep 17, 2010 at 11:31:09PM +0200, Sylvain Beucler wrote:
> > On Fri, Sep 17, 2010 at 11:08:39PM +0200, Norbert Tretkowski wrote:
> > > Am Freitag, den 17.09.2010, 22:37 +0200 schrieb Sylvain Beucler:
> > > > The 2.6.32 kernel in bpo is affected by CVE-2010-3301:
> > > > http://sota.gen.nz/compat2/
> > > > (with escalation to root privs)
> > > > 
> > > > I suppose that people are working on fixing this, for squeeze and then
> > > > for bpo - is there a status / ETA?
> > > 
> > > The package for lenny-backports gets updated as soon as there is an
> > > update for unstable available.
> > 
> > Thanks.  I'm interested in an estimation of the time this will take,
> > which will help me decide whether I should just work-around the
> > problem (shutdown / disable 32-bit...) until the update, or if I
> > should patch it myself, or look for some unofficial update.
> 
>   Note that in my own testing of the 'robert_you_suck.c' exploit I found
> that disabling 32bit binaries IS NOT A VALID WORKAROUND.  The binfmt
> magic did indeed stop 32bit binaries from running (just echo'ing their
> name instead), but I could still run the robert_you_suck exploit and
> get UID 0.
>   I didn't check the ABftw.c exploit in this manner.

Yeah, I installed binfmt-support and followed the instructions, but
somehow I could still run 32bit chroot'd binaries and run the exploit.

>   I can, however, confirm that the following 3 cherry picked git commits
> seem to prevent both exploits from working:
> 
> c41d68a513c71e35a14f66d71782d27a79a81ea6
> 36d001c70d8a0144ac1d038f6876c484849a74de
> eefdca043e8391dcd719711716492063030b55ac
> 
> apply in that order.  If I was more familiar with git I could give you
> git cherry-pick commands to pull them in, but I'm not, so ....
>   Oh, one caveat.  If you grab a diff patch of those commits the first
> will fail against 2.6.35.4 due to the arch/tile/ bits not being present.
> I assume the whole arch (or at least the affected file) was added in
> 2.6.36.git and ignored that hunk failure.

Thanks.

I see that -23 entered unstable now, so the backports shouldn't be far
away :)

-- 
Sylvain