* [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
@ 2021-05-06 17:12 Steve Sakoman
2021-05-07 6:02 ` Mikko Rapeli
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Steve Sakoman @ 2021-05-06 17:12 UTC (permalink / raw
To: openembedded-core
The preferred methods for CVE resolution are:
1. Version upgrades where possible
2. Patches where not possible
3. Database updates where version info is incorrect
4. Exclusion from checking where it is determined that the CVE
does not apply to our environment
In some cases none of these methods are possible. For example the
CVE may be decades old with no apparent resolution, and with broken
links that make further research impractical.
This patch creates a mechanism for users to remove this type of
CVE from the cve-check results via an optional include file.
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
| 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
--git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
new file mode 100644
index 0000000000..956b3a9a3c
--- /dev/null
+++ b/meta/conf/distro/include/cve-extra-exclusions.inc
@@ -0,0 +1,18 @@
+# This file contains a list of CVE's where resolution has proven to be impractical.
+# It contains all the information we are aware of about an issue and analysis about
+# why we believe it can't be fixed/handled. Additional information is welcome through
+# patches to the file.
+#
+# Include this file in your local.conf or distro.conf to exclude these CVE's
+# from the cve-check results
+
+# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
+# CVE is more than 20 years old with no resolution evident
+# broken links in CVE database references make resolution impractical
+CVE_CHECK_WHITELIST += "CVE-2000-0006"
+
+# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
+# CVE is more than 20 years old with no resolution evident
+# broken links in CVE database references make resolution impractical
+CVE_CHECK_WHITELIST += "CVE-2000-0803"
+
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-06 17:12 [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's Steve Sakoman
@ 2021-05-07 6:02 ` Mikko Rapeli
2021-05-07 6:40 ` Richard Purdie
2021-05-07 6:44 ` Konrad Weihmann
2021-05-09 18:17 ` Armin Kuster
` (2 subsequent siblings)
3 siblings, 2 replies; 11+ messages in thread
From: Mikko Rapeli @ 2021-05-07 6:02 UTC (permalink / raw
To: steve; +Cc: openembedded-core
Hi,
On Thu, May 06, 2021 at 07:12:32AM -1000, Steve Sakoman wrote:
> The preferred methods for CVE resolution are:
>
> 1. Version upgrades where possible
> 2. Patches where not possible
> 3. Database updates where version info is incorrect
> 4. Exclusion from checking where it is determined that the CVE
> does not apply to our environment
>
> In some cases none of these methods are possible. For example the
> CVE may be decades old with no apparent resolution, and with broken
> links that make further research impractical.
>
> This patch creates a mechanism for users to remove this type of
> CVE from the cve-check results via an optional include file.
>
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> ---
> .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
>
> diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> new file mode 100644
> index 0000000000..956b3a9a3c
> --- /dev/null
> +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> @@ -0,0 +1,18 @@
> +# This file contains a list of CVE's where resolution has proven to be impractical.
> +# It contains all the information we are aware of about an issue and analysis about
> +# why we believe it can't be fixed/handled. Additional information is welcome through
> +# patches to the file.
> +#
> +# Include this file in your local.conf or distro.conf to exclude these CVE's
> +# from the cve-check results
> +
> +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0006"
Could this be specific to a recipe?
It may be that CVE data changes and adds new CPEs and the same CVE could still
be valid for another recipe. I think the analysis also applies to a single
recipe.
Cheers,
-Mikko
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-07 6:02 ` Mikko Rapeli
@ 2021-05-07 6:40 ` Richard Purdie
2021-05-07 6:44 ` Konrad Weihmann
1 sibling, 0 replies; 11+ messages in thread
From: Richard Purdie @ 2021-05-07 6:40 UTC (permalink / raw
To: Mikko Rapeli, steve; +Cc: openembedded-core
On Fri, 2021-05-07 at 06:02 +0000, Mikko Rapeli wrote:
> Hi,
>
> On Thu, May 06, 2021 at 07:12:32AM -1000, Steve Sakoman wrote:
> > The preferred methods for CVE resolution are:
> >
> > 1. Version upgrades where possible
> > 2. Patches where not possible
> > 3. Database updates where version info is incorrect
> > 4. Exclusion from checking where it is determined that the CVE
> > does not apply to our environment
> >
> > In some cases none of these methods are possible. For example the
> > CVE may be decades old with no apparent resolution, and with broken
> > links that make further research impractical.
> >
> > This patch creates a mechanism for users to remove this type of
> > CVE from the cve-check results via an optional include file.
> >
> > Signed-off-by: Steve Sakoman <steve@sakoman.com>
> > ---
> > .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
> >
> > diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> > new file mode 100644
> > index 0000000000..956b3a9a3c
> > --- /dev/null
> > +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> > @@ -0,0 +1,18 @@
> > +# This file contains a list of CVE's where resolution has proven to be impractical.
> > +# It contains all the information we are aware of about an issue and analysis about
> > +# why we believe it can't be fixed/handled. Additional information is welcome through
> > +# patches to the file.
> > +#
> > +# Include this file in your local.conf or distro.conf to exclude these CVE's
> > +# from the cve-check results
> > +
> > +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> > +# CVE is more than 20 years old with no resolution evident
> > +# broken links in CVE database references make resolution impractical
> > +CVE_CHECK_WHITELIST += "CVE-2000-0006"
>
> Could this be specific to a recipe?
>
> It may be that CVE data changes and adds new CPEs and the same CVE could still
> be valid for another recipe. I think the analysis also applies to a single
> recipe.
I've been discussing this with Steve a bit. My concern and motivation for this is
that we have a set of CVEs which are proving hard to find any useful data about
and that we can do little to address, particularly the ones 10-20 years old. Having
those showing up on weekly reports when we can do little about them is painting the
situation a little unfairly. Whitelisting them in the recipes is also not entirely
appropriate though. This file is primarily intended to collect up a list of those
along with what information we do know.
For more recent entries with better data, I'd expect we either fix them or we can
handle on a per recipe basis. The entries in this file are likely to be the really
old ones which are very unlikely to change.
We've left the file as opt-in so users have to choose whether they want this data
but it gives us a way to document any investigation done and what the status is.
In answer to the specific question, we could likely use pn- overrides here I
guess but for the kinds of CVEs likely to be listed, I'm not sure it gains us much?
Cheers,
Richard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-07 6:02 ` Mikko Rapeli
2021-05-07 6:40 ` Richard Purdie
@ 2021-05-07 6:44 ` Konrad Weihmann
1 sibling, 0 replies; 11+ messages in thread
From: Konrad Weihmann @ 2021-05-07 6:44 UTC (permalink / raw
To: Mikko Rapeli, steve; +Cc: openembedded-core
On 07.05.21 08:02, Mikko Rapeli wrote:
> Hi,
>
> On Thu, May 06, 2021 at 07:12:32AM -1000, Steve Sakoman wrote:
>> The preferred methods for CVE resolution are:
>>
>> 1. Version upgrades where possible
>> 2. Patches where not possible
>> 3. Database updates where version info is incorrect
>> 4. Exclusion from checking where it is determined that the CVE
>> does not apply to our environment
>>
>> In some cases none of these methods are possible. For example the
>> CVE may be decades old with no apparent resolution, and with broken
>> links that make further research impractical.
>>
>> This patch creates a mechanism for users to remove this type of
>> CVE from the cve-check results via an optional include file.
>>
>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>> ---
>> .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>> create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
>>
>> diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
>> new file mode 100644
>> index 0000000000..956b3a9a3c
>> --- /dev/null
>> +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
>> @@ -0,0 +1,18 @@
>> +# This file contains a list of CVE's where resolution has proven to be impractical.
>> +# It contains all the information we are aware of about an issue and analysis about
>> +# why we believe it can't be fixed/handled. Additional information is welcome through
>> +# patches to the file.
>> +#
>> +# Include this file in your local.conf or distro.conf to exclude these CVE's
>> +# from the cve-check results
>> +
>> +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
>> +# CVE is more than 20 years old with no resolution evident
>> +# broken links in CVE database references make resolution impractical
>> +CVE_CHECK_WHITELIST += "CVE-2000-0006"
>
> Could this be specific to a recipe?
>
> It may be that CVE data changes and adds new CPEs and the same CVE could still
> be valid for another recipe. I think the analysis also applies to a single
> recipe.
My understanding of this file is, that it targets CVEs that will never
be fixed - so it just reduces the noise from a scan - the same settings
can still be applied to any kind of recipe.
But what I'd like to see is a proper documentation of this inc file so
it gets some visibility - or alternatively it's included by default.
or it might be even okay to include these settings into the
cvecheck.bbclass as an opt-out feature - simply any place but an
undocumented inc-file
>
> Cheers,
>
> -Mikko
>
>
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-06 17:12 [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's Steve Sakoman
2021-05-07 6:02 ` Mikko Rapeli
@ 2021-05-09 18:17 ` Armin Kuster
2021-05-09 18:56 ` Steve Sakoman
2021-05-09 21:47 ` Richard Purdie
2021-05-09 22:11 ` Richard Purdie
2021-05-09 22:20 ` Richard Purdie
3 siblings, 2 replies; 11+ messages in thread
From: Armin Kuster @ 2021-05-09 18:17 UTC (permalink / raw
To: Steve Sakoman, openembedded-core
On 5/6/21 10:12 AM, Steve Sakoman wrote:
> The preferred methods for CVE resolution are:
>
> 1. Version upgrades where possible
> 2. Patches where not possible
> 3. Database updates where version info is incorrect
> 4. Exclusion from checking where it is determined that the CVE
> does not apply to our environment
I do see the desire of doing this as it is one file to maintain if there
are multiple packages being updated at once. This does highlight a few
things to me:
1) We have been dealing with this on a per-recipe basis. This is a shift
from that. ( Does this need to be documented)
2) Recipe Maintainers aren't engage in this area of activity as we had
original hoped. So we are working around that.
Reporting a false positive is better than masking an actual issue IMHO.
So what was the Policy used to decide on what can be put into this file?
Did I miss that conversion ? Is it documented anywhere?
- Armin
> In some cases none of these methods are possible. For example the
> CVE may be decades old with no apparent resolution, and with broken
> links that make further research impractical.
>
> This patch creates a mechanism for users to remove this type of
> CVE from the cve-check results via an optional include file.
>
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> ---
> .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
>
> diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> new file mode 100644
> index 0000000000..956b3a9a3c
> --- /dev/null
> +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> @@ -0,0 +1,18 @@
> +# This file contains a list of CVE's where resolution has proven to be impractical.
> +# It contains all the information we are aware of about an issue and analysis about
> +# why we believe it can't be fixed/handled. Additional information is welcome through
> +# patches to the file.
> +#
> +# Include this file in your local.conf or distro.conf to exclude these CVE's
> +# from the cve-check results
> +
> +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0006"
> +
> +# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0803"
> +
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-09 18:17 ` Armin Kuster
@ 2021-05-09 18:56 ` Steve Sakoman
2021-05-09 21:47 ` Richard Purdie
1 sibling, 0 replies; 11+ messages in thread
From: Steve Sakoman @ 2021-05-09 18:56 UTC (permalink / raw
To: akuster808; +Cc: Patches and discussions about the oe-core layer
On Sun, May 9, 2021 at 8:17 AM akuster808 <akuster808@gmail.com> wrote:
> On 5/6/21 10:12 AM, Steve Sakoman wrote:
> > The preferred methods for CVE resolution are:
> >
> > 1. Version upgrades where possible
> > 2. Patches where not possible
> > 3. Database updates where version info is incorrect
> > 4. Exclusion from checking where it is determined that the CVE
> > does not apply to our environment
> I do see the desire of doing this as it is one file to maintain if there
> are multiple packages being updated at once.
No, that isn't the intent of this at all! The above four methods are still
the desired method to deal with CVE's on a per recipe basis, even if
a CVE applies to multiple packages (quite rare).
> This does highlight a few
> things to me:
>
> 1) We have been dealing with this on a per-recipe basis. This is a shift
> from that. ( Does this need to be documented)
As I stated above, this is not the intent.
> 2) Recipe Maintainers aren't engage in this area of activity as we had
> original hoped. So we are working around that.
True, they haven't. But, no, working around lack of engagement is not the
intent! See my last two paragraphs in the original patch for my intent.
> Reporting a false positive is better than masking an actual issue IMHO.
I agree completely, and this is why this mechanism is optional.
> So what was the Policy used to decide on what can be put into this file?
> Did I miss that conversion ? Is it documented anywhere?
See the next two paragraphs from the original patch. If you have some
suggestions on how to better explain that this file is for ancient/intractable
CVE's I would be happy to update the wording so there is no confusion!
Same goes for the leading comment in the include file. Suggestions for
revisions to the wording are welcome!
> > In some cases none of these methods are possible. For example the
> > CVE may be decades old with no apparent resolution, and with broken
> > links that make further research impractical.
> >
> > This patch creates a mechanism for users to remove this type of
> > CVE from the cve-check results via an optional include file.
> >
> > Signed-off-by: Steve Sakoman <steve@sakoman.com>
> > ---
> > .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
> >
> > diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> > new file mode 100644
> > index 0000000000..956b3a9a3c
> > --- /dev/null
> > +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> > @@ -0,0 +1,18 @@
> > +# This file contains a list of CVE's where resolution has proven to be impractical.
> > +# It contains all the information we are aware of about an issue and analysis about
> > +# why we believe it can't be fixed/handled. Additional information is welcome through
> > +# patches to the file.
> > +#
> > +# Include this file in your local.conf or distro.conf to exclude these CVE's
> > +# from the cve-check results
> > +
> > +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> > +# CVE is more than 20 years old with no resolution evident
> > +# broken links in CVE database references make resolution impractical
> > +CVE_CHECK_WHITELIST += "CVE-2000-0006"
> > +
> > +# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
> > +# CVE is more than 20 years old with no resolution evident
> > +# broken links in CVE database references make resolution impractical
> > +CVE_CHECK_WHITELIST += "CVE-2000-0803"
> > +
> >
> >
> >
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-09 18:17 ` Armin Kuster
2021-05-09 18:56 ` Steve Sakoman
@ 2021-05-09 21:47 ` Richard Purdie
1 sibling, 0 replies; 11+ messages in thread
From: Richard Purdie @ 2021-05-09 21:47 UTC (permalink / raw
To: Armin Kuster, Steve Sakoman, openembedded-core
On Sun, 2021-05-09 at 11:17 -0700, Armin Kuster wrote:
>
> On 5/6/21 10:12 AM, Steve Sakoman wrote:
> > The preferred methods for CVE resolution are:
> >
> > 1. Version upgrades where possible
> > 2. Patches where not possible
> > 3. Database updates where version info is incorrect
> > 4. Exclusion from checking where it is determined that the CVE
> > does not apply to our environment
> I do see the desire of doing this as it is one file to maintain if there
> are multiple packages being updated at once. This does highlight a few
> things to me:
>
> 1) We have been dealing with this on a per-recipe basis. This is a shift
> from that. ( Does this need to be documented)
> 2) Recipe Maintainers aren't engage in this area of activity as we had
> original hoped. So we are working around that.
>
> Reporting a false positive is better than masking an actual issue IMHO.
Steve has covered most things in his reply but I want to add something on
this last bit.
Right now, multiple people have gone off and looked at some of these CVEs
and all the people I know who have done it concluded they're intractable,
there is nothing we can do about them.
I'd like to document this somewhere to save people doing the same work over
and over. If someone wants to investigate further and can propose actual
fixes, great, but it is helpful for them to have what we know so far to start
from.
This patch is effectively there to start a discussion if necessary. I do
strongly believe we need to do something here though as the false positives
*are* harmful. Currently, it looks like the project doesn't care about 60
odd CVEs in master. Anyone wanting to try and improve that has to guess
which ones have been investigated and which haven't.
Cheers,
Richard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-06 17:12 [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's Steve Sakoman
2021-05-07 6:02 ` Mikko Rapeli
2021-05-09 18:17 ` Armin Kuster
@ 2021-05-09 22:11 ` Richard Purdie
2021-05-09 22:20 ` Richard Purdie
3 siblings, 0 replies; 11+ messages in thread
From: Richard Purdie @ 2021-05-09 22:11 UTC (permalink / raw
To: Steve Sakoman, openembedded-core
On Thu, 2021-05-06 at 07:12 -1000, Steve Sakoman wrote:
> The preferred methods for CVE resolution are:
>
> 1. Version upgrades where possible
> 2. Patches where not possible
> 3. Database updates where version info is incorrect
> 4. Exclusion from checking where it is determined that the CVE
> does not apply to our environment
>
> In some cases none of these methods are possible. For example the
> CVE may be decades old with no apparent resolution, and with broken
> links that make further research impractical.
>
> This patch creates a mechanism for users to remove this type of
> CVE from the cve-check results via an optional include file.
>
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> ---
> .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
>
> diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> new file mode 100644
> index 0000000000..956b3a9a3c
> --- /dev/null
> +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> @@ -0,0 +1,18 @@
> +# This file contains a list of CVE's where resolution has proven to be impractical.
> +# It contains all the information we are aware of about an issue and analysis about
> +# why we believe it can't be fixed/handled. Additional information is welcome through
> +# patches to the file.
> +#
> +# Include this file in your local.conf or distro.conf to exclude these CVE's
> +# from the cve-check results
> +
> +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0006"
> +
> +# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0803"
I was thinking of adding a better description for this one and went digging. I
then found (I think?) that the above was fixed in:
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=07f95f1674217275ed4612f1dcaa95a88435c6a7
which would make it fixed in groff 1.17. We can probably submit a request
to update the CPE on that one...
I do think we're going to need this file and that having it might encourage
people to either document issues or as I maybe found here, get to the bottom
of one..
Cheers,
Richard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-06 17:12 [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's Steve Sakoman
` (2 preceding siblings ...)
2021-05-09 22:11 ` Richard Purdie
@ 2021-05-09 22:20 ` Richard Purdie
3 siblings, 0 replies; 11+ messages in thread
From: Richard Purdie @ 2021-05-09 22:20 UTC (permalink / raw
To: Steve Sakoman, openembedded-core
On Thu, 2021-05-06 at 07:12 -1000, Steve Sakoman wrote:
> The preferred methods for CVE resolution are:
>
> 1. Version upgrades where possible
> 2. Patches where not possible
> 3. Database updates where version info is incorrect
> 4. Exclusion from checking where it is determined that the CVE
> does not apply to our environment
>
> In some cases none of these methods are possible. For example the
> CVE may be decades old with no apparent resolution, and with broken
> links that make further research impractical.
>
> This patch creates a mechanism for users to remove this type of
> CVE from the cve-check results via an optional include file.
>
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> ---
> .../distro/include/cve-extra-exclusions.inc | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
>
> diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> new file mode 100644
> index 0000000000..956b3a9a3c
> --- /dev/null
> +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> @@ -0,0 +1,18 @@
> +# This file contains a list of CVE's where resolution has proven to be impractical.
> +# It contains all the information we are aware of about an issue and analysis about
> +# why we believe it can't be fixed/handled. Additional information is welcome through
> +# patches to the file.
> +#
> +# Include this file in your local.conf or distro.conf to exclude these CVE's
> +# from the cve-check results
> +
> +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0006"
> +
> +# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0803"
> +
One I propose we could add which I'd looked into previously:
# epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238
# The issue here is spoofing of domain names using characters from other character sets.
# There has been much discussion amongst the epiphany and webkit developers and
# whilst there are improvements about how domains are handled and displayed to the user
# there is unlikely ever to be a single fix to webkit or epiphany which addresses this
# problem. Whitelisted as there isn't any mitigation or fix or way to progress this further
# we can seem to take.
CVE_CHECK_WHITELIST += "CVE-2005-0238"
Cheers,
Richard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-17 9:16 Richard Purdie
@ 2021-05-17 10:10 ` Konrad Weihmann
2021-05-17 10:19 ` Richard Purdie
0 siblings, 1 reply; 11+ messages in thread
From: Konrad Weihmann @ 2021-05-17 10:10 UTC (permalink / raw
To: Richard Purdie, openembedded-core
On 17.05.21 11:16, Richard Purdie wrote:
> The preferred methods for CVE resolution are:
>
> 1. Version upgrades where possible
> 2. Patches where not possible
> 3. Database updates where version info is incorrect
> 4. Exclusion from checking where it is determined that the CVE
> does not apply to our environment
>
> In some cases none of these methods are possible. For example the
> CVE may be decades old with no apparent resolution, and with broken
> links that make further research impractical. Some CVEs are vauge
> with no specific action the project can take too.
>
> This patch creates a mechanism for users to remove this type of
> CVE from the cve-check results via an optional include file.
>
> Based on an initial patch from Steve Sakoman <steve@sakoman.com>
> but extended heavily by RP.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> .../distro/include/cve-extra-exclusions.inc | 91 +++++++++++++++++++
> 1 file changed, 91 insertions(+)
> create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
>
> diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> new file mode 100644
> index 00000000000..2d774f3706c
> --- /dev/null
> +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> @@ -0,0 +1,91 @@
> +# This file contains a list of CVE's where resolution has proven to be impractical
> +# or there is no reasonable action the Yocto Project can take to resovle the issue.
> +# It contains all the information we are aware of about an issue and analysis about
> +# why we believe it can't be fixed/handled. Additional information is welcome through
> +# patches to the file.
> +#
> +# Include this file in your local.conf or distro.conf to exclude these CVE's
> +# from the cve-check results or add to the bitbake command with:
> +# -R meta/conf/distro/include/cve-extra-exclusions.inc
> +#
> +# The file is not included by default since users should review this data to ensure
> +# it matches their expectations and ussage of the project.
> +#
> +# Wemay also include "in-flight" information about current/ongoing CVE work with
> +# the aim of sharing that work and ensuring we don't duplicate it.
> +#
> +
> +
> +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> +# CVE is more than 20 years old with no resolution evident
> +# broken links in CVE database references make resolution impractical
> +CVE_CHECK_WHITELIST += "CVE-2000-0006"
> +
> +# epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238
> +# The issue here is spoofing of domain names using characters from other character sets.
> +# There has been much discussion amongst the epiphany and webkit developers and
> +# whilst there are improvements about how domains are handled and displayed to the user
> +# there is unlikely ever to be a single fix to webkit or epiphany which addresses this
> +# problem. Whitelisted as there isn't any mitigation or fix or way to progress this further
> +# we can seem to take.
> +CVE_CHECK_WHITELIST += "CVE-2005-0238"
> +
> +# glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756
> +# Issue is memory exhaustion via glob() calls, e.g. from within an ftp server
> +# Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681
> +# Upstream don't see it as a security issue, ftp servers shouldn't be passing
> +# this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT or similar
> +CVE_CHECK_WHITELIST += "CVE-2010-4756"
> +
> +# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509
> +# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511
> +# The encoding/xml package in go can potentially be used for security exploits if not used correctly
> +# CVE applies to a netapp product as well as flagging a general issue. We don't ship anything
> +# exposing this interface in an exploitable way
> +CVE_CHECK_WHITELIST += "CVE-2020-29509 CVE-2020-29511"
> +
> +
> +
> +#### CPE update pending ####
> +
> +# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
> +# Appears it was fixed in https://git.savannah.gnu.org/cgit/groff.git/commit/?id=07f95f1674217275ed4612f1dcaa95a88435c6a7
> +# so from 1.17 onwards. Reported to the database for update by RP 2021/5/9. Update accepted 2021/5/10.
> +#CVE_CHECK_WHITELIST += "CVE-2000-0803"
> +
> +# grub:grub-efi:grub-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14865
> +# Looks like grub-set-bootflag is patched in by Fedora/RHEL:
> +# https://src.fedoraproject.org/rpms/grub2/blob/498ea7003b4dd8079fc075fad7e19e0b190d0f97/f/0133-Add-grub-set-bootflag-utility.patch
> +# Does not exist in upstream grub2:
> +# https://git.savannah.gnu.org/cgit/grub.git/tree/util
> +# Reported to the database for update by RP 2021/5/9 Update accepted 2021/5/12
> +#CVE_CHECK_WHITELIST += "CVE-2019-14865"
> +
> +# tar https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4476 *
> +# https://bugzilla.redhat.com/show_bug.cgi?id=280961 - issue affects paxutils included in tar
> +# http://cvs.savannah.gnu.org/viewvc/paxutils/paxutils/paxlib/names.c?r1=1.2&r2=1.4 was the fix
> +# included in tar 1.19 and later
> +# CPE update sent, may or may not exclude for us
> +#CVE_CHECK_WHITELIST += "CVE-2007-4476"
> +
> +
> +
> +#### Upstream still working on ####
> +
> +# qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255
> +# There was a proposed patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html
> +# however qemu maintainers are sure the patch is incorrect and should not be applied.
> +
> +# flex:flex-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-6293
> +# Upstream bug, still open: https://github.com/westes/flex/issues/414
> +# Causes memory exhaustion so potential DoS but no buffer overflow, low priority
> +
> +# wget https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879
> +# https://mail.gnu.org/archive/html/bug-wget/2021-02/msg00002.html
> +# No response upstream as of 2021/5/12
What is the use of that information? From my perspective an open
unresolved issue is an open unresolved issue - from a product
perspective it's not that important if upstream is working on it or not
- rather as the actual liable party I have to check myself, if my
product is affected in any way - and if not, whitelist it myself.
So how does this provide additional information, other than it's prone
to be outdated or prone to very frequent updates (which doesn't work
well, when doing only bumps from a point release to another)?
Still I like the idea of this file, but it should be documented better
(section in the manual?)
IMHO it would be better to use this file just for the CVEs which will
not be fixed anytime soon, but not for things beyond that scope
> +
> +# bind https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-25215
> +# Fix not in upstream release yet as of 2021/5/12
> +
> +
> +
>
>
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's
2021-05-17 10:10 ` [OE-core] " Konrad Weihmann
@ 2021-05-17 10:19 ` Richard Purdie
0 siblings, 0 replies; 11+ messages in thread
From: Richard Purdie @ 2021-05-17 10:19 UTC (permalink / raw
To: Konrad Weihmann, openembedded-core
On Mon, 2021-05-17 at 12:10 +0200, Konrad Weihmann wrote:
>
> On 17.05.21 11:16, Richard Purdie wrote:
> > The preferred methods for CVE resolution are:
> >
> > 1. Version upgrades where possible
> > 2. Patches where not possible
> > 3. Database updates where version info is incorrect
> > 4. Exclusion from checking where it is determined that the CVE
> > does not apply to our environment
> >
> > In some cases none of these methods are possible. For example the
> > CVE may be decades old with no apparent resolution, and with broken
> > links that make further research impractical. Some CVEs are vauge
> > with no specific action the project can take too.
> >
> > This patch creates a mechanism for users to remove this type of
> > CVE from the cve-check results via an optional include file.
> >
> > Based on an initial patch from Steve Sakoman <steve@sakoman.com>
> > but extended heavily by RP.
> >
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> > .../distro/include/cve-extra-exclusions.inc | 91 +++++++++++++++++++
> > 1 file changed, 91 insertions(+)
> > create mode 100644 meta/conf/distro/include/cve-extra-exclusions.inc
> >
> > diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc
> > new file mode 100644
> > index 00000000000..2d774f3706c
> > --- /dev/null
> > +++ b/meta/conf/distro/include/cve-extra-exclusions.inc
> > @@ -0,0 +1,91 @@
> > +# This file contains a list of CVE's where resolution has proven to be impractical
> > +# or there is no reasonable action the Yocto Project can take to resovle the issue.
> > +# It contains all the information we are aware of about an issue and analysis about
> > +# why we believe it can't be fixed/handled. Additional information is welcome through
> > +# patches to the file.
> > +#
> > +# Include this file in your local.conf or distro.conf to exclude these CVE's
> > +# from the cve-check results or add to the bitbake command with:
> > +# -R meta/conf/distro/include/cve-extra-exclusions.inc
> > +#
> > +# The file is not included by default since users should review this data to ensure
> > +# it matches their expectations and ussage of the project.
> > +#
> > +# Wemay also include "in-flight" information about current/ongoing CVE work with
> > +# the aim of sharing that work and ensuring we don't duplicate it.
> > +#
> > +
> > +
> > +# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
> > +# CVE is more than 20 years old with no resolution evident
> > +# broken links in CVE database references make resolution impractical
> > +CVE_CHECK_WHITELIST += "CVE-2000-0006"
> > +
> > +# epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238
> > +# The issue here is spoofing of domain names using characters from other character sets.
> > +# There has been much discussion amongst the epiphany and webkit developers and
> > +# whilst there are improvements about how domains are handled and displayed to the user
> > +# there is unlikely ever to be a single fix to webkit or epiphany which addresses this
> > +# problem. Whitelisted as there isn't any mitigation or fix or way to progress this further
> > +# we can seem to take.
> > +CVE_CHECK_WHITELIST += "CVE-2005-0238"
> > +
> > +# glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756
> > +# Issue is memory exhaustion via glob() calls, e.g. from within an ftp server
> > +# Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681
> > +# Upstream don't see it as a security issue, ftp servers shouldn't be passing
> > +# this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT or similar
> > +CVE_CHECK_WHITELIST += "CVE-2010-4756"
> > +
> > +# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509
> > +# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511
> > +# The encoding/xml package in go can potentially be used for security exploits if not used correctly
> > +# CVE applies to a netapp product as well as flagging a general issue. We don't ship anything
> > +# exposing this interface in an exploitable way
> > +CVE_CHECK_WHITELIST += "CVE-2020-29509 CVE-2020-29511"
> > +
> > +
> > +
> > +#### CPE update pending ####
> > +
> > +# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
> > +# Appears it was fixed in https://git.savannah.gnu.org/cgit/groff.git/commit/?id=07f95f1674217275ed4612f1dcaa95a88435c6a7
> > +# so from 1.17 onwards. Reported to the database for update by RP 2021/5/9. Update accepted 2021/5/10.
> > +#CVE_CHECK_WHITELIST += "CVE-2000-0803"
> > +
> > +# grub:grub-efi:grub-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14865
> > +# Looks like grub-set-bootflag is patched in by Fedora/RHEL:
> > +# https://src.fedoraproject.org/rpms/grub2/blob/498ea7003b4dd8079fc075fad7e19e0b190d0f97/f/0133-Add-grub-set-bootflag-utility.patch
> > +# Does not exist in upstream grub2:
> > +# https://git.savannah.gnu.org/cgit/grub.git/tree/util
> > +# Reported to the database for update by RP 2021/5/9 Update accepted 2021/5/12
> > +#CVE_CHECK_WHITELIST += "CVE-2019-14865"
> > +
> > +# tar https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4476 *
> > +# https://bugzilla.redhat.com/show_bug.cgi?id=280961 - issue affects paxutils included in tar
> > +# http://cvs.savannah.gnu.org/viewvc/paxutils/paxutils/paxlib/names.c?r1=1.2&r2=1.4 was the fix
> > +# included in tar 1.19 and later
> > +# CPE update sent, may or may not exclude for us
> > +#CVE_CHECK_WHITELIST += "CVE-2007-4476"
> > +
> > +
> > +
> > +#### Upstream still working on ####
> > +
> > +# qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255
> > +# There was a proposed patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html
> > +# however qemu maintainers are sure the patch is incorrect and should not be applied.
> > +
> > +# flex:flex-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-6293
> > +# Upstream bug, still open: https://github.com/westes/flex/issues/414
> > +# Causes memory exhaustion so potential DoS but no buffer overflow, low priority
> > +
> > +# wget https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879
> > +# https://mail.gnu.org/archive/html/bug-wget/2021-02/msg00002.html
> > +# No response upstream as of 2021/5/12
>
> What is the use of that information? From my perspective an open
> unresolved issue is an open unresolved issue - from a product
> perspective it's not that important if upstream is working on it or not
> - rather as the actual liable party I have to check myself, if my
> product is affected in any way - and if not, whitelist it myself.
>
> So how does this provide additional information, other than it's prone
> to be outdated or prone to very frequent updates (which doesn't work
> well, when doing only bumps from a point release to another)?
If you have a list of CVEs from the tool, each person seeing that list
currently has to go and look into each one of them. Even trying to find the
correct link to find the status of a given issue can in some cases be a real pain.
My hope is that if people can see the status of the issues, we might actually
get some help in trying to fix the "open" ones.
I'm therefore experimenting a bit with some way to "share" the known
state of the open issues. I appreciate the file isn't ideal but it
could perhaps be better than the current state of knowing "nothing" and
everyone working from scratch.
> Still I like the idea of this file, but it should be documented better
> (section in the manual?)
I agree, we do need to document it. I would love help with that.
> IMHO it would be better to use this file just for the CVEs which will
> not be fixed anytime soon, but not for things beyond that scope
It is better everyone look into open issues themselves and we don't share
any "state"?
I do understand the viewpoint and from a personal/company standpoint it is
fine but I don't think it helps people collaborate on trying to reduce the
list of open issues.
I am pretty sad/frustrated that these lists have been sent out in their current
form with many open CVEs for a long period and there are few who try and do
anything about them. It certainly doesn't make the project look good :(. I know
the reality is different with the majority being obsolete but the perception
is poor.
Cheers,
Richard
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-05-17 10:19 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-06 17:12 [OE-core] [PATCH] cve-extra-exclusions.inc: add exclusion list for intractable CVE's Steve Sakoman
2021-05-07 6:02 ` Mikko Rapeli
2021-05-07 6:40 ` Richard Purdie
2021-05-07 6:44 ` Konrad Weihmann
2021-05-09 18:17 ` Armin Kuster
2021-05-09 18:56 ` Steve Sakoman
2021-05-09 21:47 ` Richard Purdie
2021-05-09 22:11 ` Richard Purdie
2021-05-09 22:20 ` Richard Purdie
-- strict thread matches above, loose matches on Subject: below --
2021-05-17 9:16 Richard Purdie
2021-05-17 10:10 ` [OE-core] " Konrad Weihmann
2021-05-17 10:19 ` Richard Purdie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.