search

archlinux / arch-security-tracker

Arch Linux Security Tracker
https://security.archlinux.org
MIT License
121 stars 38 forks source link

import cve's automatically with a queue where CVe's can be reviewed #141

Open jelly opened 5 years ago

jelly commented 5 years ago

It would be nice to import CVE's automatically using an API maybe such as https://cve.circl.lu/api/ or https://nvd.nist.gov/vuln/data-feeds and add a review / queue to the security tracker to review these issues.

An idea is to create a new view /todo/cve and show a list of CVE's who don't have at least two signoffs and show the following information:

CVE-XXX-XX-XX (a link) product and version, description and links. If the product can be found in our Package model show the package and version or do a fuzzy match on our Packages and show a list? There should be a button to create an AVG with this CVE pre-filled in.

The CVE signoffs should be a table cve_signoff that stores the CVE id, team member, signoff time

Open questions:

jelly commented 4 years ago

@ysf can you take a look at this?

ysf commented 4 years ago

It would be great to have a sanitized dump to get a feel of how the data has to look later on and generally work with the tracker.

shibumi commented 4 years ago

Hi @ysf, sad that we didn't met on 36C3 :) You can find dumps of our data via putting .json in your URL bar. For example for a CVE: https://security.archlinux.org/CVE-2019-6474.json

{
  "name": "CVE-2019-6474",
  "type": "denial of service",
  "severity": "High",
  "vector": "Remote",
  "description": "An issue has been found in the Kea DHCPv6 server before 1.6.0 or 1.5.0-P1, where a missing check on incoming client requests can be exploited to cause a situation where the Kea server's lease storage contains leases which are rejected as invalid when the server tries to load leases from storage on restart. If the number of such leases exceeds a hard-coded limit in the Kea code, a server trying to restart will conclude that there is a problem with its lease store and give up.",
  "groups": [
    "AVG-1032"
  ],
  "packages": [
    "kea"
  ],
  "advisories": [],
  "references": [
    "https://kb.isc.org/docs/cve-2019-6474"
  ],
  "notes": "CVE-2019-6474 can only affect servers which are using memfile for lease storage"
}

For an AVG: https://security.archlinux.org/AVG-1032.json

{
  "name": "AVG-1032",
  "packages": [
    "kea"
  ],
  "status": "Vulnerable",
  "severity": "High",
  "type": "denial of service",
  "affected": "1.5.0-10",
  "fixed": null,
  "ticket": null,
  "issues": [
    "CVE-2019-6474",
    "CVE-2019-6473",
    "CVE-2019-6472"
  ],
  "advisories": [],
  "references": [
    "https://marc.info/?l=oss-security&m=156706528412669"
  ],
  "notes": null
}

and so on. Hope this helps.

ysf commented 4 years ago

Yeah, but I don't want to scrape those and add them under an anonymous user into my local database if those could be easily sanitized to get a realistic working environment. Actually it's a time issue, if it's quicker to scrape and import than to sanitize and share I'll gladly do it.

Foxboron commented 4 years ago

I think there should be two views on the tracker for this data.

Obviously the entries needs to be as few false positives as possible. We should also enable easy creation of an AVG group and do some basic matching on pkgname and version to find existing AVGs.