| Message ID | 20240724152530.25856-5-marta.rybczynska@syslinbit.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | [v3,1/5] cve-check: annotate CVEs during analysis | expand |
On 24 Jul 2024, at 16:25, Marta Rybczynska via lists.openembedded.org <rybczynska=gmail.com@lists.openembedded.org> wrote: > > This file contains CVE_STATUS without machine-readable information on which > recipe it applies to. All entries should be verified and, if appropriate, > moved to their corresponding recipes. The point of this file was to be an opt-in for more exclusions where we didn’t feel 100% confident asserting the issues could be ignored. How much of a problem is it if this file contains a a limited number of CVEs? We can review what is in there and move/remove as needed to cut it down. Ross
On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <Ross.Burton@arm.com> wrote: > On 24 Jul 2024, at 16:25, Marta Rybczynska via lists.openembedded.org > <rybczynska=gmail.com@lists.openembedded.org> wrote: > > > > This file contains CVE_STATUS without machine-readable information on > which > > recipe it applies to. All entries should be verified and, if appropriate, > > moved to their corresponding recipes. > > The point of this file was to be an opt-in for more exclusions where we > didn’t feel 100% confident asserting the issues could be ignored. > > How much of a problem is it if this file contains a a limited number of > CVEs? We can review what is in there and move/remove as needed to cut it > down. > With the vex class (and with SPDX too, I think) they end up copied present in every single package of the build. This brings enormous confusion. Impossible to filter them out as there is no information about the affected recipe/package. Kind regards, Marta
On Fri, 2024-07-26 at 14:28 +0200, Marta Rybczynska via lists.openembedded.org wrote: > > > On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <Ross.Burton@arm.com> > wrote: > > On 24 Jul 2024, at 16:25, Marta Rybczynska via > > lists.openembedded.org > > <rybczynska=gmail.com@lists.openembedded.org> wrote: > > > > > > This file contains CVE_STATUS without machine-readable > > > information on which > > > recipe it applies to. All entries should be verified and, if > > > appropriate, > > > moved to their corresponding recipes. > > > > The point of this file was to be an opt-in for more exclusions > > where we didn’t feel 100% confident asserting the issues could be > > ignored. > > > > How much of a problem is it if this file contains a a limited > > number of CVEs? We can review what is in there and move/remove as > > needed to cut it down. > > With the vex class (and with SPDX too, I think) they end up copied > present in every single package of the build. This brings enormous > confusion. > Impossible to filter them out as there is no information about the > affected recipe/package. Difficult, yes, impossible, no. Surely we know which recipes a given CVE apply to? Cheers, Richard
On Thu, Aug 1, 2024 at 3:47 PM Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Fri, 2024-07-26 at 14:28 +0200, Marta Rybczynska via > lists.openembedded.org wrote: > > > > > > On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <Ross.Burton@arm.com> > > wrote: > > > On 24 Jul 2024, at 16:25, Marta Rybczynska via > > > lists.openembedded.org > > > <rybczynska=gmail.com@lists.openembedded.org> wrote: > > > > > > > > This file contains CVE_STATUS without machine-readable > > > > information on which > > > > recipe it applies to. All entries should be verified and, if > > > > appropriate, > > > > moved to their corresponding recipes. > > > > > > The point of this file was to be an opt-in for more exclusions > > > where we didn’t feel 100% confident asserting the issues could be > > > ignored. > > > > > > How much of a problem is it if this file contains a a limited > > > number of CVEs? We can review what is in there and move/remove as > > > needed to cut it down. > > > > With the vex class (and with SPDX too, I think) they end up copied > > present in every single package of the build. This brings enormous > > confusion. > > Impossible to filter them out as there is no information about the > > affected recipe/package. > > Difficult, yes, impossible, no. > > Surely we know which recipes a given CVE apply to? > > Without having the CVE data at the same time, no. Also, a CVE might apply to multiple recipes at the same time - and this could be dangerous. Imagine a situation where the CPE is incorrect and is pointing to the wrong package. It gets added to .inc. But then someone in their layer adds the package the CVE really applies to... If we keep the .inc file, I think the most correct way would be to add a field marking which recipe it should be applied to. What do you think? Regards, Marta
On Thu, 2024-08-01 at 15:58 +0200, Marta Rybczynska wrote: > On Thu, Aug 1, 2024 at 3:47 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Fri, 2024-07-26 at 14:28 +0200, Marta Rybczynska via > > lists.openembedded.org wrote: > > > On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <Ross.Burton@arm.com> > > > wrote: > > > > On 24 Jul 2024, at 16:25, Marta Rybczynska via > > > > lists.openembedded.org > > > > <rybczynska=gmail.com@lists.openembedded.org> wrote: > > > > > > > > > > This file contains CVE_STATUS without machine-readable > > > > > information on which > > > > > recipe it applies to. All entries should be verified and, if > > > > > appropriate, > > > > > moved to their corresponding recipes. > > > > > > > > The point of this file was to be an opt-in for more exclusions > > > > where we didn’t feel 100% confident asserting the issues could be > > > > ignored. > > > > > > > > How much of a problem is it if this file contains a a limited > > > > number of CVEs? We can review what is in there and move/remove as > > > > needed to cut it down. > > > > > > With the vex class (and with SPDX too, I think) they end up copied > > > present in every single package of the build. This brings enormous > > > confusion. > > > Impossible to filter them out as there is no information about the > > > affected recipe/package. > > > > Difficult, yes, impossible, no. > > > > Surely we know which recipes a given CVE apply to? > > Without having the CVE data at the same time, no. I thought we had the CVE data? > Also, a CVE might apply to multiple > recipes at the same time - and this could be dangerous. Imagine a situation where > the CPE is incorrect and is pointing to the wrong package. It gets added to .inc. > But then someone in their layer adds the package the CVE really applies to... We can't cover every possible scenario and if the data is wrong, we identify and fix it. > If we keep the .inc file, I think the most correct way would be to add a field marking > which recipe it should be applied to. > > What do you think? How do we mark up a CVE as applying to gcc-cross-*/gcc-cross-canadian- */gcc-runtime/libgcc and so on? How do we convert "bash" to "nativesdk-bash" and "bash-native"? There are ways we could do such markup but I don't think it is going to work well. I guess the key question is what we're trying to achieve and where we're expecting the data to be processed? Could we write a common exclusion file out once as part of the CVE fetch recipe and avoid putting it into the individual recipe output? Cheers, Richard
On Thu, Aug 1, 2024 at 4:08 PM Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Thu, 2024-08-01 at 15:58 +0200, Marta Rybczynska wrote: > > On Thu, Aug 1, 2024 at 3:47 PM Richard Purdie < > richard.purdie@linuxfoundation.org> wrote: > > > On Fri, 2024-07-26 at 14:28 +0200, Marta Rybczynska via > > > lists.openembedded.org wrote: > > > > On Fri, Jul 26, 2024 at 2:24 PM Ross Burton <Ross.Burton@arm.com> > > > > wrote: > > > > > On 24 Jul 2024, at 16:25, Marta Rybczynska via > > > > > lists.openembedded.org > > > > > <rybczynska=gmail.com@lists.openembedded.org> wrote: > > > > > > > > > > > > This file contains CVE_STATUS without machine-readable > > > > > > information on which > > > > > > recipe it applies to. All entries should be verified and, if > > > > > > appropriate, > > > > > > moved to their corresponding recipes. > > > > > > > > > > The point of this file was to be an opt-in for more exclusions > > > > > where we didn’t feel 100% confident asserting the issues could be > > > > > ignored. > > > > > > > > > > How much of a problem is it if this file contains a a limited > > > > > number of CVEs? We can review what is in there and move/remove as > > > > > needed to cut it down. > > > > > > > > With the vex class (and with SPDX too, I think) they end up copied > > > > present in every single package of the build. This brings enormous > > > > confusion. > > > > Impossible to filter them out as there is no information about the > > > > affected recipe/package. > > > > > > Difficult, yes, impossible, no. > > > > > > Surely we know which recipes a given CVE apply to? > > > > Without having the CVE data at the same time, no. > > I thought we had the CVE data? > When we do vex only, we have the CVE data only in the external tool. The file that comes out from the build contains additional entries. We can filter them out, but only in the tool. However, if we filter out in the tool (with a rule like: if this CVE does not apply to the package, remove it), we remove the feature of the VEX of being able to specify that your package is not affected by a widely known vulnerability. For example, you can say "I'm not affected by log4shell because I do not include log4j". This is a feature that has its use, it avoids responding to multiple procurement questions, where they all want the same information. You just say it once, in the VEX. > > > Also, a CVE might apply to multiple > > recipes at the same time - and this could be dangerous. Imagine a > situation where > > the CPE is incorrect and is pointing to the wrong package. It gets added > to .inc. > > But then someone in their layer adds the package the CVE really applies > to... > > We can't cover every possible scenario and if the data is wrong, we > identify and fix it. > I think we need to distinguish between two cases: - the data is wrong and we fix it (and we're sure of the fix) - typically a CPE fix - the resolution depends on a configuration, typically "not-applicable-config" - if someone adds a bbappend to the recipe, they MUST review impact on all related vulnerabilities - we make an assumption. All of "upstream-wontfix" are of this category. The YP user MUST make their own assessment here. > > > If we keep the .inc file, I think the most correct way would be to add a > field marking > > which recipe it should be applied to. > > > > What do you think? > > How do we mark up a CVE as applying to gcc-cross-*/gcc-cross-canadian- > */gcc-runtime/libgcc and so on? > We do not have any gcc entries in cve-extra-exclusions. > > How do we convert "bash" to "nativesdk-bash" and "bash-native"? > We do not have anything related to bash either. What is in there in cve-extra-exclusions are mostly very old CVEs, the biggest part belonging to bdb. Kernel ones can go to kernel includes etc. With the directions the CVE programme is going, I do not *expect* a need for new entries. > > There are ways we could do such markup but I don't think it is going to > work well. > > I guess the key question is what we're trying to achieve and where > we're expecting the data to be processed? > > Could we write a common exclusion file out once as part of the CVE > fetch recipe and avoid putting it into the individual recipe output? > Yes, we can do that and additionally allow each vendor to have their own file, with their own assessment. "upstream-wontfix" can be mapped to "code-not-reached" or similar, when confirmed this is not explotable. Autobuilder can have its own removing entries we don't want to see on CVE list (if we really think it is a good idea). Regards, Marta > > >
On Tue, 2024-08-06 at 15:16 +0200, Marta Rybczynska wrote: > On Thu, Aug 1, 2024 at 4:08 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2024-08-01 at 15:58 +0200, Marta Rybczynska wrote: > > > > Difficult, yes, impossible, no. > > > > > > > > Surely we know which recipes a given CVE apply to? > > > > > > Without having the CVE data at the same time, no. > > > > I thought we had the CVE data? > > When we do vex only, we have the CVE data only in the external tool. > The file that comes out from the build contains additional entries. > We can filter them out, but only in the tool. Since we're using CVE entries with CVE numbering, I think it is ok if even in the vex path, we perform some evaluation to see if a given CVE_STATUS applies to a given recipe, particularly if we're exporting data specific to that recipe. The code change in question doesn't just change VEX but the general CVE output too. > However, if we filter out in the tool (with a rule like: if this CVE > does not apply to the package, remove it), we remove the feature of > the VEX of being able to specify that your package is not affected by > a widely known vulnerability. For example, you can say "I'm not > affected by log4shell because I do not include log4j". This is a > feature that has its use, it avoids responding to multiple > procurement questions, where they all want the same information. > You just say it once, in the VEX. By that argument, you could export every CVE possible against every recipe :/. > > I think we need to distinguish between two cases: > - the data is wrong and we fix it (and we're sure of the fix) - > typically a CPE fix > - the resolution depends on a configuration, typically "not- > applicable-config" - if someone adds a bbappend to the recipe, they > MUST review impact on all related vulnerabilities > - we make an assumption. All of "upstream-wontfix" are of this > category. The YP user MUST make their own assessment here. The user needs to make an assessment, sure, but are we then going to force the user to bbappend every recipe with their assessment? > > > If we keep the .inc file, I think the most correct way would be > > > to add a field marking > > > which recipe it should be applied to. > > > > > > What do you think? > > > > How do we mark up a CVE as applying to gcc-cross-*/gcc-cross- > > canadian- > > */gcc-runtime/libgcc and so on? > > We do not have any gcc entries in cve-extra-exclusions. No, but we, or a downstream user might need to do this. > > How do we convert "bash" to "nativesdk-bash" and "bash-native"? > > We do not have anything related to bash either. Today, no. Tomorrow, or in some other product with a different configuration. > What is in there in cve-extra-exclusions are mostly very old CVEs, > the biggest part belonging to bdb. > Kernel ones can go to kernel includes etc. > > With the directions the CVE programme is going, I do not *expect* a > need for new entries. However, this mechanism is also the mechanism someone building a product and performing their own assessments may want to use. What your patches do is force all of that into the end tooling and out of the metadata and make the metadata completely impractical to do it with. That simply isn't acceptable. > > There are ways we could do such markup but I don't think it is > > going to > > work well. > > > > I guess the key question is what we're trying to achieve and where > > we're expecting the data to be processed? > > > > Could we write a common exclusion file out once as part of the CVE > > fetch recipe and avoid putting it into the individual recipe > > output? > > > > > Yes, we can do that and additionally allow each vendor to have their > own file, with their own assessment. "upstream-wontfix" can be mapped > to "code-not-reached" or similar, when confirmed this is not > explotable. You mean like an .inc file? > Autobuilder can have its own removing entries we don't want to see on > CVE list (if we really think it is a good idea). This is exactly what the file you want to deprecate does. I agreed to put it in the public metadata where people could see what we were doing and why, so they could them make their own assessment of what we've done. I'm afraid I am adamant we cannot drop support for this. (I am also find with reducing the entries in that file, I just think we can't entirely remove support for the capability) Cheers, Richard
diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc index fcef6a14fb..71c5bc31f8 100644 --- a/meta/conf/distro/include/cve-extra-exclusions.inc +++ b/meta/conf/distro/include/cve-extra-exclusions.inc @@ -1,3 +1,6 @@ +# THIS FILE IS DEPRECATED, DO NOT ADD NEW ENTRIES +# All entries from this file should migrate to appropriate recipes. +# # 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 resolve the issue. # It contains all the information we are aware of about an issue and analysis about
This file contains CVE_STATUS without machine-readable information on which recipe it applies to. All entries should be verified and, if appropriate, moved to their corresponding recipes. Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com> --- meta/conf/distro/include/cve-extra-exclusions.inc | 3 +++ 1 file changed, 3 insertions(+)