friendsofphp / security-advisories Goto Github PK
View Code? Open in Web Editor NEWA database of PHP security advisories
Home Page: https://github.com/fabpot/local-php-security-checker
License: The Unlicense
A database of PHP security advisories
Home Page: https://github.com/fabpot/local-php-security-checker
License: The Unlicense
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?
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?
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!
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?
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
.
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?
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.
It would be nice if the database were also available via an RSS/Atom feed.
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
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 :
Thanks
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?
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.
Could you please add drupal/core ? It's a subtree split of drupal/drupal so it should be the same.
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?
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?
@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.
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 thinking that it might be useful to support a severity ranking. However, this can open a can of worms.
Pros:
Cons:
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.
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
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?
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?
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 ?
An error occurred: Could not resolve host: security.sensiolabs.org
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?
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.
I think it would be a good idea to draw up a document that can help people decide what a Security Advisory is.
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?
The Package URL (purl) specification defines a "mostly" universal way of describing components regardless of language or ecosystem. Package URL has been adopted by:
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.
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
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
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 ?
This would help ensuring that advisories submitted to the repo have the right format
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
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 :)
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
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:
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)
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.
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
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
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
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.
For some reason, some of my lock files produce an error 400.
See scrutinizer-ci/scrutinizer#95.
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
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".
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.
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:
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.