all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#40142: CVE checker return false positives
@ 2020-03-20  9:10 Brice Waegeneire
  2020-03-21 16:25 ` Ludovic Courtès
  2020-04-01 17:01 ` bug#40142: (guix cve) discards configuration "vendor", leading to " Brice Waegeneire
  0 siblings, 2 replies; 5+ messages in thread
From: Brice Waegeneire @ 2020-03-20  9:10 UTC (permalink / raw)
  To: 40142

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'.

[CVE-2020-2136] <https://nvd.nist.gov/vuln/detail/CVE-2020-2136>

[CVE-2019-1003010] <https://nvd.nist.gov/vuln/detail/CVE-2019-1003010>

[CVE-2018-1000110] <https://nvd.nist.gov/vuln/detail/CVE-2018-1000110>

[CVE-2018-1000182] <https://nvd.nist.gov/vuln/detail/CVE-2018-1000182>

Brice.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#40142: CVE checker return false positives
  2020-03-20  9:10 bug#40142: CVE checker return false positives Brice Waegeneire
@ 2020-03-21 16:25 ` Ludovic Courtès
  2020-03-21 16:57   ` Brice Waegeneire
  2020-04-01 17:01 ` bug#40142: (guix cve) discards configuration "vendor", leading to " Brice Waegeneire
  1 sibling, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2020-03-21 16:25 UTC (permalink / raw)
  To: Brice Waegeneire; +Cc: 40142

Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

> 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

[...]

> • [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”:

--8<---------------cut here---------------start------------->8---
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>>
--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---
$ 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"
              }
            ]
          }
        ]
--8<---------------cut here---------------end--------------->8---

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!

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

What do you mean?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#40142: CVE checker return false positives
  2020-03-21 16:25 ` Ludovic Courtès
@ 2020-03-21 16:57   ` Brice Waegeneire
  0 siblings, 0 replies; 5+ messages in thread
From: Brice Waegeneire @ 2020-03-21 16:57 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 40142

Hello,

On 2020-03-21 16:25, Ludovic Courtès wrote:
> 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.

>> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#40142: (guix cve) discards configuration "vendor", leading to false positives
  2020-03-20  9:10 bug#40142: CVE checker return false positives Brice Waegeneire
  2020-03-21 16:25 ` Ludovic Courtès
@ 2020-04-01 17:01 ` Brice Waegeneire
  2020-04-02 10:38   ` Ludovic Courtès
  1 sibling, 1 reply; 5+ messages in thread
From: Brice Waegeneire @ 2020-04-01 17:01 UTC (permalink / raw)
  To: 40142

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
https://issues.guix.info/issue/40367.

> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#40142: (guix cve) discards configuration "vendor", leading to false positives
  2020-04-01 17:01 ` bug#40142: (guix cve) discards configuration "vendor", leading to " Brice Waegeneire
@ 2020-04-02 10:38   ` Ludovic Courtès
  0 siblings, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2020-04-02 10:38 UTC (permalink / raw)
  To: Brice Waegeneire; +Cc: 40142

Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

> 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.

> 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’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-04-02 10:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-20  9:10 bug#40142: CVE checker return false positives Brice Waegeneire
2020-03-21 16:25 ` Ludovic Courtès
2020-03-21 16:57   ` Brice Waegeneire
2020-04-01 17:01 ` bug#40142: (guix cve) discards configuration "vendor", leading to " Brice Waegeneire
2020-04-02 10:38   ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

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.