See http://www.openwall.com/lists/oss-security/2016/07/19/3 for details
Thanks. We are aware of the mcrypt issues and have plans to replace mcrypt with more modern library (phpseclib? libsodium?) pretty soon.
In the initial comment, you said Magento is not encrypting credit card data, but it was edited before I could reply.
I do want to point out, for the record, that Magento does appear to be decrypting credit card data here.
@paragonie-scott to be exact, none of the payment methods included with Magento stores card data.
OK, that's good to know. I hope no plugins are using this for that purpose.
(phpseclib? libsodium?)
Libsodium is available as a PHP extension, so if you can't require your users to install it from PECL, that's probably not an option.
For symmetric-key encryption, you have a few good choices:
Last I checked (which, admittedly, was ages ago, so it could have changed), phpseclib didn't offer a simple and easy-to-use authenticated encryption interface like defuse does. Unauthenticated encryption, though correctly implemented, doesn't fix the sensitivity to CPAs or CCAs.
If you need public-key encryption and/or digital signatures, give EasyRSA a gander. I wrote about its benefits in response to a Drupal thread about implementing automatic security updates.
Internal ticket ID MAGETWO-39838
I just ran into this issue on production :/ when do you plan to fix this?
Since ext-openssl
is already a requirement of Magento, would it not make more sense to use that instead? PHP 7.1 will be throwing E_DEPRECATED
for the use of ext-mcrypt
, and it will either be moved to PECL in 7.2 or 8.0. Usage (ignoring vendors) is contained within Framework/Encryption
and it shouldn't be too complicated to migrate (code) 鈥撀爉igrating existing data might be more involved.
On my PHP 7.0.12 installation, the OpenSSL extension has 190 cipher methods available, it should be suitable without requiring an additional library or extension.
defuse/php-encryption
uses OpenSSL, but more importantly it offers simple and easy-to-use _authenticated encryption_.
An easy-to-use abstraction over OpenSSL is fine. For simplicity's sake, I'd rather not have to compile an additional extension or use PECL
, which could also be curtains shortly... hence my recommendation of OpenSSL since it's already a requirement, an additional entry in the requires
object of my composer.json
is a 馃憤 from me.
Understood.
We are in agreement that OpenSSL is preferable to mcrypt. I just wanted to emphasize the use of a secure abstraction instead of lower-level primitives. :)
I just checked my installation of 2.1.2, and the develop branch, and we can see that use of the mcrypt_*
is still alive and well:
See Magento\Framework\Encryption\Crypt
<?php
// ....
public function __construct($key, $cipher = MCRYPT_BLOWFISH, $mode = MCRYPT_MODE_ECB, $initVector = false)
{
$this->_cipher = $cipher;
$this->_mode = $mode;
$this->_handle = mcrypt_module_open($cipher, '', $mode, '');
try {
$maxKeySize = mcrypt_enc_get_key_size($this->_handle);
// ...
Since it's not reasonably possible to say that PHP 7.1 is supported without this, and given that PHP 7.1 is now out, can we have a status update on this ticket MAGETWO-39838
?
For cross-reference: In Magerun 2 we've added PHP 7.1 support now and do see the various reported issues with Magento 2 now as well as they became blatantly obvious. We're tracking this downstream at https://github.com/netz98/n98-magerun2/issues/256.
Issues I could spot so far within the Magento 2 Github Tracker are:
I suggest to add 7.1 to the Travis build and allow it to fail. That should make it easier to progress and keep track of things.
In the light of the recent security report with the remote code execution issue on sending mails (#6146, ZF2016-04), I would suggest Magento to run checks with RIPS which is able to find injection flaws of such kind (e.g. in Roundcube, published Dec 6 2016). Just commenting for reference /cc @piotrekkaminski
X-Ref:
This can be now closed as PHP 7.1 became a part of Travis CI builds officially: https://github.com/magento/magento2/blob/develop/.travis.yml#L13
via: https://github.com/magento/magento2/pull/7688#issuecomment-298945777
One possible solution to the cryptography flaws laid out here is sodium_compat, but it's not yet known if it's safe to use yet. Only a cryptography audit will tell.
What's the TAT on a release for PHP 7.1 compatibility?
sodium_compat v1.0 is out if the Magento team wants to switch to more secure cryptography
Libsodium has just been merged into PHP 7.2 so, from 7.2 onwards, it's no longer dependent on an extension.
Internal ticket to track issue progress: MAGETWO-66161
So given the state of M2.2, it will never work on PHP7.2? If M2.3 will use Sodium, does that mean it will only work with PHP7.2 and above, or will the compat module be included (or suggested for lower versions)?
@paragonie-scott, thank you for your report.
We've created internal ticket(s) MAGETWO-39838 to track progress on the issue.
Implementation for 2.3 is currently in progress in the scope of magento-engcom/php-7.2-support project
@ishakhsuvarov judging from the composer.json in that branch, M2.3.1 will still be using a polyfill for mcrypt. Can you confirm there is an initiative underway to actually implement libsodium along with sodium_compat instead of mcrypt, phpseclib and mcrypt_compat?
I can answer this one, as I've been involved in the migration strategy and protocol review.
The gameplan is to switch to libsodium (with sodium_compat as a fallback when ext/sodium isn't available).
However, for the sake of decrypting existing ciphertexts after the M2 upgrade, mcrypt_compat was included as well. Its purpose is to enable seamless migrations to better encryption, not to keep Magento in the dark ages of cryptography.
@paragonie-scott thanks for the explanation! Just listened to you on the Roundtable ep 71 (and 73) yesterday, great work on libsodium w/ PHP7.2 :+1:
Hi @paragonie-scott,
Magento 2.3.x supports libsodium together with php 7.2, so looks like this issue was already fixed. Wasn't it?
Yep!
Most helpful comment
For cross-reference: In Magerun 2 we've added PHP 7.1 support now and do see the various reported issues with Magento 2 now as well as they became blatantly obvious. We're tracking this downstream at https://github.com/netz98/n98-magerun2/issues/256.
Issues I could spot so far within the Magento 2 Github Tracker are:
I suggest to add 7.1 to the Travis build and allow it to fail. That should make it easier to progress and keep track of things.