[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 10 Apr 2024 17:54:00 -0500
From: Jonathan Wright <jonathan@...alinux.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-1086: Linux: nf_tables: use-after-free
vulnerability in the nft_verdict_init() function
For what it's worth for RHEL 8/9 derivatives, the kpatches on my blog have
been used over 1000 times with no reported issues.
On Wed, Apr 10, 2024, 17:52 Solar Designer <solar@...nwall.com> wrote:
> 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.
