By looking just at that test, it looks like 2 + dn_size could overflow. In
fact that can't happen as that would mean we've read a CA cert of size is too
big to be represented by a size_t.
However, it's best for code to be more obviously free of overflow without
having to reason about the bigger picture.
Remove check on the pathLenConstraint value when looking for a parent to the
EE cert, as the constraint is on the number of intermediate certs below the
parent, and that number is always 0 at that point, so the constraint is always
satisfied.
The check was actually off-by-one, which caused valid chains to be rejected
under the following conditions:
- the parent certificate is not a trusted root, and
- it has pathLenConstraint == 0 (max_pathlen == 1 in our representation)
fixes#280
This was already working but not tested so far
(Test case from previous commit still failing.)
Test certificates generated with:
programs/pkey/gen_key type=ec ec_curve=secp256r1 filename=cert91.key
programs/pkey/gen_key type=ec ec_curve=secp256r1 filename=cert92.key
programs/x509/cert_write serial=91 output_file=cert91.crt is_ca=1 \
issuer_key=cert91.key issuer_name="CN=Root 9,O=mbed TLS,C=UK" \
selfsign=1 max_pathlen=0
programs/x509/cert_write serial=92 output_file=cert92.crt \
issuer_key=cert91.key issuer_name="CN=Root 9,O=mbed TLS,C=UK" \
subject_key=cert92.key subject_name="CN=EE 92,O=mbed TLS,C=UK"
* polarssl-1.2:
Use own implementation of strsep()
Add Changelog entries for this branch
Use symbolic constants in test data
Fixed pathlen contraint enforcement.
Additional corner cases for testing pathlen constrains
Added test case for pathlen constrains in intermediate certificates
If len is large enough, when cast to an int it will be negative and then the
test if( len > MAX_PATH - 3 ) will not behave as expected.
Ref: IOTSSL-518
backport of 261faed725
* polarssl-1.2:
Fix spurious #endif from previous cherry-pick
Fix macroization of inline in C++
Add missing warning in doc
Fix compile error in net.c with musl libc
Found by Guido Vranken.
Two possible integer overflows (during << 2 or addition in BITS_TO_LIMB())
could result in far too few memory to be allocated, then overflowing the
buffer in the subsequent for loop.
Both integer overflows happen when slen is close to or greater than
SIZE_T_MAX >> 2 (ie 2^30 on a 32 bit system).
Note: one could also avoid those overflows by changing BITS_TO_LIMB(s << 2) to
CHARS_TO_LIMB(s >> 1) but the solution implemented looks more robust with
respect to future code changes.
