[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE-2021-20177 kernel: iptables string match rule could result in kernel panic
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2021-01-12 16:02:51
Message-ID: 192EDE83-5DF6-40A9-8928-1CD1739177A0 () dwheeler ! com
[Download RAW message or body]


> > 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? ...
> 
> On Jan 12, 2021, at 10:23 AM, John Haxby <john.haxby@oracle.com> wrote:
> 
> 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.

I suspect in many cases there's a simple answer: who takes the *blame* when something \
goes wrong?

If someone updates a component when "they don't have to", and it causes a problem, \
that person takes the fall: gets demoted, fired, whatever. If a component is not \
updated, and the system is attacked, the *attacker** is blamed & the admins don't get \
demoted, fired, whatever. So updates are rare & involve >1 year testing to ensure \
that the blame is fully distributed away from any one person.

Some organizations make an explicit exception: if there's a CVE, then you *are* \
"required" to update the component by policy. Then those who updated the component \
are no longer at serious career risk, because when someone tries to blame the person \
who did the update, they can say "I was required to update by policy".

In short, I think it's all about incentives.

--- David A. Wheeler


[prev in list] [next in list] [prev in thread] [next in thread]