friendsofphp / security-advisories Goto Github PK

I know this is not the right place for this but I cannot find any repo to report this to and I think you guys might be one and the same or at least know the right people to tell :)

The word "Advistories" is spelled wrong in the dropdown on security.sensiolabs.org:

// @fabpot

https://github.com/smichaelsen/no-insecure-typo3-extensions

I've built an equivalent of roave/security-advisories for TYPO3 extensions, which is automatically updated based on the extension ratings of the TYPO3 security team.

Would it be of interest to incorporate that list into this project? Maybe my script could automatically open a PR when the TYPO3 security team publishes new advisories on extensions.

Thinking that this might be a first step to drastically simplifying the process of managing Drupal site vulnerabilities (libs and modules).

Context: https://drupal.org/node/2088713#comment-7866849

Correct me if I'm wrong, but I suppose this is technically only sensible for versions of Drupal that have a composer.json, so only advisories from D8 forward would make sense to keep here.

cc: @greggles @webchickenator

Cross-site scripting (XSS) vulnerability in Silex before 2.0.0 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.

https://nvd.nist.gov/vuln/detail/CVE-2014-1971

I think this isn't added yet

Hello!

Just wondered if having advisories for Drupal contributed modules in here would be possible/wanted?

They generally do not have a CVE, and of course they would have to be maintained by someone. My thinking was to create a script that parses the advisories available, and programatically create PRs for the ones that were missing. This would help to keep it up to date as well, I could run the script periodically.

Thanks for this package btw, it is very useful!

Currently, there are vulnerabilities that may affect a large number of products, such as the monolog library. Most PHP packages integrate into composer, but this project does not limit it's scope to just those packages that do integrate with composer. It is thus difficult to determine what software versions a package might affect.

One way to mitigate this is to extend the schema to allow "tags" on data. An example is below

title:     Remote Code Execution in Qquoteadv/controllers/DownloadController.php
link:      https://cart2quote.zendesk.com/hc/en-us/articles/115000616303--FIXED-Security-Vulnerability-in-downloadCustomOptionAction
# This section is new, and allows grouping vulns along arbitrary criteria as they develop
tags:
  - magento
cve:       ~
branches:
    4.x:
        time:     2017-02-01 10:45:00
        versions: ['>=4.1.6', '<=4.4.5']
    5.x:
        time:     2017-02-01 10:45:00
        versions:  ['>=5.0.0', '<5.4.4']
reference: composer://cart2quote/module-quotation
composer-repository: false

This allows users within a community to tag vulns with words that have meaning within that community to make the content more consumable.

Tags would have styleguide contentions (such as all lower case, separated by a "-" character) but not a limit in their content. There would be no limits on the number of tags.

Other such use cases would be:

• Tagging vulns that exist within some other tracking system, such as CVE
• Tagging vulns of a particular type, such as XSS, RCE, SQL-Injection

I would get around to doing this work at some point. "Managing Expectations" though, it'd either be within the next week or I'd close this issue as "I'm not going to do this" (I have a short attention span)

After addtion of https://github.com/FriendsOfPHP/security-advisories/blob/master/ezsystems/ezplatform/2018-11-21-1.yaml by @glye, many users reports being unable to install latests or update to versions due to our usage of roave/security-advisories. In these cases composer is unable to determine version of root package so it gives it a version of v1.0.0 and composer stops with package conflict.

We have changed roave/security-advisories in favour of sensiolabs/security-checker in ezsystems/ezplatform@4e94c95, however that won't help users already with a install. And afaik sensiolabs/security-checker does not check root package anyway.

As roave/security-advisories auto generates their rules from the source here and thus won't accept changes, I'm wondering if we can add a syntex match for 1.0.x and say =<1.0.0 is valid to avoid it, with some inline comment here about why. Alternative is that we remove it for this package.

Any suggestions/conventions?

Hello,

in https://github.com/FriendsOfPHP/security-advisories/blob/master/phpxmlrpc/extras/2017-10-29.yaml#L7, there might be a typo in 'versions' (line 6): '[<0.6.1]' instead of '[<6.0.1]' ?

bests

Drupal core - Moderately critical - Multiple Vulnerabilities - SA-CORE-2019-005 & Drupal core - Moderately critical - Cross Site Scripting - SA-CORE-2019-006

https://www.drupal.org/sa-core-2019-005
https://www.drupal.org/sa-core-2019-006

Pull request: #388

The Drupal module Search API Solr Search gets flagged by the security checker, because of the following issue: https://www.drupal.org/sa-contrib-2018-065. From what I can gather this issue only applies to Drupal 7 installations (correct me if I'm wrong here).

I'm running Drupal 8 with the latest 8.x-1.x (1.2.0) version of the Search APi Solr Search module. I would expect the security checker not to flag this installation as vulnerable.

This could be fixed by adjusting sa-contrib-2018-065.yaml to only apply to Drupal 7. In this case such could be achieved by specifying the branch containing the security issue, which would be 7.x-1.x in this case. But from what I can gather from #366 (comment) this won't be possible.

What would be a solution to this issue?

I'd like to integrate checking against this database as part of our CI system. How many requests per some timeframe is it appropriate to make against this service?

Alternatively is it possible to self-host the service or maybe a tool that can just run against a git checkout of this repository?

And, thanks for maintaining this :)

Don't have time just this second to do a PR but I can probably do so this week, just a placeholder issue for the moment that https://magento.com/security/patches/magento-2.3.1-2.2.8-and-2.1.17-security-update needs inclusion. I don't see any CVEs in that document nor do I know if there is a usual channel though which these get included here outside of random contribution, but they have pretty significant security scores.

Hey guys,

any chance to supply Wordpress security advisories?

Or is there no way, as the official WP repo (https://api.github.com/repos/wordpress/wordpress) does not provide composer support and one has to rely on unofficial sources like https://github.com/roots/wordpress or https://github.com/johnpbloch/wordpress?

Thanks for any thoughts on this.

Cheers

Consider updating the section "Checking for Vulnerabilities" (file README.md) to replace the bad link :
http://security.sensiolabs.org/check_lock with https://security.sensiolabs.org/check_lock

The protocol has changed from http to https.

simplesamlphp/simplesamlphp/2019-11-19.yaml appears to report anything less than simplesamlphp/simplesamlphp 1.18.0 as insecure. simplesamlphp/simplesamlphp v1.17.7 had a security issue which was addressed in https://github.com/simplesamlphp/simplesamlphp/releases/tag/v1.17.8.

Am I missing another security issue with v17.7.x, or should v1.17.8 be acceptable?

When components are EOL, especially old Symfony versions, do these get a security warning or something? I just checked a 2.2 project and it doesn't mention something like "this version is EOL and will not get security updates".

I just used http://www.yamllint.com/ to double check this file here and it says that's it's not valid. I'm getting this error with multiple yaml files from this repository. Any ideas?

Is it possible to check security for running PHP from security:check command?

If yes: Just wondering what folder structure it should be. I have no idea that what exactly Composer name of PHP is. Please advice.

anyways, PHP's source code in the github is https://github.com/php/php-src

From what I can see, the repository contains no information about security advisories for PHP versions or PHP extensions.

While I know the ecosystem is hugely messed up here (because of linux LTS distros that just "invent" a new versioning system for backported security patches), it would still be a good idea to just report any PHP release that does reference a CVE.

I think this would hugely improve the push for deploying latest stable releases.

Thoughts?

Since #109, we are validating the composer reference for mistakes, by checking the package against packagist. This makes it impossible to register a package available on custom composer repositories (see #126 for typo3 extensions, but it could also affect other communities which only start their migration to a composer ecosystem and keep things outside Packagist).

I suggest to add an optional composer-repository setting in the advisory, which would allow to validate the package against a different repository (omitting it would validate against Packagist). What do you think ?

I'd like to encourage some of my colleges to contribute to this repository, so we can benefit from better checking and contribute back to the larger community. But one of them pointed out that the licensing isn't clear. Could it be released under CC-BY, or public domain, so the legal status of any reuse would be clear?

This would help ensuring that advisories submitted to the repo have the right format

There's some sort of Magento security release happening shortly:

https://twitter.com/sherrierohde/status/826956249929437184

This issue is a stub to track is, so I remember to submit a PR about it when it's released. Seems likely to the recent Zend vulnerability, published here:

https://magento.com/security/news/new-zend-framework-1-security-vulnerability

@fabpot thankfully merged my pull request, but the mentioned issue does not appear in the database behind https://security.sensiolabs.org/, so scanned lock-files are getting an "OK".

//edit:
While having this issue opened, I just realized that I'm in the wrong project, so I will move it.

I opened an issue here FriendsOfSymfony/FOSUserBundle#2787

Can you reproduce that ?
Thanks for reply.

Currently, merging new advisories in the repo involves manual work from @fabpot. This could delay merging if he is not available (he can take vacations for instance).

I suggest implementing a system when multiple people can approve advisories, and then have a bot merging them automatically if the PR is approved and CI is green.

Note that this also implies that https://security.sensiolabs.org/ must be updated automatically with the new advisory. I have no idea how the update is handled currently.

What do you think @fabpot ?

Not that it's so relevant anymore, but from the looks of it seems the version rule on random_compat might be a bit too strict, as the underlying lack of randomness with openssl issue seems to have been fixed in later version of PHP:
php/php-src@0e2447c

I think it would be a good idea to draw up a document that can help people decide what a Security Advisory is.

Any reason the 1.x isn't included?

In security-advisories/doctrine/dbal/2011-09-25.yaml

title: SQL injection possibility
link: https://www.doctrine-project.org/blog/dbal-security-2011-1.html
cve: ~
branches:
2.0.x:
time: 2011-08-29 22:36:11
versions: ['>=2.0.0', '<2.0.8']
2.1.x:
time: 2011-08-29 22:36:11
versions: ['>=2.1.0', '<2.1.2']
reference: composer://doctrine/dbal

But in NVD the description says this:

Multiple SQL injection vulnerabilities in the Doctrine\DBAL\Platforms\AbstractPlatform::modifyLimitQuery function in Doctrine 1.x before 1.2.4 and 2.x before 2.0.3 allow remote attackers to execute arbitrary SQL commands via the (1) limit or (2) offset field.

Hit it by accident, but strings such as versions: [>=3.0.0,<3.2.1] don't seem to be valid Yaml.

Here is an example trace of how I hit this:

PHP Fatal error:  Uncaught Symfony\Component\Yaml\Exception\ParseException: The reserved indicator ">" cannot start a plain scalar; you need to quote the scalar at line 7 (near "versions: [>=3.0.0,<3.2.1]"). in vendor/symfony/yaml/Inline.php:241
Stack trace:
#0 vendor/symfony/yaml/Inline.php(317): Symfony\Component\Yaml\Inline::parseScalar('[>=3.0.0,<3.2.1...', Array, Array, 8, true, Array)
#1 vendor/symfony/yaml/Inline.php(63): Symfony\Component\Yaml\Inline::parseSequence('[>=3.0.0,<3.2.1...', 8, Array)
#2 vendor/symfony/yaml/Parser.php(479): Symfony\Component\Yaml\Inline::parse('[>=3.0.0,<3.2.1...', true, false, false, Array)

I just uploaded a lock file containing a Symfony 2.3.x version from before the security fix (i.e. an older commit of the branch version) to check it. The website told me that there was no known security issue, while I'm sure there is one (this lock file is before the update to a Symfony commit containing the fix). So I see 2 possible explanations:

• the website is using an outdated version of the database when doing the check (it seems unlikely because browsing the database shows this CVE but I don't know how this is implemented so I'm not sure)
• there is a bug in the logic matching dev versions

For some reason, some of my lock files produce an error 400.
See scrutinizer-ci/scrutinizer#95.

With Drupal core 8.5.10 I get this:

Symfony Security Check Report
=============================
1 packages have known vulnerabilities.

drupal/core (8.5.10)
 * [CVE-2019-6338][]: Critical - Third Party Libraries
 * [CVE-2019-6339][]: Critical - Arbitrary PHP code execution

[CVE-2019-6338]: https://www.drupal.org/sa-core-2019-001
[CVE-2019-6339]: https://www.drupal.org/sa-core-2019-002

This is not correct - that is for Drupal core 8.5.8 or earlier.

Hi there,
It seems like https://github.com/Roave/SecurityAdvisories/ is using information from this repo to check security issues. I can't install SwiftMailer v6.1.3 because there is only references to v4 and v5 here.
Can you help me out to fix this? I tried to make a PR on Roave/SecurityAdvisories#50 (review) but it seems not to be the right place. Should I do a PR with the v6 version but I don't have any security link about it?
Have a nice day.

Hello,

I saw 4 vulnerabilities for SF 3.4 today, but none of them pushed up in the https://security.symfony.com/ , I have 2 questions :

• Do I need to add all components all present in symfony/symfony in my composer.json ? (for example the Cache component is include in the repository symfony/symfony in sf 3.4)
• OR I need to create a pull request in this repository to adding the CVEs in the advisories symfony/symfony ?

Thanks

The Package URL (purl) specification defines a "mostly" universal way of describing components regardless of language or ecosystem. Package URL has been adopted by:

• OWASP Dependency-Track
• OWASP Dependency-Check (in progress)
• CycloneDX
• SPDX (in progress)
• SWID (in progress)
• Sonatype OSSIndex

And is being considered by many other vendors as well as NIST.

Package URL support would simply add an additional field to existing advisories. For example:

title:     Cross-Site Scripting
link:      https://github.com/erusev/parsedown/pull/495
cve:       CVE-2018-1000162
branches:
    1.x:
        time:     ~
        versions: ['<1.7.0']
reference: composer://erusev/parsedown
purl: pkg:composer/erusev/parsedown

Ideally, Package URL would also be supported by security.symfony.com as an alternative to supplying composer.lock. For organizations leveraging BOMs (CycloneDX or SPDX for example) it would be possible for them to simply supply a list of Package URLs and retrieve vulnerability information (similar to OSSIndex). For example, a request containing pkg:composer/erusev/[email protected] would return the above vulnerability.

Supporting Package URL in both advisories as well as the Symfony Security service would provide new opportunities for integration - OWASP Dependency-Track for example.

Maybe, you want to add a description field for security issues, so users can get more info about our issues, and maybe to be interesting a gravity field to determine how important it is.

example

title:     Security fixes related to the way XML is handled
link:      http://symfony.com/blog/security-release-symfony-2-0-17-released
cve:       ~
branches:
    2.0.x:
        time:     2012-08-27 19:17:44
        versions: [>=2.0.0,<2.0.17]
reference: composer://symfony/validator
description: a malicious user ... bla, bla ...
gravity: low

The contribution guidelines mention that time entries should be as accurate as possible, but which timezone is not mentioned.
Should it be the native timezone of the (merge) commit or UTC?

Using the testfile drupal/drupal/CVE-2019-6342.yaml

With content:

title: Critical - Access bypass
link: https://www.drupal.org/sa-core-2019-008
cve: CVE-2019-6342
branches:
    8.7.x:
        time:     2019-07-16 16:24:00
        versions: ['8.7.4']
reference: composer://drupal/drupal

Results in a failing validation:
Run php.exe -d memory_limit=-1 C:\Users\marco\projects\security-advisories\validator.php

Output:

...
+----------------------------------+------------------------------------------------------------+
| File                             | Issues                                                     |
+----------------------------------+------------------------------------------------------------+
| drupal\drupal\CVE-2019-6342.yaml | Version constraint "8.7.4" is not in an acceptable format. |
|                                  | "versions" must have an upper bound for branch "8.7.x".    |
+----------------------------------+------------------------------------------------------------+`
...

IMHO $isAcceptableVersionConstraint should allow this kind of version constraint.

Opinions?

An error occurred: Could not resolve host: security.sensiolabs.org

How are the branch names related to the version strings in composer? Here for example the branch 3.0 has a versions array with [>=2.0.0,<3.0.1]. I thought the versions array has to fit to the branch name. If so the array should be [>=3.0.0,<3.0.1]. Right?

Which versions on Packagist/Composer are now affected from this security vulnerability? 3.0.0 only? Or everything bigger 2.0.0 up to and including 3.0.0?

Hi, me again,

so now we have directly a case, where the first primary source describes a bigger affected version area then a review from another source I would also call as primary.

Cotya/magento-security-advisories#1

So I think another optional list for linking to reviews would be wise, while I would not change the affected range yet, if not at least two reviews come to the same result.

Do you think this makes sense?

We have a number of composer.lock files that we send to the api, many work just fine but there are a few, like that attached, that will show no issues via the SecurityChecker class but if I use curl or upload via the site we get the expected failed results.

Just curious if there is something wrong with the file or client that would cause this?

Since I can not attach the files I will link via dropbox
https://www.dropbox.com/s/oiyfzpavjx8qc73/example.json?dl=0

The test I run to show all of this is here:

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\WithFaker;
use Illuminate\Foundation\Testing\RefreshDatabase;
use GuzzleHttp\Client;
use GuzzleHttp\Psr7\Response;
use SensioLabs\Security\Crawler;
use SensioLabs\Security\SecurityChecker;

class CustomSensioClientTest extends TestCase
{

    public function setUp()
    {
        parent::setUp();
        //$this->markTestSkipped("Working on figuring out a glitch in the API");
    }

    public function testCurlExec()
    {
        $lock = base_path("tests/fixtures/example.json");
        //$lock = base_path("tests/fixtures/known_failing.json");
        $command = "curl -H \"Accept: application/json\" https://security.sensiolabs.org/check_lock -F lock=@{$lock}";
        exec($command, $output, $status);
        dd($status, $command, $output);
    }

    public function testTheirCleint()
    {
        //$lock = base_path("tests/fixtures/known_failing.json");
        $lock = base_path("tests/fixtures/example.json");
        $crawler = new Crawler();
        $checker = new SecurityChecker($crawler);
        $results = $checker->check($lock);
        dd("here", $results);
    }


    public function testTalkingToAPI()
    {
        $lock = base_path("tests/fixtures/example.json");
        //$lock = base_path("tests/fixtures/known_failing.json");
        /** @var Client $client */
        $client = new Client([
            'base_uri' => "https://security.symfony.com",
            'timeout' => 20,
            'allow_redirects' => true,
        ]);
        $options['headers'] = ["Accept" => "application/json"];
        //$options['headers'][] = ["Content-Type" => "multipart/form-data"];
        $options['multipart'] = [
            [
                'name' => 'lock',
                'contents' => fopen($lock, 'r')
            ]

        ];

        /** @var Response $results */
        $results = $client->request("POST", "/check_lock", $options);

        dd(json_decode($results->getBody(), true), $results->getStatusCode(), $lock);

    }
}

Again the curl one giving me the results I expected.

At the moment, this package bakes-in YML files comprising official security advisories for SilverStripe (and a bunch of other applications). This seems a pretty high-maintenance procedure for a kind of data that is by its very nature, constantly evolving.

Is there a reason why the package doesn't make use of web-APIs and RSS feeds where available for each of the supported packages? The SilverStripe one is here: https://www.silverstripe.org/download/security-releases/rss

It would be nice if the database were also available via an RSS/Atom feed.

Hi,
I want to start something similar for the Magento ecosystem. Now we have here not such a composer centric ecosystem which results in projects available over different sources. Some of them even with multiple composer Identifiers.

As other smaller ecosystems may have similar problems, I would like to solve it here to keep a central standard for the format.

My ideas would be to introduce an optional Alias argument, or allowing of multiple reference entries.

How do you see this?

Could you please add drupal/core ? It's a subtree split of drupal/drupal so it should be the same.

I thinking that it might be useful to support a severity ranking. However, this can open a can of worms.

Pros:

• Users can make risk-based decisions on what to use and what to prioritize; not all security vulnerabilities are the same severity
• In the absence of a CVE, this is an additional metric for users to consider

Cons:

• It can start getting subjective if the submitter starts picking rankings

Use case:
If a module has Remote Code Execution, SQLi, XXE, or something equally critical, I as a project owner want to know that the issue is serious and I should prioritize moving off of the old version sooner than something that exposes the version of PHP I'm running, for example. Ideally of course are projects that are decoupled from reliance on bug fix versions, but the reality is that not everybody versions their software correctly, and not everybody decouples their application from minor versions like they should. So allowing people to make decisions I think is a positive direction.

We have a few packages in Drupal that are unsupported because of security issues(e.g. https://www.drupal.org/sa-contrib-2019-006). Is there a way to not allow to install (any version) them?