The code assumed that `int x = - (unsigned) u` with 0 <= u < INT_MAX
sets `x` to the negative of u, but actually this calculates
(UINT_MAX - u) and then converts this value to int, which overflows.
Cast to int before applying the unary minus operator to guarantee the
desired behavior.
The code was making two unsequenced reads from volatile locations.
This is undefined behavior. It was probably harmless because we didn't
care in what order the reads happened and the reads were from ordinary
memory, but UB is UB and IAR8 complained.
Get rid of the variable p. This makes it more apparent where the code
accesses the buffer at an offset whose value is sensitive.
No intended behavior change in this commit.
Rather than doing the quadratic-time constant-memory-trace on the
whole working buffer, do it on the section of the buffer where the
data to copy has to lie, which can be significantly smaller if the
output buffer is significantly smaller than the working buffer, e.g.
for TLS RSA ciphersuites (48 bytes vs MBEDTLS_MPI_MAX_SIZE).
In mbedtls_rsa_rsaes_pkcs1_v15_decrypt, use size_greater_than (which
is based on bitwise operations) instead of the < operator to compare
sizes when the values being compared must not leak. Some compilers
compile < to a branch at least under some circumstances (observed with
gcc 5.4 for arm-gnueabi -O9 on a toy program).
Replace memmove(to, to + offset, length) by a functionally equivalent
function that strives to make the same memory access patterns
regardless of the value of length. This fixes an information leak
through timing (especially timing of memory accesses via cache probes)
that leads to a Bleichenbacher-style attack on PKCS#1 v1.5 decryption
using the plaintext length as the observable.
mbedtls_rsa_rsaes_pkcs1_v15_decrypt takes care not to reveal whether
the padding is valid or not, even through timing or memory access
patterns. This is a defense against an attack published by
Bleichenbacher. The attacker can also obtain the same information by
observing the length of the plaintext. The current implementation
leaks the length of the plaintext through timing and memory access
patterns.
This commit is a first step towards fixing this leak. It reduces the
leak to a single memmove call inside the working buffer.
Make the function more robust by taking an arbitrary zero/nonzero
argument instead of insisting on zero/all-bits-one. Update and fix its
documentation.
mbedtls_rsa_rsaes_pkcs1_v15_decrypt took care of calculating the
padding length without leaking the amount of padding or the validity
of the padding. However it then skipped the copying of the data if the
padding was invalid, which could allow an adversary to find out
whether the padding was valid through precise timing measurements,
especially if for a local attacker who could observe memory access via
cache timings.
Avoid this leak by always copying from the decryption buffer to the
output buffer, even when the padding is invalid. With invalid padding,
copy the same amount of data as what is expected on valid padding: the
minimum valid padding size if this fits in the output buffer,
otherwise the output buffer size. To avoid leaking payload data from
an unsuccessful decryption, zero the decryption buffer before copying
if the padding was invalid.
Remove a check introduced in the previous buffer overflow fix with keys of
size 8N+1 which the subsequent fix for buffer start calculations made
redundant.
Added a changelog entry for the buffer start calculation fix.
For a key of size 8N+1, check that the first byte after applying the
public key operation is 0 (it could have been 1 instead). The code was
incorrectly doing a no-op check instead, which led to invalid
signatures being accepted. Not a security flaw, since you would need the
private key to craft such an invalid signature, but a bug nonetheless.
The check introduced by the previous security fix was off by one. It
fixed the buffer overflow but was not compliant with the definition of
PSS which technically led to accepting some invalid signatures (but
not signatures made without the private key).
Fix buffer overflow in RSA-PSS signature verification when the hash is
too large for the key size. Found by Seth Terashima, Qualcomm.
Added a non-regression test and a positive test with the smallest
permitted key size for a SHA-512 hash.
* restricted/mbedtls-2.1:
Remove obsolete macros from compat-1.3.h
Add fix for #667 to ChangeLog
Fix bug in threading sample implementation #667
Fix check-doxy-blocks.pl to run from root dir
RSA: wipe more stack buffers
RSA: wipe stack buffers
The test case was generated by modifying our signature code so that it
produces a 7-byte long padding (which also means garbage at the end, so it is
essential to check that the error that is detected first is indeed the
padding rather than the final length check).
The sliding window exponentiation algorithm is vulnerable to
side-channel attacks. As a countermeasure we add exponent blinding in
order to prevent combining the results of different measurements.
This commit handles the case when the Chinese Remainder Theorem is used
to accelerate the computation.
The sliding window exponentiation algorithm is vulnerable to
side-channel attacks. As a countermeasure we add exponent blinding in
order to prevent combining the results of different measurements.
This commits handles the case when the Chinese Remainder Theorem is NOT
used to accelerate computations.
The RSA private key functions rsa_rsaes_pkcs1_v15_decrypt and
rsa_rsaes_oaep_decrypt put sensitive data (decryption results) on the
stack. Wipe it before returning.
Thanks to Laurent Simon for reporting this issue.
The PKCS#1 standard says nothing about the relation between P and Q
but many libraries guarantee P>Q and mbed TLS did so too in earlier
versions.
This commit restores this behaviour.
