search

Ravenports / ravenadm

Administration tool for Ravenports
http://www.ravenports.com
ISC License
17 stars 3 forks source link

Expose CPE_VENDOR/CPE_PRODUCT in repology.json #15

Closed AMDmi3 closed 4 years ago

AMDmi3 commented 4 years ago

This would be useful for vulnerability reporting in Repology (repology/repology-updater#15)

jrmarino commented 4 years ago

Okay. We have it set in many ports but its probably missing in many more. Maybe having it in Repology will help setting those values in the ports that it's missing though. Dunno...

AMDmi3 commented 4 years ago

Very likely, in fact I plan to generate problems on this basis in future. For now I can share a diff against CPE info from Gentoo as soon as I get CPEs from Ravenports.

Btw, you can check out experimental vulnerabilities support:

jrmarino commented 4 years ago

Okay, I have generated the repology.json with a dev version of ravenadm: https://raw.githubusercontent.com/jrmarino/Ravenports/master/Mk/Misc/repology.json

example:

  ,{
     "bucket": "03"
    ,"namebase": "ffmpeg"
    ,"version": "4.2.2"
    ,"homepage": "https://www.ffmpeg.org/"
    ,"FPC": "multimedia/ffmpeg"
    ,"keywords": [ "multimedia", "audio", "net" ]
    ,"distfile": [ "http://ffmpeg.org/releases/ffmpeg-4.2.2.tar.xz" ]
    ,"cpe": { "product": "ffmpeg", "vendor": "ffmpeg" }
    ,"variants":
     [
      {
        "label": "standard"
       ,"sdesc": "Play, record, convert, and stream audio and video"
       ,"spkgs": [ "complete", "primary", "examples", "docs" ]
      }
     ]
   }

so first, does that satisfy the request?

Secondly, I'm sure some of the CPE values are defined wrong because frankly I'm not using them yet, e.g 

"cpe": { "product": "xorg-pixman", "vendor": "xorg-pixman" }

probably isn't correct.

Will repology identify these error implicitly? E.g. it doesn't match CPE database, there's only one, etc? Also, will repology be able to identify packages that are in CPE database but ravenports hasn't set the cpe values? If repology can identify these things, we can fix the CPE definitions and add them to all the ports that are missing them.

AMDmi3 commented 4 years ago

so first, does that satisfy the request?

Yes, looks good to me, thanks!

Will repology identify these error implicitly? E.g. it doesn't match CPE database, there's only one, etc?

The code needs to be written, but there's nothing preventing us from generating problems when no CVE match given CPEs. Added repology/repology-updater#1039 for this.

Also, will repology be able to identify packages that are in CPE database but ravenports hasn't set the cpe values?

Repology needs to get CPE information for projects somewhere, and it currently relies on repositories which provide it. The only supported repository right now is Gentoo, the second will be Ravenports, and sometime I'll support FreeBSD, when I get my hands on making a custom dump for it. Also, I plan to support adding CPEs manually (repology/repology-updater#1040).

So yes, Repology is able to idenitfy some projects for which Ravenports does not have CPE information, but not all of them and each source of CPE information is important.

jrmarino commented 4 years ago

https://github.com/jrmarino/ravenadm/releases/tag/v1.55 Okay, thanks. I look forward to auditing all the ports for CPE values. This could be a very big benefit, so I'm really hopefully about the potential here.

AMDmi3 commented 4 years ago

Here's something to start with: https://pastebin.com/DHDRHUtd, it's a result of quick query listing gentoo compared to ravenports CPEs with number of associated CVEs. Looks like there's a lot to improve in both gentoo and ravenports, and probably NVD also has some problems.

jrmarino commented 4 years ago

@AMDmi3 Thanks. I just went through the rows where gentoo and ravenports both had entries. For the most part gentoo was correct, but I found these differences:

Whose correct? Differences
neither alsa-lib|alsa-project:alsa-lib|alsa-lib:alsa-lib
technically both (2) curl|haxx:libcurl|haxx:curl
Ravenports libxfont|x.org:libxfont|x:libxfont
Ravenports (1) libzip|nih:libzip|libzip:libzip
Ravenports nss|mozilla:nss|mozilla:network_security_services
Ravenports tiff|libtiff_project:libtiff|libtiff:libtiff
   
"(1)" Refers to a different product (likely caused by package merging)
"(2)" both haxx:curl and haxx:libcurl are validate.  Could be split into subpackages.

The most interesting for us involve subpackages. Curl is a good example. Now on ravenports, curl and libcurl are actually in a single package, but it could have easily have been split up into subpackages. For other repos, it could have been split up into separate packages but both falling under "curl" in repology. Both haxx:curl and haxx:libcurl are valid CPE so both are going to show in the same repology package (as an aside I change the CPE to ravenports to libcurl at least for now).

the libzip line is probably similar. In a couple of cases Gentoo is actually wrong and in the alsa case both repos were wrong. (The current CPE is alsa-project:alsa). When I republish later today the corrected CPEs will show on Ravenports.

jrmarino commented 4 years ago

So there's quite a few mistakes in gentoo that I found, @AMDmi3 . In case you are interested:

package comment
c-ares             daniel_stenberg:c-ares wrong vendor
cmake              cmake_project:cmake refers to node.js, not cmake
expat              libexpat:expat old vendor, new libexpat_project
fribidi            fribidi:gnu_fribidi correct is gnu:fribidi
fuse               fuse:fuse correct is fuse_project:fuse
ghostscript        artifex:gpl_ghostscript old product, now it's just "ghostscript"
gtk                gtk:gtk%2B version 2.2.  cpe 2.3 is "gtk:gtk+"
libcroco           gnome:libcroco not present in nvd
libevent           niels_provos:libevent correct vendor is "libevent_project"
libidn2            libidn2_project:libidn2 correct vendor is "gnu"
libvorbis          xiph:libvorbis correct vendor is "xiph.org"
libxfont2          x.org:libxfont Both wrong.  Closest is "x:libxfont" but that's for version 1.  No nvd entry?
libxkbcommon       xkbcommon:libxkbcommon correct vendor is "xkbcommon_project"
pcre2              pcre:pcre correct product is "pcre2"
python:urllib3     urllib3:urllib3 correct vendor is "python"
speex              xiph:speex not present in nvd
speexdsp           xiph:speex not present in nvd
tidy               html-tidy:tidy correct vendor is "htacg"
unrar              rarlab:unrar not present in nvd
xinit              x.org:xinit not present in nvd
xinput             x.org:xinput not present in nvd
xkeyboard-config   xkeyboard_config_project:xkeyboard-config not present in nvd
xrdb               matthias_hopf:xrdb not present in nvd
AMDmi3 commented 4 years ago 
May 11 23:11:04   ERROR: failed: YAJL error: lexical error: inside a string, '\' occurs before a character which it may not.
              ,"cpe": { "product": "gtk\+", "vendor": "gtk" }     ,"va
                     (right here) ------^
jrmarino commented 4 years ago

I was actually worried about one. I'll remove the cpe setting for now. It would require some kind of escape in ravenadm to fix. I don't even know what the correct text should be. 

(gtk\\+ maybe?)
AMDmi3 commented 4 years ago

Just gtk+.

https://www.freeformatter.com/json-escape.html

jrmarino commented 4 years ago

right, but I wasn't trying to escape the plus sign. The slash is literal. The full cpe for gtk3: 

cpe:2.3:a:gtk:gtk\+:3.10.9:

So according to your link, i would have needed ravenadm to transform 

gtk\+

to 

gtk\\+

.

AMDmi3 commented 4 years ago

In that case probably yes, it's the same as they are escaped in CVD CVE feeds:

          "cpe23Uri" : "cpe:2.3:a:gtk:gtk\\+:1.1.12:*:*:*:*:*:*:*"

However I'm not sure if it's correct as CPE are URLs themselves and are escaped internally (to allow literal : at least, so it may be that it's in fact just gtk+. Repology parses it as gtk+ at least.

jrmarino commented 4 years ago

hmm, okay, maybe nvd site presented it incorrectly. I'll try again with just "gtk+" later today.

AMDmi3 commented 4 years ago

hmm, okay, maybe nvd site presented it incorrectly

No, it's likely correct when used within CPE, as at least delimeter and backslash must be escaped there and probably other escaping rules apply (still haven't read the specification), e.g. cpe:2.3:a:foobar:seven_kingdoms\:ancient_adversaries:*..., however when vendor/product is used alone, no escaping is ever needed (vendor=foobar, product=seven_kingdoms:ancient_adversaries).

AMDmi3 commented 4 years ago

The most interesting for us involve subpackages. Curl is a good example.

This is not related to subpackages in fact - more to the parts of the original project, as curl and libcurl are distributed as one, and because of that IMO these CVEs should use single product as there is, in fact, a single product. This is not a problem for Repology though as it treats curl as a single project and just link all CVEs there:

https://repology.org/project/curl/cves

correct vendor is

Note that apart from cases which are never encountered in NVD which are most likely wrong, there's still no "correct vendor" as CVE may be linked to multiple different CPE vendor/products, and technically one wants to support them all, because

So cases like this are pretty common: https://repology.org/project/libexif/cves

AMDmi3 commented 4 years ago

FYI, CPE related problems are now reported:

https://repology.org/repository/ravenports/problems

jrmarino commented 4 years ago

okay, going through them now. I can already seen some things that are reported as problems that are actually wrong. example: we have cases where gentoo is wrong (e.g. libcroco) that to remove that, ravenports would have to make the same error example2: some of these are reported as "no CVEs found so it probably is bogus" but I checked them before entering them. the cpes are correct but there may not be any CVEs yet. so it's getting reported as a problem where there is no problem. so good start but we might have to rethink some of these. Plus I was thinking it would be a separate "info" page rather than combining with problems since the confidence on whether they are real problems isn't really that high.

jrmarino commented 4 years ago

Still working on it. I'll summarize at end. strike what I said about libcroco though. for some reason it shows in nvd now.

jrmarino commented 4 years ago

@AMDmi3 So I've boiled this down to a single problem type. Basically the problems report is flagging valid CPEs as invalid because there are no matching CVEs for those CPES. re: https://nvd.nist.gov/products/cpe/search

No CVEs found keyword matching records
gmplib:gmp cpe:2.3: a:gmplib:gmp 35
libffi_project:libffi cpe:2.3: a:libffi_project:libffi 9
gnupg:libgpg-error cpe:2.3: a:gnupg:libgpg-error 42
netfilter:libmnl cpe:2.3: a:netfilter:libmnl 4
popt_project:popt cpe:2.3: a:popt_project:popt 1
rhash_project:rhash cpe:2.3: a:rhash_project:rhash 55
gnu:sed cpe:2.3: a:gnu:sed 31
tukaani:xz cpe:2.3: a:tukaani:xz 25

(ignore space in middle of keyword, git markdown was getting triggered and making 🅰️ in middle of it)

So basically I think we should check the given CPEs against NVD before declaring it bad. So the logic would be "no CVEs found so check NVD. If CPE not found in NVD, then issue problem report"

AMDmi3 commented 4 years ago

example: we have cases where gentoo is wrong (e.g. libcroco) that to remove that, ravenports would have to make the same error

Problems and suggestions are only generated for CPEs which have known CVEs, so bad CPEs from e.g. Gentoo won't generate any problems, unless they refer to a completely unrelated product.

Plus I was thinking it would be a separate "info" page rather than combining with problems since the confidence on whether they are real problems isn't really that high.

Problems are advisory, false positives are possible in any type of them and you don't need to fix them all. In future there will be more ways of moving unfixable problems out of the way.

example2: some of these are reported as "no CVEs found so it probably is bogus" but I checked them before entering them. the cpes are correct but there may not be any CVEs yet

Basically the problems report is flagging valid CPEs as invalid because there are no matching CVEs for those CPES.

Hmm. I still won't rely on that actual CVEs which may appear would use these CPEs, but having some meaningful CPE defined just in case is definitely a valid case. I guess I'll have to add support for CPE dictionary which NVD provides as well.

AMDmi3 commented 4 years ago

I guess I'll have to add support for CPE dictionary which NVD provides as well.

Done, looks like there are no longer any false positives for this kind of problem.

jrmarino commented 4 years ago

Nice job!

AMDmi3 commented 4 years ago

I did some revamp of CPE/CVE support infrastructure in Repology, you might be interested in an update:

jrmarino commented 4 years ago

okay. So I was already about to add json escaping code to ravenadm, so I'll go ahead and do that and update gtk+ to how I had it originally. Now, for the remaining CPE tags, I'm planning to only add them to the json object if they are defined by the spec sheet. I'm sure that's not an issue for your parser -- it just has to be told it might exist rather than guaranteed. I will post back with the json keys when I implement them. Technically we support all the fields that FreeBSD does, but originally you only cared about the two (and frankly I think only one port attempted to support a CPE field other than those). I'll be on the lookout for new problem reports.

jrmarino commented 4 years ago

this is from the cpe USES module in Ravenports:

# CPE_PART      Defaults to "a" for "application".
# CPE_VENDOR        Defaults to same as ${CPE_PRODUCT} (below).
# CPE_PRODUCT       Defaults to ${PORTNAME}.
# CPE_VERSION       Defaults to ${PORTVERSION}.
# CPE_UPDATE        Defaults to empty.
# CPE_EDITION       Defaults to empty.
# CPE_LANG      Defaults to empty.
# CPE_SW_EDITION    Defaults to empty.
# CPE_TARGET_SW     Defaults to the operating system name and version
# CPE_TARGET_HW     Defaults to x86 for i386, x64 for amd64, and
#           otherwise ${ARCH}.
# CPE_OTHER     Defaults to ${PORTREVISION} if non-zero.

My plan is to continue to publish CPE_VENDOR and CPE_PRODUCT in all cases, and the remaining ones only if they are defined in the spec sheet and differing from the default. That means repology would have to set CPE_VERSION (if undefined) from the already provided version. The defaults for CPE_TARGET_HW don't make sense in this case because one port in theory builds on multiple architectures so we can't pick just one.

So with that plan, if CPE is used, it will always have at least the two fields it has now. But it may have more. Would that work?

AMDmi3 commented 4 years ago

Sure. I'd just like to know how they will be named in JSON.

jrmarino commented 4 years ago

okay, the full key set would be:

  1. "part"
  2. "vendor" (implemented)
  3. "product" (implemented)
  4. "version"
  5. "update"
  6. "edition"
  7. "lang"
  8. "sw_edition"
  9. "target_sw"
  10. "target_hw"
  11. "other"