linux-hardening - Re: [PATCH v3] kmod: harden user namespaces with new kernel.ns_modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Mar 2023 12:09:17 +0100
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     "Serge E. Hallyn" <serge@...lyn.com>
Cc:     Luis Chamberlain <mcgrof@...nel.org>, linux-kernel@...r.kernel.org,
        Thadeu Lima de Souza Cascardo <cascardo@...onical.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Kees Cook <keescook@...omium.org>,
        linux-hardening@...r.kernel.org, linux-modules@...r.kernel.org,
        John Haxby <john.haxby@...cle.com>,
        Jann Horn <jannh@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>
Subject: Re: [PATCH v3] kmod: harden user namespaces with new
 kernel.ns_modules_allowed sysctl

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