(guix cve) discards configuration "vendor", leading to false positives

  • Open
  • quality assurance status badge
Details
2 participants
  • Brice Waegeneire
  • Ludovic Courtès
Owner
unassigned
Submitted by
Brice Waegeneire
Severity
normal

Debbugs page

Brice Waegeneire wrote 5 years ago
CVE checker return false positives
(address . bug-guix@gnu.org)
0bb3b7878b37095b4ed7fa49aee5936f@waegenei.re
Hello,

The CVE checker of “guix lint” returns false positives:
┌────
│ LANGUAGE=C guix lint git 2>&1
├───
│ gnu/packages/version-control.scm:149:2: git@2.25.1: probably
vulnerable to CVE-2020-2136, CVE-2019-1003010, CVE-2018-1000110,
CVE-2018-1000182
│
/gnu/store/8q0nfd6vnc6lnjh13rwl7fyimwlv7fml-guix-module-union/share/guile/site/3.0/gnu/packages/version-control.scm:153:12:
git@2.25.1: can be upgraded to 2.25.2
│
/gnu/store/8q0nfd6vnc6lnjh13rwl7fyimwlv7fml-guix-module-union/share/guile/site/3.0/gnu/packages/version-control.scm:154:11:
git@2.25.1: source not archived on Software Heritage
└────


• [CVE-2020-2136]: “Jenkins Git Plugin 4.2.0 and earlier […]”
• [CVE-2019-1003010]: “[…] Jenkins Git Plugin 3.9.1 and earlier […]”
• [CVE-2018-1000110]: “[…] Jenkins Git Plugin version 3.7.0 and earlier
[…]”
• [CVE-2018-1000182]: “[…] Jenkins Git Plugin 3.9.0 and older […]”

Also note the missing / on the first line and it output on `stderr'
instead of `stdout'.





Brice.
Ludovic Courtès wrote 5 years ago
(name . Brice Waegeneire)(address . brice@waegenei.re)(address . 40142@debbugs.gnu.org)
87sgi1znd8.fsf@gnu.org
Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

Toggle quote (8 lines)
> The CVE checker of “guix lint” returns false positives:
> ┌────
> │ LANGUAGE=C guix lint git 2>&1
> ├───
> │ gnu/packages/version-control.scm:149:2: git@2.25.1: probably
> vulnerable to CVE-2020-2136, CVE-2019-1003010, CVE-2018-1000110,
> CVE-2018-1000182

[...]

Toggle quote (6 lines)
> • [CVE-2020-2136]: “Jenkins Git Plugin 4.2.0 and earlier […]”
> • [CVE-2019-1003010]: “[…] Jenkins Git Plugin 3.9.1 and earlier […]”
> • [CVE-2018-1000110]: “[…] Jenkins Git Plugin version 3.7.0 and earlier
> […]”
> • [CVE-2018-1000182]: “[…] Jenkins Git Plugin 3.9.0 and older […]”

(guix cve) reports it as applying to “git”:

Toggle snippet (9 lines)
scheme@(guix cve)> (define items
(call-with-decompressed-port 'gzip (http-fetch (yearly-feed-uri 2020))
json->cve-items))
scheme@(guix cve)> (find (lambda (item)
(string=? (cve-id (cve-item-cve item)) "CVE-2020-2136"))
items)
$130 = #<<cve-item> cve: #<<cve> id: "CVE-2020-2136" data-type: CVE data-format: MITRE references: (#<<cve-reference> url: "http://www.openwall.com/lists/oss-security/2020/03/09/1" tags: ("Third Party Advisory")> #<<cve-reference> url: "https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1723" tags: ("Vendor Advisory")>)> configurations: (("git" (<= "4.2.0"))) published-date: #<date nanosecond: 0 second: 0 minute: 15 hour: 16 day: 9 month: 3 year: 2020 zone-offset: 0> last-modified-date: #<date nanosecond: 0 second: 0 minute: 4 hour: 20 day: 9 month: 3 year: 2020 zone-offset: 0>>

I think the problem stems from the fact that the CVE configuration
specify “jenkins:git” (where “jenkins” is the “vendor” and “git” is the
“product”), but we just strip the vendor part:

Toggle snippet (20 lines)
$ wget -O - -q https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2020.json.gz| gunzip | jq

[…]

"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"operator": "OR",
"cpe_match": [
{
"vulnerable": true,
"cpe23Uri": "cpe:2.3:a:jenkins:git:*:*:*:*:*:jenkins:*:*",
"versionEndIncluding": "4.2.0"
}
]
}
]

It’s usually the case that the vendor part has little relevance for free
software packages, but in this case it does make a difference.

Probably the fix would be to preserve the vendor part in the API and to
somehow use it meaningfully.

Ideas & patches welcome!

Toggle quote (3 lines)
> Also note the missing / on the first line and it output on `stderr'
> instead of `stdout'.

What do you mean?

Thanks,
Ludo’.
Brice Waegeneire wrote 5 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 40142@debbugs.gnu.org)
95d598f98f65efd7a5c89aaf52b80df1@waegenei.re
Hello,

On 2020-03-21 16:25, Ludovic Courtès wrote:
Toggle quote (5 lines)
> Probably the fix would be to preserve the vendor part in the API and to
> somehow use it meaningfully.
>
> Ideas & patches welcome!

I'll see what I can write a patch to fix it then.

Toggle quote (5 lines)
>> Also note the missing / on the first line and it output on `stderr'
>> instead of `stdout'.
>
> What do you mean?

I misunderstood the meaning of “gnu/packages/version-control.scm:149:2:”
and thought there was a missing / before “gnu/”; this is irrelevant.
About
the output stream of “guix lint” I think it should output to `stdout',
not
`stderr' as it's currently the case.

Brice.
Ludovic Courtès wrote 5 years ago
control message for bug #40142
(address . control@debbugs.gnu.org)
87y2rtwev3.fsf@gnu.org
retitle 40142 (guix cve) discards configuration "vendor", leading to false positives
quit
Brice Waegeneire wrote 5 years ago
(guix cve) discards configuration "vendor", leading to false positives
(address . 40142@debbugs.gnu.org)
ee58b7a4cda4f5a09eb1bbd303ac36d6@waegenei.re
Hello,

I have thought of a way to improve on those false positives. And I have
submitted a patch to solve the stderr situation at

Toggle quote (3 lines)
> Probably the fix would be to preserve the vendor part in the API and to
> somehow use it meaningfully

It looks like, for most free software the name of the software is used
as
the vendor too, but I'm guessing that's not always the case in
particular
when two project are using the same name. So we can't just filter the
entries where the vendor name isn't the name of the package or we could
end up with false negatives which seems worse than false positive for a
vulnerability checker.

One solution would be to display the name of the vendor when it doesn't
correspond to the name of the package. Such solution would still output
false positives but at least it will be quicker to identify then as
such,
compared to looking up and reading trough each CVE.

- Brice
Ludovic Courtès wrote 5 years ago
(name . Brice Waegeneire)(address . brice@waegenei.re)(address . 40142@debbugs.gnu.org)
87mu7up3zb.fsf@gnu.org
Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

Toggle quote (9 lines)
> It looks like, for most free software the name of the software is used
> as
> the vendor too, but I'm guessing that's not always the case in
> particular
> when two project are using the same name. So we can't just filter the
> entries where the vendor name isn't the name of the package or we could
> end up with false negatives which seems worse than false positive for a
> vulnerability checker.

Yeah.

Toggle quote (6 lines)
> One solution would be to display the name of the vendor when it doesn't
> correspond to the name of the package. Such solution would still output
> false positives but at least it will be quicker to identify then as
> such,
> compared to looking up and reading trough each CVE.

Yes, though I think that (guix cve) should simply preserve the vendor
part, and leave it up to its user, ‘guix lint’, to display vendor
mismatches.

Thanks,
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 40142@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40142
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help