Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Oct 2011 21:35:47 +0200
From: Petr Matousek <pmatouse@...hat.com>
To: oss-security@...ts.openwall.com
Cc: kseifried@...hat.com
Subject: Re: CVE Request -- kernel: sysctl: restrict write
 access to dmesg_restrict

On Wed, Oct 26, 2011 at 07:53:10PM +0400, Vasiliy Kulikov wrote:
> Hi,
> 
> On Wed, Oct 26, 2011 at 09:26 -0600, Kurt Seifried wrote:
> > On 10/26/2011 09:16 AM, Petr Matousek wrote:
> > > When dmesg_restrict is set to 1 CAP_SYS_ADMIN is needed to read the
> > > kernel ring buffer. But a root user without CAP_SYS_ADMIN is able
> > > to reset dmesg_restrict to 0.
> > >
> > > This is an issue when e.g.  LXC (Linux Containers) are used and complete
> > > user space is running without CAP_SYS_ADMIN.  A unprivileged and jailed
> > > root user can bypass the dmesg_restrict protection.
> > >
> > > Introduced by:
> > > eaf06b241b091357e72b76863ba16e89610d31bd
> > >
> > > Fixed by:
> > > bfdc0b497faa82a0ba2f9dddcf109231dd519fcc
> > >
> > > Thanks,
> > Please use CVE-2011-4080 for this issue.
> 
> Why does it worth CVE?  Procfs is not ready for containers yet.  You can
> use other sysctls for more harmful things.  E.g. kernel.core_pattern
> allows arbitrary code execution as a full root - does it need a CVE too
> then? :-)

Yes, you are right. I was aware of the procfs limitations, still it looked
to me that boundary explicitly defined in eaf06b2 is directly crossed in
this case.

Anyway I agree that it is useless to issue CVE for each procfs flaw of
this kind.

Kurt, could you please reject the CVE?

Sorry for the noise,
Petr

> 
> root@...-ubuntu:/proc/sys/kernel# echo "|/usr/bin/touch /tmp/pwned" > core_pattern
> root@...-ubuntu:/proc/sys/kernel# cat 
> ^\Quit (core dumped)
> 
> (In the root namespace)
> $ ls /tmp/pwned
> /tmp/pwned
> 
> -- 
> Vasiliy Kulikov
> http://www.openwall.com - bringing security into open computing environments

-- 
Petr Matousek / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.