[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240410225113.GA21187@openwall.com>
Date: Thu, 11 Apr 2024 00:51:13 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2024-1086: Linux: nf_tables: use-after-free vulnerability in the nft_verdict_init() function
Hi,
Quoting the CVE description:
A use-after-free vulnerability in the Linux kernel's netfilter:
nf_tables component can be exploited to achieve local privilege
escalation. The nft_verdict_init() function allows positive values as
drop error within the hook verdict, and hence the nf_hook_slow()
function can cause a double free vulnerability when NF_DROP is issued
with a drop error which resembles NF_ACCEPT.
Introduced in February 2014:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0abdadcc6e1
Fixed in January 2024:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660
This is old news, but it's still relevant. Out of major distros,
notably RHEL 9.3 (and most rebuilds) is still not fixed, and Notselwyn's
exploit that just works all the way to a root shell was recently widely
publicized:
https://github.com/Notselwyn/CVE-2024-1086
There are known mitigations: blacklist the nf_tables kernel module if
unused, disallow access to user namespaces if containers are not used,
load Jonathan Wright's unofficial AlmaLinux kpatch (link below), or/and
load LKRG (kills the published exploit at its last stage, leaving the
system unstable).
https://jonathanspw.com/posts/2024-03-31-dealing-with-cve-2024-1086/
$ sha256sum AlmaLinux-9--5-14-0-362--CVE-2024-1086-Patch.ko
446a2f0a78f92a5530c45d443680171536888c4e6f6a3edaff95a412ca1aafbe AlmaLinux-9--5-14-0-362--CVE-2024-1086-Patch.ko
The above exploit's author Notselwyn also wrote an extensive blog post
on March 26:
https://pwning.tech/nftables/
Its title and abstract are:
"Flipping Pages: An analysis of a new Linux vulnerability in nf_tables
and hardened exploitation techniques
A tale about exploiting KernelCTF Mitigation, Debian, and Ubuntu
instances with a double-free in nf_tables in the Linux kernel, using
novel techniques like Dirty Pagedirectory. All without even having to
recompile the exploit for different kernel targets once."
I asked and was hoping Notselwyn would bring this to oss-security
directly, but since that's not happening I am posting this relatively
brief message now. I understand it'd be a lot of work to process the
whole blog post into a plain text message.
Another reason for me to post this is that a somewhat obscure public
GitHub repo link (0 forks, 0 stars) for a different reproducer (crashing
the kernel) for what turned out to be the same bug was brought to
linux-distros (and wrongly also to distros) on March 29 (asking for a
CVE assignment). By linux-distros policy we need to have the underlying
vulnerability, once it's public, brought up on oss-security.
As the reporter wouldn't communicate with linux-distros any further, we
ended up directly bringing this to s@k.o and found out the reporter did
also bring the issue to there. What happened next highlighted what may
be a gap in report handling by s@.... Due to the reproducer being on a
public GitHub repo, s@k.o merely redirected the reporter to take it to
the normal developer mailing lists. Which the reporter neglected to do.
When a "public" issue enters this state, it's apparently not tracked by
s@k.o anymore. So if it were not for linux-distros, I think the report
would just fall through the cracks and remain uninvestigated. Which
means if the bug were not already fixed, it'd remain unfixed until maybe
rediscovered. Via linux-distros, we pinged s@k.o further, and Greg got
the Netfilter maintainers involved, who determined it's the fixed bug
above. Luckily, this did not matter (the bug is already known and fixed
anyway), but for some other bug it could.
Incidentally, that reporter in question is the same person accused of
exploit plagiarism in the other Linux kernel oss-security posting today.
So you can find their reproducer by following links from there to their
other repo. I don't want to directly promote it here (no need given the
real exploit is so public, plus s@k.o previously expressed they dislike
publication of reproducers), but perhaps it's somewhat more visible now.
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.
