Re: [OE-core] severe issue in CVE checker

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

I did not mean that yocto CVE checker is useless, or that bugs like
this should not be fixed. Using it is part of the best practice
processes for making secure products with yocto (even if it's currently
not documented as such).

But we should also document that the CVE checker makes a LOT of
assumptions which are frequently broken in real life. poky tries to work well
with CVE checker but many other layers and recipes may not work at all.

Few reasons are:

 * recipe name may not match to a CPE product name in the NVD database,
   and CVE_PRODUCT may not be set

 * recipe versions PV may not be compatible with upstream version
   numbers and hance the version range checks may fail

 * data in NVD is frequently wrong about the version ranges of CVEs

And there are more corner cases. All these fail silently.

Now you found a problem with the NVD download scripting which I think
needs to be fixed. But even if it works, developers who need to run
security checks on real products need to do more than just rely on
CVE check output.

Cheers,

-Mikko

On Wed, Oct 12, 2022 at 11:51:28AM +0200, Carlo Piana wrote:
> [sent from the wrong account, resent, sorry for the noise] 
> 
> ----- Messaggio originale ----- 
> > Da: "Mikko Rapeli" <mikko.rapeli@linaro.org> 
> > A: "Marta Rybczynska" <rybczynska@gmail.com> 
> > Cc: "Alexander Kanavin" <alex.kanavin@gmail.com>, "Alberto Pianon" <alberto@pianon.eu>, "OE-core" 
> > <openembedded-core@lists.openembedded.org>, "marta rybczynska" <marta.rybczynska@linaro.org>, "Richard Purdie" 
> > <richard.purdie@linuxfoundation.org>, "Carlo Piana" <carlo@piana.eu> 
> > Inviato: Mercoled�, 12 ottobre 2022 10:04:07 
> > Oggetto: Re: [OE-core] severe issue in CVE checker 
> 
> > Hi, 
> > 
> > Can the downloads be turned into normal do_fetch() SRC_URI downloads including 
> > caches in yocto infrastructure? 
> > 
> > There are many issues around CVE checking that it's really 
> > a process where a lot of details and uncertainties just need to be 
> > accepted. It's far from a perfect and users just need to accept this. 
> > 
> > 
> 
> [...] 
> 
> I beg to (strongly, if I may) differ. 
> 
> CVE is broken? This is no excuse of course to ignore a known insecurity. 
> 
> Is it better to include a process that, when fails, the fail goes unnoticed, than nothing? No, "nothing" is better than flawed here, speaking of security, since a false sense of security is worse than insecurity itself. 
> 
> If we put a CVE checker that just throws in a contradictory message (a warning and eventually a "success" one) and then silently moves on without any fuss, we leave users in a state of false belief that they have completed at least the CVE checks -- however insufficient this may be -- but in reality it's a test that never fails because the database is empty or outdated. I agree that for developers CVE checking, compliance, software component inventory are a PITA, but it's way more a PITA when an attacker exploits an unpatched known insecurity kept out in the wild, or when a copyright troll comes after you demanding (many!) millions in damages (I can't disclose who has received it, but I have seen it in real life), because you failed to notice that a GPL component went into a mass-distribution device. 
> 
> Once the function is advertised, the expected behaviour for a thing of that importance must be to visibly flag the issue and **stand in the way** until you acknowledge it, so that the warning cannot be missed. It is up to the duly informed user to say "Ok, it's nothing, I know it" and shrug the problem off. Not a decision taken for the user by others and hidden under the carpet. We have several clients relying on that CVE checking and just by coincidence we noticed that something did not add up. God only knows how many times did this happen before. 
> 
> One can think it's not their problem, this is open source after all. But being open source is not total relief from liability. If you create a hole in the road and cover it with foliage, the fact that you are not paid to pave the road and you are doing it as a service for the community does not shield you if a car takes a nose-dive into it. 
> 
> I am sorry to intrude in the discussion so bluntly, but I prefer that the legal implications are correctly perceived before making a decision. 
> 
> All the best, 
> 
> Carlo 
>