oss-sec mailing list archives

Re: CVE-2021-20177 kernel: iptables string match rule could result in kernel panic


From: Philip Pettersson <philip.pettersson () gmail com>
Date: Tue, 12 Jan 2021 08:40:41 -0800

On Tue, Jan 12, 2021 at 8:06 AM Sasha Levin <sashal () kernel org> wrote:

On Tue, Jan 12, 2021 at 03:23:16PM +0000, John Haxby wrote:
On 12 Jan 2021, at 08:04, Greg KH <greg () kroah com> wrote:

I still do not understand why you report issues that are fixed over a
year ago (October 2019) and assign them a CVE like this.  Who does this
help out?  And what about the thousands of other issues that are fixed
in the kernel and not assigned a CVE like this, are they somehow not as
important to your group?

What determines what you want to give a CVE to and what you do not?


I think I can answer that.   There's nothing technical going on here, it's down to the behaviour of the end users of 
enterprise systems.

A lot of those people have a hard time understanding that they do actually want bug fixes and an even harder time 
understanding that they need to actually do something to install those fixes.   (I was once asked if I could fix a 
problem without changing anything, anything at all when the fix was a one-off chmod.)   A CVE number gets attention: 
think of it as getting hold of the customer by the lapels and going nose-to-nose to explain in words of one syllable 
they if they don't update their systems that they will crash and they will get hacked.

Ooh, no, they say, we can't possibly take the risk of updating our systems.  Suppose something goes wrong?   Sheesh. 
 Suppose, instead, someone comes along and sees a known, fixed bug is unfixed and uses that to trash your systems.  
 Or that you've got a bug that crashes the machine once a week for which there's a fix.   But, no, apparently the 
mythical risk of a tested update vs the actual quantifiable risk of leaving the bug unfixed is so great that they'd 
rather take the real, quantifiable risk.   I suppose that's understandable, after a fashion, even though actual 
regressions are quite rare.

If you present a customer with a CVE number (with or without a score) then they have SLAs which will ensure that 
that fix gets applied.

The subject of this thread is a "vulnerability" that requires root to
exploit and was fixed ages ago.

I didn't take a look at this specific bug very closely, but on certain
distributions (Ubuntu etc) it has been possible to get CAP_NET_ADMIN
in your own network namespace for years. An unprivileged user can
become root with all capabilities in their own user/network namespace
and modify local iptables rules. On Redhat systems you still need
root.

Philip


Current thread: