Impact
The code that performs decryption and padding check in RSA PKCS#1 v1.5 decryption is data dependant.
In particular, code in current (as of 0.8.0-alpha38) master
|
def decrypt(self, encBytes): |
|
"""Decrypt the passed-in bytes. |
|
|
|
This requires the key to have a private component. It performs |
|
PKCS1 decryption of the passed-in data. |
|
|
|
:type encBytes: bytes-like object |
|
:param encBytes: The value which will be decrypted. |
|
|
|
:rtype: bytearray or None |
|
:returns: A PKCS1 decryption of the passed-in data or None if |
|
the data is not properly formatted. |
|
""" |
|
if not self.hasPrivateKey(): |
|
raise AssertionError() |
|
if self.key_type != "rsa": |
|
raise ValueError("Decryption requires RSA key, \"{0}\" present" |
|
.format(self.key_type)) |
|
if len(encBytes) != numBytes(self.n): |
|
return None |
|
c = bytesToNumber(encBytes) |
|
if c >= self.n: |
|
return None |
|
m = self._rawPrivateKeyOp(c) |
|
decBytes = numberToByteArray(m, numBytes(self.n)) |
|
#Check first two bytes |
|
if decBytes[0] != 0 or decBytes[1] != 2: |
|
return None |
|
#Scan through for zero separator |
|
for x in range(1, len(decBytes)-1): |
|
if decBytes[x]== 0: |
|
break |
|
else: |
|
return None |
|
return decBytes[x+1:] #Return everything after the separator |
and code in 0.7.5 branch
|
def decrypt(self, encBytes): |
|
"""Decrypt the passed-in bytes. |
|
|
|
This requires the key to have a private component. It performs |
|
PKCS1 decryption of the passed-in data. |
|
|
|
:type encBytes: bytearray |
|
:param encBytes: The value which will be decrypted. |
|
|
|
:rtype: bytearray or None |
|
:returns: A PKCS1 decryption of the passed-in data or None if |
|
the data is not properly formatted. |
|
""" |
|
if not self.hasPrivateKey(): |
|
raise AssertionError() |
|
if len(encBytes) != numBytes(self.n): |
|
return None |
|
c = bytesToNumber(encBytes) |
|
if c >= self.n: |
|
return None |
|
m = self._rawPrivateKeyOp(c) |
|
decBytes = numberToByteArray(m, numBytes(self.n)) |
|
#Check first two bytes |
|
if decBytes[0] != 0 or decBytes[1] != 2: |
|
return None |
|
#Scan through for zero separator |
|
for x in range(1, len(decBytes)-1): |
|
if decBytes[x]== 0: |
|
break |
|
else: |
|
return None |
|
return decBytes[x+1:] #Return everything after the separator |
has multiple ways in which it leaks information (for one, it aborts as soon as the plaintext doesn't start with 0x00, 0x02) about the decrypted ciphertext (both the bit length of the decrypted message as well as where the first unexpected byte lays).
All TLS servers that enable RSA key exchange as well as applications that use the RSA decryption API directly are vulnerable.
All previous versions of tlslite-ng are vulnerable.
Patches
The patches to fix it are proposed in
#438
#439
Note: the patches depend on Python processing the individual bytes in side-channel free manner, this is known to not be the case: https://securitypitfalls.wordpress.com/2018/08/03/constant-time-compare-in-python/
As such, users that require side-channel resistance are recommended to use different TLS implementations, as stated in the security policy of tlslite-ng.
Workarounds
There is no way to workaround this issue.
References
https://securitypitfalls.wordpress.com/2018/08/03/constant-time-compare-in-python/
For more information
If you have any questions or comments about this advisory please open an issue in tlslite-ng.
tomato42 Analyst
Impact
The code that performs decryption and padding check in RSA PKCS#1 v1.5 decryption is data dependant.
In particular, code in current (as of 0.8.0-alpha38) master
tlslite-ng/tlslite/utils/rsakey.py
Lines 407 to 441 in 0812ed6
and code in 0.7.5 branch
tlslite-ng/tlslite/utils/rsakey.py
Lines 394 to 425 in acdde31
has multiple ways in which it leaks information (for one, it aborts as soon as the plaintext doesn't start with 0x00, 0x02) about the decrypted ciphertext (both the bit length of the decrypted message as well as where the first unexpected byte lays).
All TLS servers that enable RSA key exchange as well as applications that use the RSA decryption API directly are vulnerable.
All previous versions of tlslite-ng are vulnerable.
Patches
The patches to fix it are proposed in
#438
#439
Note: the patches depend on Python processing the individual bytes in side-channel free manner, this is known to not be the case: https://securitypitfalls.wordpress.com/2018/08/03/constant-time-compare-in-python/
As such, users that require side-channel resistance are recommended to use different TLS implementations, as stated in the security policy of tlslite-ng.
Workarounds
There is no way to workaround this issue.
References
https://securitypitfalls.wordpress.com/2018/08/03/constant-time-compare-in-python/
For more information
If you have any questions or comments about this advisory please open an issue in tlslite-ng.