support for other languages

87 views
Skip to first unread message

Lukas Kahwe Smith

unread,
Sep 28, 2015, 4:14:29 AM9/28/15
to dependen...@googlegroups.com
Aloha,

I noticed that this tool supports more languages than “just” Java:
"Currently Java, .NET, Ruby, Node.js, and Python projects are supported; additionally, limited support for C/C++ projects is available for projects using CMake or autoconf."

I am currently looking into this topic for PHP specifically but also for Node.js/Bower/Python/Ruby for the web agency where I work (liip.ch). I have also launched an initiative for the PHP world with the goal of providing more structured security reporting in order to not have to rely on parsing CVEs. Also the idea is to give OSS projects a bit more control about the workflow by letting them manage the reports themselves (though ideally they would also still use CVEs). There is a summary of the initiative in this blog post http://blog.phpdeveloper.org/2015/05/22/php-security-psr-9psr-10/

Can someone elaborate a bit about the support for other languages?

Also how realistic would it be to improve the CVE system to at least optionally support a more structured format?

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org



signature.asc

Visser, Dale

unread,
Sep 28, 2015, 10:35:28 AM9/28/15
to Lukas Kahwe Smith, dependen...@googlegroups.com
Lukas:

I have added much of the non-Java/.NET analyzer code, as part of a sponsored project at my workplace. Our goal was simply to take Dependency-Check and extend it to make even more useful than it already was, and a major area of that was adding analyzer codes for other programming languages, particularly ones that already had established popular package management. Python (PyPI) was added first, followed by the autoconf and CMake analyzers. Node.js (npm) and Ruby (Gems/Bundler) were added last, since they already have similar ongoing security efforts with associated tools, but it was still felt that having Dependency-Check also be able to find things is a desirable thing. (See http://jeremylong.github.io/DependencyCheck/related.html for links to the Ruby and Node.js security efforts and tools).

I couldn't speak to improving the CVE schema. It's gone through one revision already, and I imagine NIST would be conservative about amending it further. That said, there probably is a process in place for future incarnations of CVE. I just have never looked into it. What kind of metadata do you think it is currently missing?

Best regards,
Dale
--
You received this message because you are subscribed to the Google Groups "Dependency Check" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dependency-che...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Lukas Kahwe Smith

unread,
Sep 28, 2015, 11:08:10 AM9/28/15
to Visser, Dale, dependen...@googlegroups.com

> On 28 Sep 2015, at 16:35, Visser, Dale <dvi...@ida.org> wrote:
>
> Lukas:
>
> I have added much of the non-Java/.NET analyzer code, as part of a sponsored project at my workplace. Our goal was simply to take Dependency-Check and extend it to make even more useful than it already was, and a major area of that was adding analyzer codes for other programming languages, particularly ones that already had established popular package management. Python (PyPI) was added first, followed by the autoconf and CMake analyzers. Node.js (npm) and Ruby (Gems/Bundler) were added last, since they already have similar ongoing security efforts with associated tools, but it was still felt that having Dependency-Check also be able to find things is a desirable thing. (See http://jeremylong.github.io/DependencyCheck/related.html for links to the Ruby and Node.js security efforts and tools).

So you scan for relevant dependency information in package.json, requirements.txt etc?

Any plans to add PHP support?

> I couldn't speak to improving the CVE schema. It's gone through one revision already, and I imagine NIST would be conservative about amending it further. That said, there probably is a process in place for future incarnations of CVE. I just have never looked into it. What kind of metadata do you think it is currently missing?

Mostly the issue is that the data is too unstructured, ie. I would prefer to have clearly defined fields for affected version, fixed version as well as a mapping to popular package managers (ie. PIP, NPM, Gem, Composer etc.) to enable automated security checks with less guess work.
signature.asc

Visser, Dale

unread,
Sep 28, 2015, 11:23:26 AM9/28/15
to Lukas Kahwe Smith, dependen...@googlegroups.com
Lukas:

http://jeremylong.github.io/DependencyCheck/analyzers/index.html goes into a good amount of detail as to exactly what artifacts get examined by the various Dependency-Check analyzers.

Unfortunately, the funding where I work is limited in the near-term future, preventing me from spending time on a PHP analyzer, which *is* something we have discussed doing, but that so far, I haven't spent any time looking into.

Unlike with Python, C/C++, and Ruby (and Java and .NET), my experience with PHP is virtually zero, limited to minor edits of a Drupal add-on about a year ago. I haven't looked over your PSRs in detail, but I bet it would not be very difficult for you to study the existing analyzer codes in Dependency-Check (https://github.com/jeremylong/DependencyCheck/tree/master/dependency-check-core/src/main/java/org/owasp/dependencycheck/analyzer) and figure out an approach for PHP. You just need files that can serve as artifacts to analyze, that can provide project, vendor and version information for installed/in-use packages.

I agree that having CVE aware of package management systems (both dev/language-specific and OS platform, such as APT/YUM/DNF) could be a nice addition.

Best regards,
Dale

-----Original Message-----

Visser, Dale

unread,
Sep 28, 2015, 11:29:37 AM9/28/15
to Visser, Dale, Lukas Kahwe Smith, dependen...@googlegroups.com
Lukas:

I feel very silly. I didn’t examine the latest release very carefully. There is a PHP analyzer included (http://jeremylong.github.io/DependencyCheck/analyzers/composer-lock.html), and it is even mentioned on the GitHub pages main page (http://jeremylong.github.io/DependencyCheck/index.html).

Lukas Kahwe Smith

unread,
Sep 28, 2015, 11:35:12 AM9/28/15
to Visser, Dale, dependen...@googlegroups.com

> On 28 Sep 2015, at 17:29, Visser, Dale <dvi...@ida.org> wrote:
>
> Lukas:
>
> I feel very silly. I didn’t examine the latest release very carefully. There is a PHP analyzer included (http://jeremylong.github.io/DependencyCheck/analyzers/composer-lock.html), and it is even mentioned on the GitHub pages main page (http://jeremylong.github.io/DependencyCheck/index.html).

Awesome but now I feel even more silly than you! ..
signature.asc

Bernd Eckenfels

unread,
Sep 28, 2015, 11:47:59 AM9/28/15
to Visser, Dale, Lukas Kahwe Smith, dependen...@googlegroups.com
Hello,

Am Mon, 28 Sep 2015 11:23:22 -0400
schrieb "Visser, Dale" <dvi...@ida.org>:
> I agree that having CVE aware of package management systems (both
> dev/language-specific and OS platform, such as APT/YUM/DNF) could be
> a nice addition.

I was proposing to map Maven Central coordinates to CPE identifiers
(similiar might work for other languages, too). This would allow to
specify very clear artifact identifiers without changing the CVE
schema. However nobody was interested to follow up on that. I might
propose it on oss-security again, but currently I am not too familiar
with its subculture. It does require that CVE moerators or vadors are
willing to specify those.

http://www.evernote.com/l/AAPiy3a7TgdLQqormZ2Wgf9QXYHBp7wlqaI/

Gruss
Bernd

Lukas Kahwe Smith

unread,
Sep 29, 2015, 2:28:15 AM9/29/15
to Bernd Eckenfels, Visser, Dale, dependen...@googlegroups.com
yeah that would provide a lot of value.

I see two approaches:
1) build up an external DB that does this mapping
2) advocate people to use a more specific format in the free text part of their CVEs that include a clear and easily parseable definition of affected and fixed versions as well as known packages in which the code is contained.
signature.asc

Lukas Kahwe Smith

unread,
Sep 29, 2015, 2:32:04 AM9/29/15
to Visser, Dale, dependen...@googlegroups.com

> On 28 Sep 2015, at 17:35, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:
>
>
>> On 28 Sep 2015, at 17:29, Visser, Dale <dvi...@ida.org> wrote:
>>
>> Lukas:
>>
>> I feel very silly. I didn’t examine the latest release very carefully. There is a PHP analyzer included (http://jeremylong.github.io/DependencyCheck/analyzers/composer-lock.html), and it is even mentioned on the GitHub pages main page (http://jeremylong.github.io/DependencyCheck/index.html).
>
> Awesome but now I feel even more silly than you! ..

I ran this checker on some code with known vulnerabilities:
https://github.com/symfony-cmf/standard-edition/blob/9f1125f34a28214d3f7c9e1e2d5f7ec310a3986c/composer.lock

With the dependency check it found me an issue with jquery:
CVE-2007-2379 suppress

Severity: Medium
CVSS Score: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)

The jQuery framework exchanges data using JavaScript Object Notation (JSON) without an associated protection scheme, which allows remote attackers to obtain the data via a web page that retrieves the data through a URL in the SRC attribute of a SCRIPT element and captures the data using other JavaScript code, aka "JavaScript Hijacking."

• MISC - http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
• OSVDB - 43320
Vulnerable Software & Versions:

• cpe:/a:jquery:jquery

With the sensiolabs checker, where they manually maintain a DB with CVEs to composer package mappings manually for some popular PHP projects I instead got this:

• doctrine/annotations (v1.2.4)

• Security Misconfiguration Vulnerability in various Doctrine projects — CVE-2015-5723
• doctrine/cache (v1.4.1)

• Security Misconfiguration Vulnerability in various Doctrine projects — CVE-2015-5723
• doctrine/common (v2.5.0)

• Security Misconfiguration Vulnerability in various Doctrine projects — CVE-2015-5723
• doctrine/doctrine-bundle (v1.5.0)

• Security Misconfiguration Vulnerability in various Doctrine projects — CVE-2015-5723
• doctrine/orm (v2.4.7)

• Security Misconfiguration Vulnerability in various Doctrine projects — CVE-2015-5723
• twig/twig (v1.18.1)

• Remote code execution in templates
signature.asc

Jeremy Long

unread,
Oct 3, 2015, 6:52:35 AM10/3/15
to Dependency Check, dvi...@ida.org
With regard to CVE-2015-5723 - this is still a candidate record and the data is not actually available in the NVD (yet). Once this record has been published in the NVD I would expect it to be identified. However, this does highlight one of the issues with only relying on the NVD - other hand curated vulnerability databases contain more vulnerabilities then are in the NVD. Risk Based Security's VulnDB is one example. I know other vendors in this space have gone as far as monitoring the commit logs of projects to identify when vulnerabilities were fixed (but not necassarily announced). However, all of these databases are commercial. If someone had a license to other vuln databases it wouldn't be hard to add an analyzer to dependency-check to obtain vulnerability information from the database to include in the report.

Best Regards,

Jeremy Long

On Tuesday, September 29, 2015 at 2:32:04 AM UTC-4, Lukas Kahwe Smith wrote:

> On 28 Sep 2015, at 17:35, Lukas Kahwe Smith wrote:
Reply all
Reply to author
Forward
0 new messages