Re: [OE-core] [yocto-security] OE-core CVE metrics for master on Sun 24 Jan 2021 07:15:01 AM HST

["Lee Chee Yang" <chee.yang.lee@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 4888 bytes --]

A variable in recipe to indicate the character as patch level?
like CVE_VERSION_SUFFIX  in  “alphabetical”  so the parser understand the last alphabetical character as patched release




From: Ross Burton <ross@burtonini.com>
Sent: Tuesday, 26 January, 2021 5:54 PM
To: Lee, Chee Yang <chee.yang.lee@intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>; Steve Sakoman <steve@sakoman.com>; openembedded-core@lists.openembedded.org; yocto-security@lists.yoctoproject.org
Subject: Re: [OE-core] [yocto-security] OE-core CVE metrics for master on Sun 24 Jan 2021 07:15:01 AM HST

Versions using a single character for patch level isn’t rare, and OpenSSL is high impact. Can we special case these in the parser?

Ross

On Tue, 26 Jan 2021 at 03:55, Lee Chee Yang <chee.yang.lee@intel.com<mailto:chee.yang.lee@intel.com>> wrote:
for this case the new changes only consider 1.1.1 from both 1.1.1i  and 1.1.1b , do not takes the trailing "i" and "b" when comparing them , so these 2 version are treated as same version ( 1.1.1 ) when comparing them.

I expected this although knowing that compare version in this way can falsely report more CVE, but this can capture some corner case.

>-----Original Message-----
>From: Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>>
>Sent: Tuesday, 26 January, 2021 6:10 AM
>To: Lee, Chee Yang <chee.yang.lee@intel.com<mailto:chee.yang.lee@intel.com>>; Steve Sakoman
><steve@sakoman.com<mailto:steve@sakoman.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>; yocto-
>security@lists.yoctoproject.org<mailto:security@lists.yoctoproject.org>
>Subject: Re: [yocto-security] OE-core CVE metrics for master on Sun 24 Jan 2021
>07:15:01 AM HST
>
>I'm not sure its working. For example:
>
>https://nvd.nist.gov/vuln/detail/CVE-2019-1543
>
>which says it applies to:
>
>1.1.0 to 1.1.0j
>and
>1.1.1 to 1.1.1b
>
>Master has 1.1.1i which is greater than 1.1.1b so we shouldn't be shown as at risk
>yet the CVE is listed.
>
>Cheers,
>
>Richard
>
>On Mon, 2021-01-25 at 02:39 +0000, Lee, Chee Yang wrote:
>> The changes expose these, it ignored trailing character in this
>> version compare ( "i" in this case for openssl_1.1.1i )
>> (CVE-2019-1543, CVE-2019-1547, CVE-2019-1549, CVE-2019-1551,
>> CVE-2019-1552, CVE-2019-1563, CVE-2020-1967, CVE-2020-1971) behave
>> this way because its difficult to define the trailing characters (like
>> version 1.1b can be 1.1 beta or patched release 1.1b)
>>
>>
>> NVD just updated these recently
>> CVE-2013-0800, CVE-2020-14409, CVE-2020-14410
>>
>>
>>
>> > -----Original Message-----
>> > From: Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>>
>> > Sent: Monday, 25 January, 2021 7:21 AM
>> > To: Steve Sakoman <steve@sakoman.com<mailto:steve@sakoman.com>>; openembedded-
>> > core@lists.openembedded.org<mailto:core@lists.openembedded.org>; yocto-security@lists.yoctoproject.org<mailto:yocto-security@lists.yoctoproject.org>
>> > Cc: Lee, Chee Yang <chee.yang.lee@intel.com<mailto:chee.yang.lee@intel.com>>
>> > Subject: Re: [yocto-security] OE-core CVE metrics for master on Sun
>> > 24 Jan 2021
>> > 07:15:01 AM HST
>> >
>> > On Sun, 2021-01-24 at 07:18 -1000, Steve Sakoman wrote:
>> > > Branch: master
>> > >
>> > > New this week:
>> > > CVE-2013-0800: pixman
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0800 *
>> > > CVE-2019-1543: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1543 *
>> > > CVE-2019-1547: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1547 *
>> > > CVE-2019-1549: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1549 *
>> > > CVE-2019-1551: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1551 *
>> > > CVE-2019-1552: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1552 *
>> > > CVE-2019-1563: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1563 *
>> > > CVE-2020-14409: libsdl2
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-14409 *
>> > > CVE-2020-14410: libsdl2
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-14410 *
>> > > CVE-2020-1967: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-1967 *
>> > > CVE-2020-1971: openssl
>> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-1971 *
>> >
>> > Adding Chee Yang, did the recent cve-check change mean some version
>> > comparisons regressed and exposed CVEs that shouldn't be in this
>> > list, or were we making some we need to fix? Or did some other change
>expose these?
>> >
>> > Cheers,
>> >
>> > Richard
>> >
>> >
>>
>>
>




[-- Attachment #2: Type: text/html, Size: 10104 bytes --]