Linux Modules
 help / color / mirror / Atom feed
From: Vegard Nossum <vegard.nossum@oracle.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	linux-kernel@vger.kernel.org,
	Thadeu Lima de Souza Cascardo <cascardo@canonical.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Kees Cook <keescook@chromium.org>,
	linux-hardening@vger.kernel.org, linux-modules@vger.kernel.org,
	John Haxby <john.haxby@oracle.com>, Jann Horn <jannh@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>
Subject: Re: [PATCH v3] kmod: harden user namespaces with new kernel.ns_modules_allowed sysctl
Date: Wed, 1 Mar 2023 12:09:17 +0100	[thread overview]
Message-ID: <8b0cfd73-d22c-2000-d4c6-41cf75531cdf@oracle.com> (raw)
In-Reply-To: <20230112180045.GA18314@mail.hallyn.com>


On 1/12/23 19:00, Serge E. Hallyn wrote:
> On Thu, Jan 12, 2023 at 02:19:11PM +0100, Vegard Nossum wrote:
>> Creating a new user namespace grants you the ability to reach a lot of code
>> (including loading certain kernel modules) that would otherwise be out of
>> reach of an attacker. We can reduce the attack surface and block exploits
>> by ensuring that user namespaces cannot trigger module (auto-)loading.
>>
>> A cursory search of exploits found online yields the following
>> non-exhaustive list of vulnerabilities, and shows that the technique is
>> both old and still in use:
>>
>> - CVE-2016-8655
>> - CVE-2017-1000112
>> - CVE-2021-32606
>> - CVE-2022-2588
>> - CVE-2022-27666
>> - CVE-2022-34918
>> - CVE-2023-0179
> 
> I think it would be worth pointing out how many of the above would
> actually be aided by this patch.  The first two would not, but certainly
> at least the can module one counts.  So I support this at least in
> principle.  I'll take a closer look at the code hopefully tonight.

The intention was to list _only_ CVEs with exploits that would be
mitigated by this patch. Let me go through them one by one, just using
public exploits found with Google:

CVE-2016-8655: this uses AF_PACKET. I guess your objection is that
AF_PACKET is rarely built as a module and even then would most certainly
already be loaded as part of regular operations? I see at least one
distro kernel having used CONFIG_PACKET=m in the past, so I wouldn't
write this off completely. You need CAP_NET_RAW to create this socket
type AFAICT, which is why the exploit uses user/network namespaces.

CVE-2017-1000112: uses AF_INET. Agreed that this would certainly be
compiled in or already loaded, so we can drop this.

CVE-2021-32606: needs CONFIG_CAN_ISOTP=m/can-isotp.

CVE-2022-2588: needs CONFIG_NET_CLS_ROUTE4=m/cls_route.

CVE-2022-27666: needs CONFIG_INET6_ESP=m/esp6.

CVE-2022-34918: needs CONFIG_NF_TABLES=m/nf_tables at least.

CVE-2023-0179: needs CONFIG_NF_TABLES=m/nf_tables at least.

All the exploits seem to be using user namespaces, for CVE-2017-1000112
I think it needs it to set the MTU of a dummy interface. I'm happy to
drop this CVE from the list (I probably looked too fast when looking at
it), but I think the rest are legitimate. Added Andrey Konovalov to Cc
as he wrote the exploit I looked at and can maybe confirm (and in
general has more experience with exploits).

Thanks again for looking at this -- I will try to address Luis's
comments in this thread as well and send out a v4 when we agree on the
required changes.


Vegard

  reply	other threads:[~2023-03-01 11:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 13:19 [PATCH v3] kmod: harden user namespaces with new kernel.ns_modules_allowed sysctl Vegard Nossum
2023-01-12 18:00 ` Serge E. Hallyn
2023-03-01 11:09   ` Vegard Nossum [this message]
2023-03-01 12:37     ` Vegard Nossum
2023-01-12 18:45 ` Luis Chamberlain
2023-01-12 21:53   ` Vegard Nossum
2023-01-13 23:06     ` Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b0cfd73-d22c-2000-d4c6-41cf75531cdf@oracle.com \
    --to=vegard.nossum@oracle.com \
    --cc=andreyknvl@gmail.com \
    --cc=cascardo@canonical.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=john.haxby@oracle.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox