[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Jul 2022 18:05:08 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Hugues ANGUELKOV <hanguelkov@...dorisec.fr>
Subject: Re: Linux kernel: Netfilter heap buffer overflow in nft_set_elem_init
Proposed fix by the maintainer:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6
netdev thread leading to there starts here:
https://lists.openwall.net/netdev/2022/07/02/86
> ----- Forwarded message from Hugues ANGUELKOV <hanguelkov@...dorisec.fr> -----
> One of our collaborators at RandoriSec, Arthur Mongodin found a
> vulnerability within the netfilter subsystem during his internship.
> Successful exploitation of this bug leads to a Local Privilege
> Escalation (LPE) to the `root` user, as tested on Ubuntu server 22.04
> (Linux 5.15.0-39-generic).
> This vulnerability is a heap buffer overflow due to a weak check and has
> been introduced within the commit
> [fdb9c405e35bdc6e305b9b4e20ebc141ed14fc81](https://github.com/torvalds/linux/commit/fdb9c405e35bdc6e305b9b4e20ebc141ed14fc81),
> it affects the Linux kernel since the version 5.8 and is still present
> today.
The fix commit above says it Fixes an older commit from 2015
(7d7402642eaf), but the bug was likely only exposed later, by the 2020
commit referenced in RandoriSec's message above. Quoting from:
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20220702191029.238563-1-pablo@netfilter.org/
Insufficient validation of element datatype and length in
nft_setelem_parse_data(). At least commit 7d7402642eaf updates
maximum element data area up to 64 bytes when only 16 bytes
where supported at the time. Support for larger element size
came later in fdb9c405e35b though. Picking this older commit
as Fixes: tag to be safe than sorry.
> The vulnerable code path can be reached if the kernel is built with the
> configuration `CONFIG_NETFILTER`, `CONFIG_NF_TABLES` enabled.
> To exploit the vulnerability, an attacker may need to obtain an
> unprivileged user namespace to gain the capability `CAP_NET_ADMIN`
> (`CONFIG_USER_NS` and `CONFIG_NET_NS` enabled, and
> `kernel.unprivileged_userns_clone = 1`).
Another scenario is the attacker having (or gaining by other means)
"root" access inside a pre-existing container with CAP_NET_ADMIN. This
does not require unprivileged user namespaces as the container may have
been started by host root.
> we can
> suggest the August, 15th 2022 as a potential date for public disclosure.
FWIW, an embargo this long wouldn't have been accepted by linux-distros.
The latest this issue could be disclosed publicly is July 15th.
Alexander
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.
