Re: [PEAR-QA] Fwd: Insecure RSA Encryption in jCryption, PEAR Crypt_RSA and Crypt_RSA2

https://github.com/pear/Crypt_RSA for patches; I've got NFI how to solve it
except "fork phpseclib's Crypt_RSA"

On Thu, Dec 1, 2011 at 4:12 AM, Stefan Neufeind <[email protected]> wrote:

> Hello PEARs, :-)
>
> just wanted to share that "security-announcement" with you.
>
>
> Regards,
>  Stefan
>
> -------- Original Message --------
> Subject: Insecure RSA Encryption in jCryption, PEAR Crypt_RSA and
> Crypt_RSA2
> Date: Wed, 30 Nov 2011 11:17:50 +0100
> From: Daniel Roethlisberger <[email protected]>
> Organization: SWITCH-CERT
> To: [email protected]
>
> SWITCH-CERT SECURITY ADVISORY
> =============================
>
> Vulnerability:      Insecure Implementation of RSA Encryption
> Affected Products:  jCryption, PEAR Crypt_RSA, PEAR Crypt_RSA2
> Advisory Date:      2011-11-30
> Advisory Author:    Daniel Roethlisberger, SWITCH-CERT
>
>
> ## Introduction
>
> Web applications using jCryption, PEAR Crypt_RSA or Crypt_RSA2 to
> provide confidentiality are vulnerable to exposure of the data
> protected by RSA encryption.
>
> jCryption is a jQuery based library for encrypted transmission of
> HTML form data from web browser to web application.  jCryption is
> designed to provide confidentiality against passive attacks.
> PEAR Crypt_RSA and Crypt_RSA2 are libraries providing RSA
> encryption to PHP/PEAR based web applications.  PEAR Crypt_RSA2
> was designed to be compatible with jCryption.
>
> jCryption and PEAR Crypt_RSA2 implement RSA with a static
> checksum and no random padding.  PEAR Crypt_RSA implements RSA
> with static padding.  The missing randomness in the padding leads
> to a loss of semantic security [1] and thus allows the RSA
> encryption to be broken [2,3] under realistic real-world
> circumstances.
>
>
> ## Affected Products
>
> Vulnerable:
> -   jCryption 1.2
> -   jCryption 1.1
> -   PEAR Crypt_RSA
> -   PEAR Crypt_RSA2
>
> Not Vulnerable:
> -   phpseclib Crypt_RSA
>
>
> ## Workaround / Solution
>
> Enabling TLS instead of relying on jCryption is a workaround.
>
> In general, only RSA implementations using a secure padding
> scheme such as PKCS#1 OAEP [4] should be used, for example the
> phpseclib version of Crypt_RSA.
>
>
> ## Technical Description
>
> The cryptographical protocol implemented by jCryption 1.2 is as
> follows:
>
> 1) Client requests URL.
>
> 2) Server generates per-session RSA keypair with e = 0x10001 and
>   random primes p and q.
>
> 3) Server sends client the HTML form, the jCryption JavaScript
>   code and the per-session RSA public key (e, n).
>
> 4) Client encrypts form data as follows:
>   checksum = checksum(plaintext);
>   ciphertext = RSA_encrypt(checksum || plaintext);
>   using modulus n, exponent e, deterministic checksum function
>   (modular sum of all bytes) and plain RSA in ECB mode with null
>   padding.
>
> 5) Client sends ciphertext to server, which does the reverse of 4
>   to decrypt the message using the per-session private key d.
>
> PEAR Crypt_RSA2 provides RSA encryption/decryption compatible
> with jCryption, thus essentially just step 4.
>
> PEAR Crypt_RSA uses a plain RSA operation in the following way:
>
>   ciphertext = RSA_encrypt(plaintext || 0x01);
>
> Using modulus n, exponent e, concatenation ||, and RSA_encrypt()
> being plain RSA in ECB mode with null padding.  There is no
> randomness in this scheme.
>
> These are essentially plain textbook RSA with deterministic
> padding.  There is a number of well-known attacks against plain
> RSA [2,3].  An attacker with the ability to sniff HTTP traffic
> can use these attacks to break the RSA encryption, which is the
> exact attack scenario that jCryption is designed to protect
> against.  The most obvious attack: Because the scheme is not
> semantically secure [1], an attacker can guess likely plaintexts,
> encrypt them using the known public key, and compare the
> resulting cyphertext to the original cyphertext.
>
> The attack scenarios for PEAR Crypt_RSA and Crypt_RSA2 depend on
> the way they are used by an application, but in general,
> confidentiality is lost in the same way.
>
>
> ## Other Attacks
>
> Of course, since the jCryption scheme lacks authentication and
> integrity, it is also vulnerable to active attacks (MitM).
> However, since jCryption was not designed to protect against
> active attacks and does not claim to do so, that's out of scope
> of this advisory, even if it is totally relevant in practice.
>
>
> ## Disclosure Timeline
>
> 2011-11-30:     Public disclosure due to no response (jCryption)
>                and wont fix (PEAR Crypt_RSA) answers.
> 2011-08-13:     PEAR project forwards initial notification to a
>                public mailing list; response: wont fix.
> 2011-08-10:     PEAR Crypt_RSA original author response: not
>                maintained anymore.
> 2011-08-10:     Initial vendor/author notification for jCryption
>                and PEAR Crypt_RSA.
> 2011-08-02:     Discovery by Daniel Roethlisberger, SWITCH-CERT.
>
>
> ## References
>
> [1] http://en.wikipedia.org/wiki/Semantic_security
>
> [2] http://en.wikipedia.org/wiki/RSA#Attacks_against_plain_RSA
>
> [3] D. Boneh, A. Joux, P. Nguyen:
>    Why Textbook ElGamal and RSA Encryption are Insecure
>
>
> http://www.comms.engg.sussex.ac.uk/fft/crypto/Why_Textbook_ElGamal_and_RSA_Encryption_are_Insecure.pdf
>
> [4] RFC 3447: Public-Key Cryptography Standards (PKCS) #1:
>    RSA Cryptography Specifications Version 2.1
>    https://www.ietf.org/rfc/rfc3447.txt
>
> --
> PEAR QA Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>