Date: Sun, 8 Nov 2015 01:48:57 -0500 From: Scott Arciszewski <scott@...agonie.com> To: oss-security@...ts.openwall.com, fulldisclosure@...lists.org Subject: Joomla CMS - Bad Cryptography - Multiple Vulnerabilities Hi OSS-Sec, Full Disclosure, MITRE, and friends, I spent roughly half an hour looking at Joomla (and picking up my jaw from the floor at how bad their crypto is), and this is what I found: https://github.com/joomla/joomla-cms/issues/created_by/paragonie-scott It seems to hit the jackpot at "bad crypto bingo", even going so far as to deploy a home-grown cipher that is basically XOR-ECB: https://github.com/joomla/joomla-cms/issues/8327 MITRE: I'd like to request just one CVE for the Joomla cryptography library, even though I've identified multiple issues here, as it would seem redundant to get a CVE for every fatal mistake they made. But just in case that's a no-go, here's a complete enumeration of what I've found: - JCrypt: Silent fallback to a weak, userspace PRNG (which is very bad for cryptography purposes) - JCryptCipherSimple: Homegrown weak cipher (XOR-ECB) - JCryptCipher: Chosen ciphertext attacks (no authentication) - JCryptCipher: Data corruption / padding oracle attack - JCryptCipher: Static IV for CBC mode (stored with JCryptKey under the misnomer property, "public") -- this sort of defeats the purpose of using CBC mode - JCryptPasswordSimple: PHP Non-Strict Type Comparison (a.k.a. Magic Hash vulnerability) Additionally, there's a (probably non-exploitable) issue that affects all JCrypt functions: If mbstring.func_overload is enabled (set to 2, 3, or 7 in php.ini), strlen() and substr() will act as of the input strings are Unicode strings rather than raw binary strings. None of these functions are written to handle this, which can lead to unpredictable results (i.e. with timingSafeCompare()). I'd strongly encourage people to not use the current incarnation of JCrypt for anything sensitive, especially if it's exposed to active attackers. Instead, check out libsodium, Halite (a libsodium wrapper that I wrote), defuse/php-encryption, or Zend\Crypt instead. * https://pecl.php.net/package/libsodium * https://github.com/paragonie/halite * https://github.com/defuse/php-encryption * https://github.com/zendframework/zend-crypt Additionally, anyone whose PCI/whatever compliance is in any way hinged upon the cryptography that Joomla provided should probably notify their pen-testers and get re-evaluated with this new information at their earliest convenience. That's all from me. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> P.S. If anyone feels like the sky is falling, please take a deep breath. Everything will be okay. If any companies need a security consultant to help them assess the impact (if any) of these developments on their bottom line, feel free to drop me a line.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ