It is now unreachable because:
- end_set == end_attr_data is enforced at library/x509_csr.c:236.
- end_exts == end_set is enforced at library/x509_csr.c:248.
- x509_csr_parse_extensions() only returns success if *p == end_exts, enforced
at library/x509_csr.c:188.
So after a successful x509_csr_parse_extensions() call, *p == end_exts ==
end_set == end_attr_data. The condition at line 257 cannot be true.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't allow parts of a compound (SEQUENCE or SET) to go beyond the
containing compound.
The inline CSR regression test is derived from the existing "X509 CSR
ASN.1 (OK)" DER test vector. In the extensionRequest attribute, the original
well-formed fragment is:
a029 3027 06092a864886f70d01090e 311a 3018 ...
where 31 1a is the SET containing the Extensions sequence and 30 18 is the
contained Extensions sequence. The malformed test changes only the SET
length byte, from 1a to 19:
a029 3027 06092a864886f70d01090e 3119 3018 ...
The attribute SEQUENCE length and the inner Extensions sequence length are
left unchanged. This makes the SET one byte too short for its containing
attribute, so the parser must reject it with
MBEDTLS_ERR_ASN1_LENGTH_MISMATCH instead of parsing the trailing byte as
data outside the SET.
There is no known security impact, just some risk reduction.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When parsing the basicConstraints extension, reject junk after the SEQUENCE
inside the extension (which is probably benign), and reject a SEQUENCE that
extends beyond the extension (could be very dangerous).
Add a non-regression test where a certificate that is technically malformed,
but accepted as a leaf certificate by OpenSSL and other X.509
implementations, to be accepted as a CA certificate by Mbed TLS.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When MBEDTLS_SSL_PROTO_TLS1_3 is enabled ensure that at least one of the
related key exchanges is also enabled.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Following the team discussion, don't suggest "prerequisite" or "consuming"
in the template. Suggest linking all the pull requests in a group
everywhere.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This directory is currently excluded from `check-python-files.sh`, because
we run it on the CI in an old Python version that doesn't support some of
our new maintainer scripts.
There are no such scripts in mbedtls for now (only in TF-PSA-Crypto), but be
ready if we want to add some.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This way, when Mbed TLS's `analyze_outcomes.py` loads the python module from
TF-PSA-Crypto (because it needs to know the value of `INTERNAL_TEST_CASES`),
there's no risk that the subproject and the superproject will have different
requirements on auxiliary modules such as `mbedtls_framework.outcome_analysis`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If we can't read `INTERNAL_TEST_CASES` from
`tf-psa-crypto/tests/scripts/analyze_outcomes.py` because the script doesn't
exist, hard-code the legacy value of that information.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If the `tf-psa-crypto` submodule has `tests/scripts/analyze_outcomes.py`,
require it to define a global variable `INTERNAL_TEST_CASES`. Those test
cases will be ignored in Mbed TLS's coverage analysis.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
