[<prev] [next>] [day] [month] [year] [list]
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: 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
