Fix Lucky 13 cache attack on MD/SHA padding
The basis for the Lucky 13 family of attacks is for an attacker to be able to
distinguish between (long) valid TLS-CBC padding and invalid TLS-CBC padding.
Since our code sets padlen = 0 for invalid padding, the length of the input to
the HMAC function gives information about that.
Information about this length (modulo the MD/SHA block size) can be deduced
from how much MD/SHA padding (this is distinct from TLS-CBC padding) is used.
If MD/SHA padding is read from a (static) buffer, a local attacker could get
information about how much is used via a cache attack targeting that buffer.
Let's get rid of this buffer. Now the only buffer used is the internal MD/SHA
one, which is always read fully by the process() function.
diff --git a/ChangeLog b/ChangeLog
index 19bdb79..0acb2c6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -16,6 +16,13 @@
caused by a miscalculation (for SHA-384) in a countermeasure to the
original Lucky 13 attack. Found by Kenny Paterson, Eyal Ronen and Adi
Shamir.
+ * Fix a vulnerability in TLS ciphersuites based on CBC, in (D)TLS 1.0 to
+ 1.2, that allowed a local attacker, able to execute code on the local
+ machine as well as manipulate network packets, to partially recover the
+ plaintext of messages under some conditions (see previous entry) by using
+ a cache attack targetting an internal MD/SHA buffer. Connections using
+ GCM or CCM instead of CBC or using Encrypt-then-Mac (RFC 7366) were not
+ affected. Found by Kenny Paterson, Eyal Ronen and Adi Shamir.
API Changes
* Extend the platform module with a util component that contains
