A lot of DTLS test are timing-sensitive, especially those that contain
assertions about retransmission. Sometimes some DTLS test fails intermittently
on the CI with no clear apparent reason; we need more information in the log
to understand the cause of those failures.
Adding a proxy means we'll get timing information from the proxy logs.
An alternative would be to add timing information to the debug output of
ssl_server2 and ssl_client2. But that's more complex because getting
sub-second timing info is outside the scope of the C standard, and our current
timing module only provides a APi for sub-second intervals, not absolute time.
Using the proxy is easier as it's a single point that sees all messages, so
elapsed time is fine here, and it's already implemented in the proxy output.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In the entries (mbedtls_x509_crl_entry values) on the list constructed
by mbedtls_x509_crl_parse_der(), set entry->raw.tag to
(SEQUENCE | CONSTRUCTED) rather than to the tag of the first ASN.1
element of the entry (which happens to be the tag of the serial
number, so INTEGER or INTEGER | CONTEXT_SPECIFIC). This is doesn't
really matter in practice (and in particular the value is never used
in Mbed TLS itself), and isn't documented, but at least it's
consistent with how mbedtls_x509_buf is normally used.
The primary importance of this change is that the old code tried to
access the tag of the first element of the entry even when the entry
happened to be empty. If the entry was empty and not followed by
anything else in the CRL, this could cause a read 1 byte after the end
of the buffer containing the CRL.
The test case "X509 CRL ASN1 (TBSCertList, single empty entry at end)"
hit the problematic buffer overflow, which is detected with ASan.
Credit to OSS-Fuzz for detecting the problem.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a few more negative test cases for mbedtls_x509_crl_parse.
The test data is manually adapted from the existing positive test case
"X509 CRL ASN1 (TBSCertList, sig present)" which decomposes as
305c
3047 tbsCertList TBSCertList
020100 version INTEGER OPTIONAL
300d signatureAlgorithm AlgorithmIdentifier
06092a864886f70d01010e
0500
300f issuer Name
310d300b0603550403130441424344
170c303930313031303030303030 thisUpdate Time
3014 revokedCertificates
3012 entry 1
8202abcd userCertificate CertificateSerialNumber
170c303831323331323335393539 revocationDate Time
300d signatureAlgorithm AlgorithmIdentifier
06092a864886f70d01010e
0500
03020001 signatureValue BIT STRING
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is an LTS branch, C99 isn't allowed yet, it breaks versions of MSVC that
we still support for this branch.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Currently this breaks all.sh component test_memsan_constant_flow, just as
expected, as the current implementation is not constant flow.
This will be fixed in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This option allows to test the constant-flow nature of selected code, using
MemSan and the fundamental observation behind ctgrind that the set of
operations allowed on undefined memory by dynamic analysers is the same as the
set of operations allowed on secret data to avoid leaking it to a local
attacker via side channels, namely, any operation except branching and
dereferencing.
(This isn't the full story, as on some CPUs some instructions have variable
execution depending on the inputs, most notably division and on some cores
multiplication. However, testing that no branch or memory access depends on
secret data is already a good start.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Just move code from ssl_decrypt_buf() to the new cf_hmac() function and then
call cf_hmac() from there.
This makes the new cf_hmac() function used and validates that its interface
works for using it in ssl_decrypt_buf().
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The dummy implementation is not constant-flow at all for now, it's just
here as a starting point and a support for developing the tests and putting
the infrastructure in place.
Depending on the implementation strategy, there might be various corner cases
depending on where the lengths fall relative to block boundaries. So it seems
safer to just test all possible lengths in a given range than to use only a
few randomly-chosen values.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The condition is a complex and repeated a few times. There were already some
inconsistencies in the repetitions as some of them forgot about DES.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
inv_mod() already returns a specific error code if the value is not
invertible, so no need to check in advance that it is. Also, this is a
preparation for blinding the call to inv_mod(), which is made easier by
avoiding the redundancy (otherwise the call to gcd() would need to be blinded
too).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In the next commit, we'll need to draw a second random value, in order to
blind modular inversion. Having a function for that will avoid repetition.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Add the missing executable in the list of executables
to install.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
