Backport the ssl_context_load_rejects_oob_length test function from
development in its final form, with cases for the serialized in_cid,
out_cid and ALPN lengths.
mbedtls_test_ssl_dtls_join_endpoints() and
mbedtls_test_ssl_perform_connection() do not exist on this branch, so
set up the DTLS endpoints and run the handshake with the helpers that
do: mbedtls_test_ssl_endpoint_init() with message queues,
mbedtls_test_mock_socket_connect() and
mbedtls_test_move_handshake_to_state(). Exchange application data
explicitly before saving the context, as
mbedtls_test_ssl_perform_connection() does on development: the server
keeps its handshake structure until then, and
mbedtls_ssl_context_save() refuses to run while it exists.
Signed-off-by: Naveed <naveed@bugqore.com>
The serialized ALPN length was passed to memcmp() against each configured protocol without checking it against the remaining serialized data, so a malformed context could read past the end of the buffer. Bound it before the comparison, like the adjacent CID fields.
Signed-off-by: Naveed <naveed@bugqore.com>
Previous wording only named the four low-level update() functions
directly touched by the fix. mpg pointed out a normal user calling
mbedtls_md_update(), psa_hash_compare(), or any of the one-shot
wrappers (mbedtls_md5(), mbedtls_sha256(), psa_hash_compute(), etc.)
has no way to tell from that wording whether they are affected, and
that SHA-224 should be listed explicitly even though it shares
mbedtls_sha256_update() under the hood, since that implementation
detail should not be something a ChangeLog reader needs to already
know.
Signed-off-by: Johnson Ajibi <ajibijohnson@gmail.com>
Per mpg's review, MD5, SHA-1 and RIPEMD-160 have the exact same bug as
SHA-256: mbedtls_*_update() truncates ilen to its low 32 bits before
adding it to ctx->total[0], and the overflow check right after only
catches the single wraparound of that 32-bit addition -- neither step
folds in bits 32 and up of ilen itself when a single update() call is
passed >= 2^32 bytes on a 64-bit platform.
SHA-512 does not have this bug (confirmed by TimothyPMann and
independently by me): it tracks its 128-bit byte count in two
uint64_t words, so ilen (a 64-bit size_t at most) can never overflow
the low word before the carry-in step even runs.
Applied the identical fix to all three: fold ilen >> 32 into total[1],
guarded on SIZE_MAX so 32-bit platforms are unaffected.
Verified live with the same method as the SHA-256 fix: hashed a real
4GiB + 64 byte file with mbedtls_md5_update()/sha1_update()/
ripemd160_update() in a single call and compared against md5sum(1),
sha1sum(1), and `openssl dgst -rmd160`.
algorithm before fix (wrong) after fix (matches reference tool)
MD5 0e8b3fdad1980e2c4e66ef714abc3f0c 8b647773014d9f640da9887274f444cd
SHA-1 b190a761fceaafdc19b62cbcc729ec22b02e7d0c 703fe5b4441eb203af67ed4fbc20263d44bc5f5c
RIPEMD-160 68956d1517f2ebcef4761d2c0fddf11331a1e6b6 d14d7e80c32ddc603c677151bfd59fd8cf867c42
Also reworded the ChangeLog entry per feedback to cover all four
functions concisely instead of describing the SHA-256 internals in
detail.
Signed-off-by: Johnson Ajibi <ajibijohnson@gmail.com>
mbedtls_sha256_update() tracks the running byte count in a 64-bit
counter split across ctx->total[0]/[1] (32 bits each), used at
finalization to encode the message length into the padding.
ctx->total[0] += (uint32_t) ilen truncates ilen to its low 32 bits
before adding, and the overflow check right after (ctx->total[0] <
(uint32_t) ilen) only detects the single wraparound of that 32-bit
addition. Neither step ever looks at bits 32 and up of ilen itself.
So when a single update() call is passed >= 2^32 bytes on a 64-bit
platform (size_t wider than 32 bits), every byte is correctly hashed
into the message, but the length folded into the final padding block
is wrong by a multiple of 2^32 bytes, producing an incorrect digest
despite no error being returned.
Fold ilen>>32 into total[1] directly, guarded on SIZE_MAX so 32-bit
platforms (where ilen cannot exceed 2^32-1 and the shift would be
UB-adjacent) are unaffected.
Verified live: generated a 4GiB+64 byte random file, hashed it with
mbedtls_sha256_update() in a single call both before and after this
fix, and compared against sha256sum of the same file.
- before: 803ab176fbafaf3cf345cbe22e2a35715c3ae8f7fbf241a00677d4d733db0214 (wrong)
- after: 21a1f671cd9797227f341a243fed82c8fe95a769a58a6f3965e958f047e969d6 (matches sha256sum)
Also re-verified normal-sized inputs (empty string, "abc") against
known SHA-256 vectors, and that a two-call split of a 100-byte input
still agrees with a single whole-buffer call.
Fixes#10964.
Signed-off-by: Johnson Ajibi <ajibijohnson@gmail.com>
Backport the final approved implementation from Mbed-TLS/TF-PSA-Crypto#843
to mbedtls-3.6.
Enable the existing Linux getrandom syscall path when sys/syscall.h
is available and defines SYS_getrandom. Preserve the existing
glibc/Midipix detection and runtime ENOSYS fallback.
Apply the platform change to library/entropy_poll.c in this branch.
Signed-off-by: Ning Xia <hi@nosec.me>
Change the documentation of mbedtls_sha3_finish() and mbedtls_sha3()
to state that olen must be at least the digest size (28, 32, 48, or 64
for SHA3-224/256/384/512) rather than must equal it.
The implementation accepts olen larger than the digest size — it
silently writes the digest and ignores the excess. The previous docs
incorrectly suggested that olen larger than the digest size would be
an error.
Fixes#10844
Signed-off-by: AaryanCdry <AaryanCdry@users.noreply.github.com>
Make SSL test helper code potentially available to sample programs. This is
notably useful for `ssl_client2` and `ssl_server2`, which may reasonably use
some test helper code even in the default configuration.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In terms of CMake, we want it to be part of the mbedtls_test_helpers
object collection, which as the name does not suggest, is actually for
SSL, and not part of mbedtls_test which is generic.
The easiest way to achieve that is to move the source file to
test_helpers which again as the name does not reflect is for SSL.
Then we just need ssl_server2 and ssl_client2 to link to
mbedtls_test_helpers.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
