Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 15 18:05

    haikoschol on develop

    Fix resource leak in NPM import… (compare)

  • Feb 15 17:59

    haikoschol on develop

    Add rust security advisories … Upgrade requirements Signed-of… Use 'with' handler for urlopen… and 1 more (compare)

  • Feb 15 17:59
    haikoschol closed #148
  • Feb 15 17:59
    haikoschol closed #92
  • Feb 15 17:58
    haikoschol review_requested #148
  • Feb 12 12:56
    sbs2001 synchronize #148
  • Feb 12 10:09
    haikoschol labeled #149
  • Feb 12 10:09
    haikoschol opened #149
  • Feb 12 10:09
    haikoschol labeled #149
  • Feb 12 07:03
    haikoschol review_requested #148
  • Feb 10 16:29
    sbs2001 opened #148
  • Feb 10 16:26
    Travis sbs2001/vulnerablecode (add-importer) fixed (35)
  • Feb 10 16:25
    Travis sbs2001/vulnerablecode (add-importer) fixed (39)
  • Feb 10 16:22
    Travis sbs2001/vulnerablecode (add-importer) broken (38)
  • Feb 10 16:22
    Travis sbs2001/vulnerablecode (add-importer) broken (34)
  • Feb 10 16:18
    Travis sbs2001/vulnerablecode (add-importer) passed (37)
  • Feb 10 16:18
    Travis sbs2001/vulnerablecode (add-importer) passed (33)
  • Feb 08 16:02
    haikoschol commented #123
  • Feb 08 15:39
    haikoschol commented #123
  • Feb 08 14:10
    haikoschol closed #122
Philippe Ombredanne
@pombredanne
so we have eventually access to a way to resolve or rather test if the vulnerability applies to a package (and then we can resolve that to a concrete set of vuln <-> relationships IMHO
(this is rather mind bogling though... 5 or 6 nested indirectionsare needed)
Philippe Ombredanne
@pombredanne
Shivam Sandbhor
@sbs2001

So I'm able to map CVE's to packages from the OVAL files , but I'm missing something .

Consider CVE-2015-7559 whose description in com.ubuntu.disco.cve.oval.xml is given as :

<description>It was found that the Apache ActiveMQ client before 5.15.5 exposed a remote shutdown command in the ActiveMQConnection class. An attacker logged into a compromised broker could use this flaw to achieve denial of service on a connected client.</description> which implies activemq x.y.z<5.15.5 are vulnerable to CVE-2015-7559 .

So I digged in the file to see the vulnerable packages for CVE-2015-7559 and I got this :
<constant_variable id="oval:com.ubuntu.disco:var:201575590000000" version="1" datatype="string" comment="'activemq' package binaries"> <value>activemq</value> <value>libactivemq-java</value> </constant_variable> Nowhere it mentions activemq's versions . This is the case with maximum of the CVEs mentioned here, any pointers on what I might be missing?

Philippe Ombredanne
@pombredanne
@sbs2001 is this the ultimate resources/id?
in the worst case, if this is what we have this is what we have.
This is an excellent use case for community curation and peer review :)
Shivam Sandbhor
@sbs2001
@haikoschol I have added a PR to import rust advisory . Please review
Shivam Sandbhor
@sbs2001
Take a look at the data dump operation specifically , since majority of the vulnerabilities in the advisory are not cves(they have ids in form of RUSTSEC-xxxx-xxxx) I had to store their ids in VulnerabilityReference's reference_id
Philippe Ombredanne
@pombredanne

@sbs2001
re

I had to store their ids in VulnerabilityReference's reference_id

:+1: that's exactly the intent and purpose for these

Shivam Sandbhor
@sbs2001

@pombredanne so my previous approach was of using bs4 and extract the data accordingly, but this would require us to craft a new importer for each oval file (for eg red hat's oval schema is different than ubuntu's ) which is impractical. So I had cross out bs4 approach . This issue is bigger than what it seemed to me .

I think we should somehow figure out to use already implemented oval scanner https://github.com/OpenSCAP/openscap/tree/maint-1.3/src/OVAL for our purpose. Apparently they provide an undocumented python api (I am reaching out to openscap folks for help on this one ) https://github.com/OpenSCAP/openscap/blob/maint-1.3/swig/openscap_api.py but I haven't figured out how to use it .

Upon reading the auto-generated documentation http://static.open-scap.org/openscap-1.2/oval__generator_8c.html I believe this repo contains what we need. btw should I add this to the ticket?

Haiko Schol
@haikoschol
@sbs2001 thanks for the PR. i got sick on the weekend which is why i'm behind on #123. i'm feeling better today so will have a look at your changes now
Haiko Schol
@haikoschol
while looking at some example rust advisories i found one that only applies on windows (https://github.com/RustSec/advisory-db/blob/master/crates/hyper/RUSTSEC-2016-0002.toml). with our current data model this information is lost which means a lot of false positives for users on other platforms
Philippe Ombredanne
@pombredanne
@haikoschol get well :)
Haiko Schol
@haikoschol
@pombredanne merci
Philippe Ombredanne
@pombredanne
@sbs2001 I would be really surprised if "for eg red hat's oval schema is different than ubuntu's "
the whole idea of val is to have a common schema
did you try to play with some of the libraries I listed in the ticket beyond the openscap one (which is in C so it comes with its own build issues)?
Also oval is strict XML, so bs4 would not be needed (it helps typically with damaged html) :P

@haikoschol re:

with our current data model this information is lost which means a lot of false positives for users on other platforms

we need a ticket then :)

A natural way to handle it for me would be to add a platform qualifier to the impacted package PackageURL

Haiko Schol
@haikoschol
right, from the perspective of the package url that makes sense. we do have that field via the model mixin but i'm not sure we can easily query on it. however, another question is how this would work in the component that constructs the package url
when would that tool decide to add on which platform it is running? and would that even be a good idea, if the tool runs as part of CI on a different platform than where the app is ultimately deployed?
tricky, but we definitely should have a ticket for it
re oval: i also thought having one oval parser would cover all oval-based sources, but i haven't looked at the files the distributions publish. but i just had a look at trivy-db and they also have one for readhat and one for debian. haven't looked at the code to see whether the difference is in the oval handling itself or something else (could just be the url where to fetch the data from). https://github.com/aquasecurity/trivy-db/tree/master/pkg/vulnsrc
Haiko Schol
@haikoschol
Philippe Ombredanne
@pombredanne
@haikoschol thanks. Yes that's tricky :)
Philippe Ombredanne
@pombredanne
@haikoschol yes, trivy and/or https://github.com/kotakanbe/goval-dictionary
we could reuse all these alright BTW, I do not want to reinvent the wheel
Shivam Sandbhor
@sbs2001
@haikoschol I have made the requested changes , btw we need to make changes to npm importer's get_all_versions() method to prevent the urlopen() issue you talked about.
Shivam Sandbhor
@sbs2001

re:

did you try to play with some of the libraries I listed in the ticket beyond the openscap one (which is in C so it comes with its own build issue

Atm no, openscap seemed promising but it seems to require a lot of work to get it working for our purposes.

I was using bs4 for 'prototyping' , using etree is very painful for me but the plan was to move to etree eventually after getting it right in bs4 . Anyways I am looking at trivy-db atm , finally reading some go code .

Philippe Ombredanne
@pombredanne
@sbs2001 there are libraries that are supposed to deal with Oval that I listed in the ticket... IMHO we shoud evaluate these first
Shivam Sandbhor
@sbs2001
Okay I will research
Shivam Sandbhor
@sbs2001

So after trying all the suggested tools I managed to obtain data in the desired format using https://github.com/kings-way/OVAL2DB , the problem with this tool is we need to work on it to make it python3 compatible .

I also think https://github.com/cjaymes/pyscap might have something useful , I have no idea how to make it work though (no documentation ) . Let me know whether I should dig in deeper , but for the moment
https://github.com/kings-way/OVAL2DB seems good enough .What do you think? Should I explore pyscap or start working on making OVAL2DB python3 compatible?

Haiko Schol
@haikoschol

@haikoschol I have made the requested changes

@sbs2001 thanks! i hope i'll get to review and merge them tonight or tomorrow

btw we need to make changes to npm importer's get_all_versions() method to prevent the urlopen() issue you talked about.

thanks for pointing that out. i think i can take care of it when i'm done with your PR

@sbs2001 i can't comment much on the oval stuff since i haven't looked at any of the libs yet, but i just had a look at the OVAL2DB repo and it's GPLv3. i think we'd have to get an exception/relicense from the author to be able to use it, but pombredanne is the expert on that :)
Shivam Sandbhor
@sbs2001
great :) looking forward to what @pombredanne says
Philippe Ombredanne
@pombredanne
hey :wave: ...catching up with the scroll log....
Philippe Ombredanne
@pombredanne
@sbs2001 I agree with @haikoschol ... the GPL license would be problematic since we are using a permissive license.
Also OVAL2DB has absolutely no unit tests :]
pyscap is also GPL-licensed :|
(Unrelated I am talking tomorrow with the folks of https://github.com/eclipse/steady )
to see if we could collaborate somehow
Philippe Ombredanne
@pombredanne
@sbs2001 pyscap at least has tests ...
Shivam Sandbhor
@sbs2001
@haikoschol suppose in an ideal case , we are able to collect purls of all the vulnerable packages , does that result into fixing nexB/vulnerablecode#149 as vulnerabilities are already linked to a package?
because the corresponding purl will contain the info about the platform
Philippe Ombredanne
@pombredanne
@sbs2001 good point
Shivam Sandbhor
@sbs2001
@pombredanne in future we will be adding solutions to every vulnerability right?
Shivam Sandbhor
@sbs2001
Hey what you think about data from here https://access.redhat.com/hydra/rest/securitydata/cve.json (you can pass in parameters to get more data)
Philippe Ombredanne
@pombredanne

@sbs2001 re:

in future we will be adding solutions to every vulnerability right?

what do you mean?

@sbs2001 re https://access.redhat.com/hydra/rest/securitydata/cve.json

that sounds great... create or add the details to a ticket

Shivam Sandbhor
@sbs2001

@pombredanne in future we will be adding solutions to every vulnerability right?

Consider vulnerability 'CVE-A' , suppose the advisory from where we get data about 'CVE-A' also contains ways to avoid/fix the 'CVE-A' . Our current vulnerability model has no way for storing these instructions related to prevention of the corresponding vulnerability . Should we add an additional field for storing this data?

Shivam Sandbhor
@sbs2001
https://developer.cisco.com/docs/psirt/#!api-reference interesting! Can we use this ? We need some sort of cisco account for that