[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230113173016.GA23279@openwall.com>
Date: Fri, 13 Jan 2023 18:30:16 +0100
From: Solar Designer <solar@...nwall.com>
To: Davide Ornaghi <d.ornaghi97@...il.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-0179: Linux kernel stack buffer overflow in nftables: PoC and writeup
Hi all,
Just sharing a little detail on handling of this issue:
On Fri, Jan 13, 2023 at 04:22:47PM +0100, Davide Ornaghi wrote:
> While auditing the Linux kernel (6.2.0-rc1, commit
> 1b929c02afd37871d5afb9d498426f83432e71c2), I found a buffer overflow
> vulnerability within the Netfilter subsystem which has been assigned
> CVE-2023-0179.
> CVE-2023-0179 is exploitable starting from commit f6ae9f1 up to commit
> 696e1a48b1a1.
> The exploitation could allow the leakage of both stack and heap addresses
> and, potentially, a Local Privilege Escalation to the root user via
> arbitrary code execution.
Davide brought this to linux-distros early on Jan 11, Red Hat assigned
the CVE ID on the same day, and Greg KH helped bring this to attention
of Netfilter maintainers - all of which is appreciated!
Also the same day, Davide posted this publicly to Linux kernel mailing
lists and syzkaller, but the message only(?) got through to syzkaller:
https://groups.google.com/g/syzkaller/c/YRNDJBsJn_s?pli=1
and a Netfilter maintainer posted the patch to netfilter-devel:
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230111212251.193032-4-pablo@netfilter.org/
Both messages contained the CVE ID, making it obvious that this is a
security issue.
Davide - this is absolutely not your fault. It's just that
linux-distros and Linux kernel team's preferences and thus policies and
instructions differ and are not always compatible, which was indeed
difficult from your side to make sense of.
After that point, Greg KH nevertheless insisted on not posting this to
oss-security until the fix is merged - and today's merging of it into
linux-next was not enough to make him happy. (I wonder how much longer
we were supposed to sit on this issue.)
We did add an exception for Linux kernel issues last year:
https://www.openwall.com/lists/oss-security/2022/05/24/1
However, it only applies "if the publicly accessible fix doesn't look
like it's for a security issue", which wasn't the case this time.
Regardless, this disclosure made Greg KH really unhappy - as if we
violated some prior agreement, which wasn't the case. It may well be
the last straw that will result in Linux kernel documentation getting
updated so that reporters would not be instructed to contact
linux-distros anymore (or would even be instructed not to?) On one
hand, this is bad. On the other, everyone is tired of the
inconsistencies and the drama.
Brainstorming on possible alternatives, I suppose we (oss-security
community?) could want to setup a crawler detecting likely security
issues on Linux kernel mailing lists and among Linux kernel commits
(including branches). This could detect even more issues than are being
brought to linux-distros and oss-security now. Unfortunately, we would
have less information on those issues (not the full original reports),
but I suppose them starting to appear on oss-security would sometimes
encourage the reporters to follow-up with the additional detail?
Apparently, grsecurity is successfully doing something similar, and
quite possibly bad actors are doing it too - so us doing it would help
level the playing field. A public effort like this would possibly
result in mailing list postings and commit messages becoming more
obscure or even specifically tailored to avoid our detection if we make
our keyword lists, etc. public (a reason not to, since the bad actors
would not?)
This situation where two well-meaning communities with a common end goal
could end up treating each other as adversaries is indeed ridiculous.
I welcome better ideas, if anyone has any.
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.
