7 ms·

How does this tool go from a vuln. in a library to -> a set of affected functions/control paths? My understanding was that the CVE format is unustructed which m

How does this tool go from a vuln. in a library to -> a set of affected functions/control paths? My understanding was that the CVE format is unustructed which makes an analysis like this difficult

theptip 4y ago
My question too. All I see is this citation: > [1] We’ll be sharing more details about this work later in October. Stay tuned!
ievans 4y ago
We added support to the Semgrep engine for combining package metadata restrictions (from the CVE format) with code search patterns that indicate you're using the vulnerable library (we're writing those mostly manually, but Semgrep makes it pretty easy): - id: vulnerable-awscli-apr-2017 pattern-either: - pattern: boto3.resource('s3', ...) - pattern: boto3.client('s3', ...) r2c-internal-project-depends-on: namespace: pypi package: awscli version: "<= 1.11.82" message: this version of awscli is subject to a directory traversal vulnerability in the s3 module This is still experimental and internal (https://semgrep.dev/docs/experiments/r2c-internal-project-depends-on/#example https://semgrep.dev/docs/experiments/r2c-internal-project-de...) but eventually we'd like to promote it and also maybe open up our CVE rules more as well!
- mattkopecki 4y ago
  Here is a good writeup of some of the pros and cons of using a "reachability" approach. https://blog.sonatype.com/prioritizing-open-source-vulnerabilities-is-reachability-useful https://blog.sonatype.com/prioritizing-open-source-vulnerabi... >Unfortunately, no technology currently exists that can tell you whether a method is definitively not called, and even if it is not called currently, it’s just one code change away from being called. This means that reachability should never be used as an excuse to completely ignore a vulnerability, but rather reachability of a vulnerability should be just one component of a more holistic approach to assessing risk that also takes into account the application context and severity of the vulnerability.
  - sverhagen 4y ago
    I saw that Java support was still in beta. But it makes me wonder if it's going to come with a "don't use reflection" disclaimer, then...?
  - DannyBee 4y ago
    Err, "no technology currently exists" is wrong, "no technology can possibly exist" to say whether something if definitively called. It's an undecidable problem in any of the top programming languages, and some of the sub problems (like aliasing) themselves are similarly statically undecidable in any meaningful programming language. You can choose between over-approximation or under-approximation.

How does this tool go from a vuln. in a library to -> a set of affected functions/control paths? My understanding was that the CVE format is unustructed which makes an analysis like this difficult

theptip 4y ago

My question too. All I see is this citation: > [1] We’ll be sharing more details about this work later in October. Stay tuned!

ievans 4y ago

We added support to the Semgrep engine for combining package metadata restrictions (from the CVE format) with code search patterns that indicate you're using the vulnerable library (we're writing those mostly manually, but Semgrep makes it pretty easy): - id: vulnerable-awscli-apr-2017 pattern-either: - pattern: boto3.resource('s3', ...) - pattern: boto3.client('s3', ...) r2c-internal-project-depends-on: namespace: pypi package: awscli version: "<= 1.11.82" message: this version of awscli is subject to a directory traversal vulnerability in the s3 module This is still experimental and internal (https://semgrep.dev/docs/experiments/r2c-internal-project-depends-on/#example https://semgrep.dev/docs/experiments/r2c-internal-project-de...) but eventually we'd like to promote it and also maybe open up our CVE rules more as well!

mattkopecki 4y ago
Here is a good writeup of some of the pros and cons of using a "reachability" approach. https://blog.sonatype.com/prioritizing-open-source-vulnerabilities-is-reachability-useful https://blog.sonatype.com/prioritizing-open-source-vulnerabi... >Unfortunately, no technology currently exists that can tell you whether a method is definitively not called, and even if it is not called currently, it’s just one code change away from being called. This means that reachability should never be used as an excuse to completely ignore a vulnerability, but rather reachability of a vulnerability should be just one component of a more holistic approach to assessing risk that also takes into account the application context and severity of the vulnerability.
- sverhagen 4y ago
  I saw that Java support was still in beta. But it makes me wonder if it's going to come with a "don't use reflection" disclaimer, then...?
- DannyBee 4y ago
  Err, "no technology currently exists" is wrong, "no technology can possibly exist" to say whether something if definitively called. It's an undecidable problem in any of the top programming languages, and some of the sub problems (like aliasing) themselves are similarly statically undecidable in any meaningful programming language. You can choose between over-approximation or under-approximation.