[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Oct 2011 16:04:53 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com, cve-assign@...re.org
Subject: Re: CVE Request -- kernel: sysctl: restrict write
access to dmesg_restrict
Please revoke
CVE-2011-4080
On 10/27/2011 01:35 PM, Petr Matousek wrote:
> 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
--
-Kurt Seifried / 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.
