While it saddens me to report a vulnerability that prevents installation of ALL Magento CE versions, that's what happens with 0-day disclosures. I don't agree with what was done with the original disclosure, I'm just here to add it to the database.

The file provided here will have to be updated once the Magento team has released a replacement for the current crypto.

Ref: http://www.openwall.com/lists/oss-security/2016/07/19/3

Copying disclosure text for reference:

Date: Tue, 19 Jul 2016 00:56:58 -0400
From: Scott Arciszewski <[email protected]>
To: [email protected], [email protected]
Subject: Ruining the Magic of Magento's Encryption Library

Hello mcrypt, my old friend
I've come to exploit you again
Because a version slowly rotting
Is well-deserved for a boycotting
And the S-box that was planted in its GOST
Still remains
Within the sound of silence

~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~ 8< ~

Let's talk about Magento.

The Wikipedia page for Magento begins, "Magento is an open-source
e-commerce platform written in PHP." This bears emphasis: e-commerce
platform.

When I hear e-commerce, I think "financial information". I think "credit
card numbers" and "probably PCI-DSS violations should anything be obviously
stupid".

Let's look at how Magento implements cryptography, with a series of
exhibits followed by an explanation of what's happening and why it's
dangerous:

  A.
https://github.com/magento/magento2/blob/6ea7d2d85cded3fa0fbcf4e7aa0dcd4edbf568a6/lib/internal/Magento/Framework/Encryption/Encryptor.php#L268-L320
  B.
https://github.com/magento/magento2/blob/6ea7d2d85cded3fa0fbcf4e7aa0dcd4edbf568a6/lib/internal/Magento/Framework/Encryption/Encryptor.php#L390-L399
  C.
https://github.com/magento/magento2/blob/6ea7d2d85cded3fa0fbcf4e7aa0dcd4edbf568a6/lib/internal/Magento/Framework/Encryption/Crypt.php#L63-L77

D.
https://github.com/magento/magento2/blob/6ea7d2d85cded3fa0fbcf4e7aa0dcd4edbf568a6/lib/internal/Magento/Framework/Encryption/Encryptor.php#L170

If you looked at the code, I promise this is every bit as bad as it looks
at a glance.

EXHIBIT A
=========

Magento's decryption expects up to 4 strings concatenated by a : character.
Depending on the number of pieces, it assumes a totally different setup:

1 piece: Blowfish, in ECB mode!
2 or 3 pieces: Probably blowfish, but maybe AES or Rijndael-256, depending
on the integer supplied by the attacker.
4 pieces: We finally get an initialization vector, which means CBC mode can
be used.

At no point do they authenticate _anything_, so no matter what:

- You get to control which branch is selected by breaking pieces off the
attacker-chosen message.
- You get to choose the ciphertext that the attempted decryption is
performed upon.

EXHIBIT B
=========

If you thought the ability to be encrypted with AES was a saving grace, too
bad. They hard-code your choice to ECB mode.

The only way you can get CBC mode (which, again, is unauthenticated) is to
use the non-standard Rijndael256 cipher.

EXHIBIT C
=========

If you thought it couldn't possibly get any worse, Magento's encryption
library will either:

- Give you an IV consisting entirely of NULL bytes.
- Generate it, using rand(), on a 62-character keyspace.

(Y'know, because it's not XORed with the plaintext in CBC mode and biases
aren't a concern or anything.)

EXHIBIT D
=========

Yes, that is how Magento hashes passwords. Which is weird: They go out of
their way to compare strings in constant-time, but

PUTTING IT ALL TOGETHER
=======================

An attacker has a great deal of control over the ciphertext, and
incidentally which cipher mode is used by the decryption routine.
Nothing is authenticated. At all.
ECB mode everywhere.
When CBC mode is actually used, it's used with a laughably weak IV and a
non-standard cipher. Also, unauthenticated.

Magento, one of the largest open source e-commerce platforms, ships a
broken cryptography library that clueless developers are probably using to
encrypt your credit card information for their client's customers.

Given the prevalence of ECB mode, and the weak IV used in CBC mode, you
should assume anything you encrypted with Magento's encryption library is
both:

- Decryptable, if an attacker can alter plaintexts or ciphertexts and study
the output of either operation, without the key
- Forgeable

This cryptography implementation is very irresponsible and, because
cryptography is involved, warrants immediate full disclosure so everyone
can cease to use their broken crypto as soon as possible.

If you need a remediation strategy, I've got you covered:
https://paragonie.com/blog/2015/11/choosing-right-cryptography-library-for-your-php-project-guide

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

https://github.com/paragonie/random_compat/issues/96

TL;DR - In environments where the PHP process is forked, openssl_random_psuedo_bytes can generate the same stream of values.

There are other security issues that also caused @paragonie-scott concern.

Also I'm not sure what to do with the branch name, the vulnerability spans more than one branch and can best be described as "all versions 1.*? (edit - as @stof mentioned it's actually all versions <2 )

Just released a security checker package that is similar to the Sensiolabs security checker (now deprecated). I'm adding this to the Readme so that people are aware of this and can use it.

Benefits / differentiation of this package include:

• Can be pulled in with Composer.
• Exposes a PHP API.
• Licensed under the MIT license.

The package is backed with tests and implements HTTP caching while pulling in the Advisories database from Github. 🚀

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 https://github.com/FriendsOfPHP/security-advisories/issues/366#issuecomment-466175158 this won't be possible.

What would be a solution to this issue?

Parsedown has had multiple XSS issues for a long time when using its ->setMarkupEscaped(true) option (e.g. being able to break out of the AST representation by adding quotes in link ~~addresses~~ titles). All of these issues are fixed in https://github.com/erusev/parsedown/pull/495, but this has remained open for almost a year now, and there appears to be no interest in merging it any time soon from the repository owner (I digress).

There might be some debate as to whether XSS issues in a markdown parser can actually be considered security issues (since markdown itself permits HTML). To address this I would present the following:

• The Parsedown Wiki has for a long time stated that HTML can be escaped using the ->setMarkupEscaped(true) configuration:

    echo Parsedown::instance()
       ->setMarkupEscaped(true) # escapes markup (HTML)
       ->text("<div><strong>*Some text*</strong></div>");
  
    # Output:
    # <p>&lt;div&gt;&lt;strong&gt;<em>Some text</em>&lt;/strong&gt;&lt;/div&gt;</p>
  

  (Parsedown does not do this properly)

• Attempts at escaping HTML appear throughout the code, but are not sufficient, or are applied in some places but missed in analogous ones (e.g. https://github.com/erusev/parsedown/pull/495#issuecomment-340721927)

This PR adds a record for the facade/ignition RCE vulnerability.

• https://www.ambionics.io/blog/laravel-debug-rce
• https://github.com/facade/ignition/pull/334
• https://github.com/facade/ignition/pull/353

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 https://github.com/ezsystems/ezplatform/commit/4e94c9552d28961e4251252b1cccd453ac96924f, 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?

Based on this https://github.com/propelorm/Propel2/issues/1675

the following does not apply to 1propel/propel": "2.0.0-alpha11`

I'm still getting the error https://github.com/ChurchCRM/CRM/runs/1471875270?check_suite_focus=true

Other files to note https://github.com/FriendsOfPHP/security-advisories/blob/master/propel/propel/2018-02-14.yaml https://github.com/ChurchCRM/CRM/blob/master/src/composer.json

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!

I'm not sure I have the time exactly as it should be. The example I looked at didn't match to the second (it used 00 for the second, so I did as well), but someone familiar with submitting these should probably check that date/time value.

This security advisory also affected simplesamlphp/saml2, but unfortunately I don't have time to submit a file for that path at the moment.

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?

Added the following TYPO3 extension security advisories:

• https://typo3.org/security/advisory/typo3-ext-sa-2022-016
• https://typo3.org/security/advisory/typo3-ext-sa-2022-017
• https://typo3.org/security/advisory/typo3-ext-sa-2022-018

Note: The extension for CVE-2022-47408 does not use semantic versioning, so it is not possible to cover all affected versions.

Problem: Maintainers use the Github security advisory database to publish security issues. Currently random developers like me find out about them when Github's dependabot flags them in a composer.lock file in one of my repositories. That is how the FriendsOfPHP/security-advisories database missed the Dompdf security issue #625 for 3 weeks, oopsie doodle.

Proposed Solution: Write a Github action that imports Github security advisories fully automatic into this repository. It could work something like this:

• Github action runs periodically (once per day?)
• It uses the Github GraphQL API to fetch all PHP composer security advisories from https://github.com/advisories?query=type%3Areviewed+ecosystem%3Acomposer
• It checks based on CVE identifier if the advisory already exists in this repository
• If not: it creates a new advisory file and commits it automatically (I assume this is somehow possible, not sure under which user account it would push the commit)

This could be a nice Google Summer of Code project or similar for a student :-)

Fixes #576

This commit adds an automatic OSV export to the osv branch while keeping the current repository as is.

Inspired by rustsec: https://github.com/rustsec/advisory-db/blob/main/.github/workflows/export-osv.yml

Preview

https://github.com/jaylinski/security-advisories/tree/osv

Possible improvements

• [ ] Validate generated JSON against spec (https://github.com/ossf/osv-schema/blob/main/validation/schema.json)
• [ ] Validate uniqueness of IDs

Before merging

• [ ] Create an empty osv branch with a readme similar to this one: https://github.com/rustsec/advisory-db/blob/osv/README.md

Introduction

Google recently published it's OSV unified vulnerability schema for open source: https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html

OSV is a vulnerability database and triage infrastructure for open source projects aimed at helping both open source maintainers and consumers of open source.

For open source maintainers, OSV's automation helps reduce the burden of triage. Each vulnerability undergoes automated bisection and impact analysis to determine precise affected commit and version ranges.

For open source consumers, OSV provides an API that lets users of these projects query whether or not their versions are impacted.

Discussion

It like the idea of having a unified schema for open source vulnerabilities, so I think it would be nice if this repository could adopt the new OSV schema.

I see the following benefits:

• No more discussion about the format (since it now follows a standard)
  Relates to #537, #496, #465
• The unified schema will make it easy for other libraries to use this repository as a data-feed, since it follows a schema also used for other languages
  Example: https://github.com/pypa/advisory-db/blob/main/vulns/aiohttp/PYSEC-2021-76.yaml
• This vulnerability feed can be made accessible via https://osv.dev/ API

I'm looking forward for your input. :octocat:

The format-change should be pretty straight forward. I'll open a PR if this proposal receives positive feedback.