Previously, MAC validation for an incoming record proceeded as follows:
1) Make a copy of the MAC contained in the record;
2) Compute the expected MAC in place, overwriting the presented one;
3) Compare both.
This resulted in a record buffer overflow if truncated MAC was used, as in this
case the record buffer only reserved 10 bytes for the MAC, but the MAC
computation routine in 2) always wrote a full digest.
For specially crafted records, this could be used to perform a controlled write of
up to 6 bytes past the boundary of the heap buffer holding the record, thereby
corrupting the heap structures and potentially leading to a crash or remote code
execution.
This commit fixes this by making the following change:
1) Compute the expected MAC in a temporary buffer that has the size of the
underlying message digest.
2) Compare to this to the MAC contained in the record, potentially
restricting to the first 10 bytes if truncated HMAC is used.
A similar fix is applied to the encryption routine `ssl_encrypt_buf`.
* mbedtls-2.1:
Fix typo in asn1.h
Improve leap year test names in x509parse.data
Correctly handle leap year in x509_date_is_valid()
Renegotiation: Add tests for SigAlg ext parsing
Parse Signature Algorithm ext when renegotiating
Fix changelog for ssl_server2.c usage fix
Fix ssl_server2 sample application prompt
Update ChangeLog for fix to #836
Enhance documentation of ssl_write_hostname_ext, adapt ChangeLog.
Enhance documentation of mbedtls_ssl_set_hostname
Add test case calling ssl_set_hostname twice
Make mbedtls_ssl_set_hostname safe to be called multiple times
Fix typo in configs/README.txt file
The function mbedtls_ecp_gen_keypair_base did not wipe the stack buffer used to
hold the private exponent before returning. This commit fixes this by not using
a stack buffer in the first place but instead calling mpi_fill_random directly
to acquire the necessary random MPI.
This commit modifies mpi_read_binary to always allocate the minimum number of
limbs required to hold the entire buffer provided to the function, regardless of
its content. Previously, leading zero bytes in the input data were detected and
used to reduce memory footprint and time, but this non-constant behavior turned
out to be non-tolerable for the cryptographic applications this function is used
for.
Previously, if `MBEDTLS_SSL_RENEGOTIATION` was disabled, incoming handshake
messages in `mbedtls_ssl_read` (expecting application data) lead to the
connection being closed. This commit fixes this, restricting the
`MBEDTLS_SSL_RENEGOTIATION`-guard to the code-paths responsible for accepting
renegotiation requests and aborting renegotiation attempts after too many
unexpected records have been received.
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.
This commit fixes a comparison of ssl_session->encrypt_then_mac against the
ETM-unrelated constant MBEDTLS_SSL_EXTENDED_MS_DISABLED. Instead,
MBEDTLS_SSL_ETM_DISABLED should be used.
The typo is has no functional effect since both constants have the same value 0.
This commit adds a build with default config except
MBEDTLS_SSL_MAX_FRAGMENT_LENGTH to all.sh, as well as a run of the MFL-related
tests in ssl-opt.sh.
Some tests in ssl-opt.sh require MBEDTLS_SSL_MAX_CONTENT_LEN to be set to its
default value of 16384 to succeed. While ideally such a dependency should not
exist, as a short-term remedy this commit adds a small check that will at least
lead to graceful exit if that assumption is violated.
This commit adds four tests to ssl-opt.sh testing the library's behavior when
`mbedtls_ssl_write` is called with messages beyond 16384 bytes. The combinations
tested are TLS vs. DTLS and MBEDTLS_SSL_MAX_FRAGMENT_LENGTH enabled vs. disabled.
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).