[Bug 25431] Error names allow RSAES-PKCS1-v1_5 oracle attack against wrapped keys

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431

--- Comment #7 from Mark Watson <watsonm@netflix.com> ---
So, first, considering the issue actually in the subject line of this bug, if
we change the specification so that padding errors and parse errors do not
return distinct codes, then I believe the padding oracle attack of [B98] and
variants is rendered infeasible for keys that have usage 'unwrap' and not
'decrypt' and where the wrapped key format has some structure: the chosen
ciphertexts in the attack would not only need to result in correctly padded
plaintext, but syntactically valid payloads. The chance of this for any given
chosen ciphertext seems little better than random, rendering the attack
infeasible.

Second, for the *separate* issue of the same attack using the decrypt method as
the oracle, it does indeed seem convoluted to modify the API so that
information is not leaked about the correctness or not of the padding. However,
to practically exploit this, the attacker needs either to be able to run
arbitrary code on the origin of the key, or to modify messages and observe the
results (and for the distinction between success and padding errors to be
exposed in those results).

For the first case of an attacker able to run arbitrary code on the origin of
the key, it would seem much simpler for that attacker to simply replace the
global webcrypto object with their own polyfill, giving them access to the RSA
key itself at the time it is generated / imported / unwrapped. The exception is
the case where the RSA key, or a non-extractable key used to unwrap it, is
generated / imported / unwrapped at an earlier time at which the attacker is
not present. An effective mitigation then, would be to always use the RSA key
immediately, to unwrap a symmetric key, for example, and then discard the RSA
one.

Finally, for the second case of an attacker able to modify and observe messages
but unable to insert arbitrary code onto the client, it would be sufficient for
the JS application to avoid exposing a distinction between the success and
failure cases, for example as per the TLS approach Ryan cited.

I don't want to underplay the significance of the weaknesses with this padding
scheme or suggest for a moment that one shouldn't always use RSA-OAEP instead
if that is available. But it seems that support for RSA-OAEP is not going to be
universal in browsers, at least initially.

I'd suggest that we fix this for the unwrap case as suggested above. For the
decrypt case, the existence of the oracle attack seems to make things no worse
with respect to an attacker able to run arbitrary code, provided RSA keys are
not persisted, and can be mitigated through protocol design for an attacker
able to modify messages but not run arbitrary JS on the origin. 

[B98] D. Bleichenbacher. Chosen ciphertext attacks against protocols based on
the RSA encryption standard. In Advances in Cryptology: Proceedings of
CRYPTO’98, volume 1462 of LNCS, pages 1–12, 1998.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 12 May 2014 23:56:57 UTC