full-disclosure - [FD] Joomla CMS - Bad Cryptography

Open Source and information security mailing list archives

Message-ID: <CAKws9z180P5D6H0QUAg5jcz+a6GR7Z0tCNcTzmB3U9LzwfFk1w@mail.gmail.com>
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: [FD] 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.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives