Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 15 Dec 2015 08:50:43 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: oss-security@...ts.openwall.com
Cc: guoyonggang@....cn, cve-assign@...re.org
Subject: Re: Re: CVE request - Android kernel - IPv6 connect
 cause a denial of service

Hi,

On 15.12.2015 04:48, Robert Święcki wrote:
>>> Use CVE-2015-8543 for the originally identified bug. We realize that,
>>> for example,
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/net/ipv4/af_inet.c
>>> has not yet been changed. If Linux kernel developers determine that
>>> multiple independent bugs result in situations where
>>> sk->sk_prot->get_port is NULL above, then it is possible that
>>> additional CVE IDs will be assigned later.
>>
>> The following patch fixes this issue:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=79462ad02e861803b3840cc782248c7359451cd9
>>
>> It is queued up for -stable.
>>
> 
> Not sure if it's important for you, but the description of this diff
> may not be exactly correct:
> 
> a) ... as root ..
> 
> If a given kernel supports CLONE_NEWUSER then everybody can create
> SOCK_RAW sockets. And CLONE_NEWUSER seems to be enabled with most
> modern Linux distros.

Yep, that is true. You can create a new user namespace and a new
net-namespace in which an ordinary user is allowed to use raw sockets.

> b). .. could simply crash the kernel ..
> 
> It'll cause GPF in the supervisor mode, and it seems that with most of
> supported CPU architectures under Linux, this will actually cause
> SIGSEGV to be sent to the user-land counterpart of the kernel thread
> which caused such GPF. So, it's not really crash of the kernel in most
> cases (may depend on sysctl and CPU architecture in use though).
> However, given that such GPF can happen when the socket struct seems
> to be locked, this could potentially cause some kernel dead-locks with
> subsequent accesses to sk (may result in unkillable processes and
> similar artifacts)

This is what I meant by simply crashing the kernel. :) In most kernel
crashes we hold some locks or are in a rcu critical section, which makes
the rest of kernel execution pretty much indeterministic.

Red Hat kernel always set panic_on_ooops because of this.

> Also, it could be potentially turned into a privilege escalation
> problem if there was a way to map the NULL page. Under x86/x86-64 I
> reviewed the code (install_special_mapping() and friends from mmap.c)
> and it seems to be correctly protected. But if anybody is using any
> alternative CPU architecture, I'd suggest looking at their
> arch-specific vdso/vvar mapping code. In case the address is
> controllable by user, this could likely allow for mapping of the NULL
> page and pwning the kernel.

Even on x86_64 a NULL address should be installable if you lower
/proc/sys/vm/mmap_min_addr as root before. Some software might need this.

Thanks for the following up. Unfortunately I can't edit the commit
anymore but it will be hopefully useful for the description of the CVE
entry.

Bye,
Hannes

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ