esp_crt_check_bundle() read the 4-byte certificate header (name_len,
key_len) via esp_crt_get_len() after only checking that the cert's
start offset lies inside the bundle, so a crafted bundle whose first
or last certificate starts within the final 3 bytes caused a transient
out-of-bounds read of up to 3 bytes before the extent check rejected
it. Require the whole header to lie inside the bundle before reading
it.
gen_crt_bundle.py now uses the shared esp-pylib library instead of its own
logging and argument parsing, so its messages look the same as the rest of
the ESP-IDF Python tools.
gen_crt_bundle.py only parses files ending in .pem or .der, but silently
ignored anything else. A PEM certificate named e.g. ca.crt was skipped
without a word, and since the build invokes the script with -q, even the
"Successfully added 0 certificates" hint was suppressed. The build then
succeeded and embedded a bundle without the certificate, and the problem
only surfaced at runtime as a TLS verification failure.
A file passed directly via --input, which is what
CONFIG_MBEDTLS_CUSTOM_CERTIFICATE_BUNDLE_PATH points at, is now expected
to be a certificate: an unsupported extension raises an InputError and
fails the build with a message naming the file and the two accepted
extensions. Files found while scanning a directory keep being skipped,
as a certificate directory may legitimately contain other files, but a
warning is now printed unconditionally so it is visible in the build log.
Also document the requirement in the Kconfig help text and in the
esp_crt_bundle documentation.
Closes https://github.com/espressif/esp-idf/issues/18933
The offset table and the per-cert length fields of the certificate
bundle were read through uint16_t*/uint32_t* casts, which compile to
halfword/word loads at addresses with no alignment guarantee: bundles
supplied via esp_crt_bundle_set() can start anywhere, and cert entries
are byte-packed, so their 16-bit fields land at arbitrary offsets.
On chips with SOC_CPU_MISALIGNED_ACCESS_ON_PMP_MISMATCH_ISSUE (DIG-694:
ESP32-C6/H2/H21) a misaligned load from memory-mapped flash can take a
spurious "Load access fault" when it sits within two instructions of an
access to a differently-permissioned region, observed as a crash in
esp_crt_check_bundle()/CA callback during TLS handshakes with a bundle
that happened to be placed at an odd address.
Some of the endpoints (e.g., httpbin.org) is still relying on the
Starfield Class 2 CA in the chain. Added this root certificate as
a temporary exception and shall be removed in future.
