Pim-community-dev: Bunch of dependencies have security vulnerabilities

Created on 17 Nov 2016  路  6Comments  路  Source: akeneo/pim-community-dev

Hi guys

We currently maintain two Akeneo installations, one with version v1.4.27 and another with version v1.5.12.

Today I decided to upload the composer.lock file of both these projects to https://security.sensiolabs.org/check
Both of these projects currently have 9 dependencies with security vulnerabilities.

I notice most (not all) of these old dependencies which get reported are still being used on the master branch of this project, so that's not really good I think.

Is there a possibility you could update your dependencies to a patched version and then backport these updates to v1.5 & v1.4 if possible?

Thanks!

tech-improvement wanna-contribute

Most helpful comment

Hello,

as of today this issue is not fully solved, even on the latest 1.7 release.

We are aware of theses security warnings and plan to fix all of them on the next release. More, we'll add a new check in our continuous integration process to include the security advisor checker from SensioLabs.

Thanks again for your feedback.

All 6 comments

Hello @hostep,

Thank you for reporting this. You pointed out an important topic we are aware of. We plan to fix it but I can't give you an estimate time of resolution.

If you are interested, you could contribute by opening a pull request on the master branch. We would be happy to help you by reviewing your fix and by taking care of all the tests.

All you need to know is on our contribution guide: https://docs.akeneo.com/1.6/contributing/contribution_guide.html

Regards,
Fabien

Hi Fabien

Here is some info you might find interesting, if I change these version contstraints of the composer.json file on the master branch, almost all dependencies with security vulnerabilities are fixed:

diff --git a/composer.json b/composer.json
index 2c27f5e..20477bc 100644
--- a/composer.json
+++ b/composer.json
@@ -23,16 +23,16 @@
         "php": ">=5.6.0",
         "apy/jsfv-bundle": "2.0.1",
         "ass/xmlsecurity": "1.1.1",
-        "doctrine/annotations": "1.2.6",
+        "doctrine/annotations": "1.2.*",
         "doctrine/cache": "1.6.0",
-        "doctrine/common": "2.4.2",
+        "doctrine/common": "2.4.*",
         "doctrine/data-fixtures": "1.0.0",
-        "doctrine/doctrine-bundle": "1.2.0",
+        "doctrine/doctrine-bundle": "^1.2",
         "doctrine/doctrine-fixtures-bundle": "2.2.0",
         "doctrine/doctrine-migrations-bundle": "1.1.0",
         "doctrine/migrations": "1.2.2",
-        "doctrine/orm": "2.4.7",
-        "dompdf/dompdf" : "0.6.1",
+        "doctrine/orm": "2.4.*",
+        "dompdf/dompdf" : "0.6.*",
         "escapestudios/wsse-authentication-bundle": "2.0.2",
         "friendsofsymfony/jsrouting-bundle": "1.5.4",
         "friendsofsymfony/rest-bundle": "0.12.0",
@@ -57,7 +57,7 @@
         "symfony/assetic-bundle": "2.3.1",
         "symfony/monolog-bundle": "2.10.0",
         "symfony/swiftmailer-bundle": "2.3.8",
-        "symfony/symfony": "2.7.2",
+        "symfony/symfony": "2.7.*",
         "twig/extensions": "1.2.0",
         "box/spout": "2.5.0"
     },

I mostly used the x.y.* version constraints to avoid a big jump in version numbers, even though according to semver, the preferred constraints should be ^x.y
Only for the doctrine/doctrine-bundle dependency it needed a bigger jump, because the vulnerability was only fixed in versions 1.5.2 and above.

There now is still one dependency with a security vulnerability: willdurand/js-translation-bundle. This is not a direct dependency but comes from the dependency: apy/jsfv-bundle.
That last one has been deprecated for a few years and should be replaced by: fp/jsformvalidator-bundle, which no longer has a dependency on willdurand/js-translation-bundle.
Be aware, you need to pick the correct version of fp/jsformvalidator-bundle:

If you have Symfony 2.8.* or 2.7.* - you need to use Version 1.3.* If you have Symfony 2.6.* or less - you need to use Version 1.2.*

I could create a PR for all this, but I feel like I have too little knowledge of all the ins and outs of Akeneo to be sure that none of these updates will break something...
So let me know if you want me to continue with this, or if you guys are taking this over?

Maybe it's also an idea that with the updates to these particular dependencies that all the other dependencies are getting reviewed and are being replaced with the version constraint: ^x.y so there is less chance in the future that the same security issues problem will happen again.
Most of the other big PHP projects have no fixed version constraints like you guys do. If you want to be sure that the team is working on the same versions, you could try to include the composer.lock file into git, since that's what it is for :)

Hello @hotstep,

Thank you a lot for your answer! In addition to my previous message, I gathered further information by discussing with our product team: We know that some of our vendors should be updated. In order to achieve this, we have to keep in mind the following matters:

  • If we upgrade our vendors in a patch version, it can introduce some backwards compatibility breaks with strong impacts on the current PIM projects. It has already happened in the past, so we decided to upgrade our vendors only for minor releases 1.X (not for patch versions 1.6.X).
  • One major issue for PIM users is the performance. Upgrading vendors can improve them or... damage them. We have to process many tests, especially to make sure all batch operations are as fast as before.
  • Last thing, we have to rework all our automated tests. As an example, upgrading Symfony to 2.7.17 version causes 119 scenarios to fail (we have approximately 1700 scenarios to maintain).

These tasks can be very time consuming, and we are aware that it's necessary. For now, you can suggest a pull request with an upgraded "composer.json" file on the master branch. But we only accept explicit versions (for instance 2.7.17 instead of 2.7.*). We will later perform tests and adjustments I mentioned, but I can't tell you in which upcoming PIM version it will be available.

@wakqasahmed reported a related demand: https://github.com/akeneo/pim-community-dev/issues/5300

Regards,
Fabien

Hello,

as of today this issue is not fully solved, even on the latest 1.7 release.

We are aware of theses security warnings and plan to fix all of them on the next release. More, we'll add a new check in our continuous integration process to include the security advisor checker from SensioLabs.

Thanks again for your feedback.

Hello,
I installed 2.3-alpha (akeneo/pim-community-standard) recently and the security check still shows vulnerabilities.

dompdf/dompdf (v0.6.1)
----------------------

 * CVE-2014-5013: Remote Code Execution (complement of CVE-2014-2383)
   https://github.com/dompdf/dompdf/releases/tag/v0.6.2
 * CVE-2014-5011: Information Disclosure
   https://github.com/dompdf/dompdf/releases/tag/v0.6.2
 * CVE-2014-5012: Denial Of Service Vector
   https://github.com/dompdf/dompdf/releases/tag/v0.6.2

symfony/symfony (v3.4.2)
------------------------

 * CVE-2018-11407: CVE-2018-11407: Unauthorized access on a misconfigured LDAP server when using an empty password
   https://symfony.com/cve-2018-11407
 * CVE-2018-11386: CVE-2018-11386: Denial of service when using PDOSessionHandler
   https://symfony.com/cve-2018-11386
 * CVE-2018-11406: CVE-2018-11406: CSRF Token Fixation
   https://symfony.com/cve-2018-11406
 * CVE-2018-11408: CVE-2018-11408: Open redirect vulnerability on security handlers
   https://symfony.com/cve-2018-11408
 * CVE-2018-11385: CVE-2018-11385: Session Fixation Issue for Guard Authentication
   https://symfony.com/cve-2018-11385

When will this be fixed? (for 2.3) Why not allow at least minor updates/bugfix releases via "~3.4.*" in composer.json?

Hello!

I close this issue resolve, feel free to reopen it if you still have an error.

Regards,

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FabienSalles picture FabienSalles  路  5Comments

Piotr-Borek picture Piotr-Borek  路  5Comments

wakqasahmed picture wakqasahmed  路  4Comments

paulchubatyy picture paulchubatyy  路  5Comments

henryktews picture henryktews  路  4Comments