This patch introduces some additional checks in the PK module for 64-bit
systems only. The problem is that the API functions in the PK
abstraction accept a size_t value for the hashlen, while the RSA module
accepts an unsigned int for the hashlen. Instead of silently casting
size_t to unsigned int, this change checks whether the hashlen overflows
an unsigned int and returns an error.
This change fixes a regression introduced by an earlier commit that
modified x509_crt_verify_top() to ensure that valid certificates
that are after past or future valid in the chain are processed. However
the change introduced a change in behaviour that caused the
verification flags BADCERT_EXPIRED and BADCERT_FUTURE to always be set
whenever there is a failure in the verification regardless of the cause.
The fix maintains both behaviours:
* Ensure that valid certificates after future and past are verified
* Ensure that the correct verification flags are set.
To do so, a temporary pointer to the first future or past valid
certificate is maintained while traversing the chain. If a truly valid
certificate is found then that one is used, otherwise if no valid
certificate is found and the end of the chain is reached, the program
reverts back to using the future or past valid certificate.
This patch modifies the function mbedtls_x509_crl_parse() to ensure
that a CRL in PEM format with trailing characters after the footer does
not result in the execution of an infinite loop.
This PR fixes a number of unused variable/function compilation warnings
that arise when using a config.h that does not define the macro
POLARSSL_PEM_PARSE_C.
In a USENIX WOOT '16 paper the authors warn about a security risk
of random Initialisation Vectors (IV) repeating values.
The MBEDTLS_SSL_AEAD_RANDOM_IV feature is affected by this risk and
it isn't compliant with RFC5116. Furthermore, strictly speaking it
is a different cipher suite from the TLS (RFC5246) point of view.
Removing the MBEDTLS_SSL_AEAD_RANDOM_IV feature to resolve the above
problems.
Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky and Philipp
Jovanovic, "Nonce-Disrespecting Adversaries: Practical Forgery Attacks
on GCM in TLS", USENIX WOOT '16
The PKCS#1 standard says nothing about the relation between P and Q
but many libraries guarantee P>Q and mbed TLS did so too in earlier
versions.
This commit restores this behaviour.
Fix implementation and documentation missmatch for the function
arguments to mbedtls_gcm_finish(). Also, removed redundant if condition
that always evaluates to true.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
The PKCS#1 standard says nothing about the relation between P and Q
but many libraries guarantee P>Q and mbed TLS did so too in earlier
versions.
This commit restores this behaviour.
Fix implementation and documentation missmatch for the function
arguments to mbedtls_gcm_finish(). Also, removed redundant if condition
that always evaluates to true.
The certificates are not valid according to the RFC, but are in wide
distribution across the internet. Hence the request to add a
compile-time flag to accept these certificates if wanted by the
application.
If POLARSSL_RELAXED_X509_DATE is enabled it will allow dates without
seconds, and allow dates with timezones (but doesn't actually use
the timezone).
Patch provided by OpenVPN.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
The server code parses the client hello extensions even when the
protocol is SSLv3 and this behaviour is non compliant with rfc6101.
Also the server sends extensions in the server hello and omitting
them may prevent interoperability problems.
In mingw32, net_usleep() was failing to sleep for the given period, and was
sleeping in microseconds, not milliseconds. Fix backported from mbed TLS 2.x of
using the Win32 Sleep() API call rather than using the timeout of select().
armar doesn't understand the syntax without dash. OTOH, the syntax with dash
is the only one specified by POSIX, and it's accepted by GNU ar, BSD ar (as
bundled with OS X) and armar, so it looks like the most portable syntax.
fixes#386
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.
See for example page 8 of
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
The previous constant probably came from a typo as it was 2^26 - 2^5 instead
of 2^36 - 2^5. Clearly the intention was to allow for a constant bigger than
2^32 as the ull suffix and cast to uint64_t show.
fixes#362
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
* mbedtls-1.3:
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. Just in case.
Added test case for pathlen constrains in intermediate certificates
* mbedtls-1.3:
Add ChangeLog entry for previous commit
cert_write : fix "Destination buffer is too small" error
Add ChangeLog entry for previous two commits
Test certificate "Server1 SHA1, key_usage" reissued.
Fix boolean values according to DER specs
Fix typo in an OID name
Disable reportedly broken assembly of Sparc(64)
ECHDE-PSK does not use a certificate
Actually ignore most non-fatal alerts
In BER encoding, any boolean with a non-zero value is considered as
TRUE. However, DER encoding require a value of 255 (0xFF) for TRUE.
This commit makes `mbedtls_asn1_write_bool` function uses `255` instead
of `1` for BOOLEAN values.
With this fix, boolean values are now reconized by OS X keychain (tested
on OS X 10.11).
Fixes#318.
Not a security issue as here we know the buffer is large enough (unless
something else if badly wrong in the code), and the value cast to int is less
than 2^16 (again, unless issues elsewhere).
Still changing to a more correct check as a matter of principle
backport of bc5e508
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
* mbedtls-1.3:
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.
There is only one length byte but for some reason we skipped two, resulting in
reading one byte past the end of the extension. Fortunately, even if that
extension is at the very end of the ClientHello, it can't be at the end of the
buffer since the ClientHello length is at most SSL_MAX_CONTENT_LEN and the
buffer has some more room after that for MAC and so on. So there is no
buffer overread.
Possible consequences are:
- nothing, if the next byte is 0x00, which is a comment first byte for other
extensions, which is why the bug remained unnoticed
- using a point format that was not offered by the peer if next byte is 0x01.
In that case the peer will reject our ServerKeyExchange message and the
handshake will fail.
- thinking that we don't have a common point format even if we do, which will
cause us to immediately abort the handshake.
None of these are a security issue.
The same bug was fixed client-side in fd35af15
Backport of f7022d1
This helps in the case where an intermediate certificate is directly trusted.
In that case we want to ignore what comes after it in the chain, not only for
performance but also to avoid false negatives (eg an old root being no longer
trusted while the newer intermediate is directly trusted).
see #220
backport of fdbdd72
This causes a compile-time error:
platform.c(157): error: #147: declaration is incompatible with "void (*polarssl_exit)(int)" (declared at line 179 of "platform.h")
If the top certificate occurs twice in trust_ca (for example) it would
not be good for the second instance to be checked with check_path_cnt
reduced twice!
library/dhm.c: accept (and ignore) optional privateValueLength for
PKCS#3 DH parameters.
PKCS#3 defines the ASN.1 encoding of a DH parameter set like this:
----------------
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL }
The fields of type DHParameter have the following meanings:
o prime is the prime p.
o base is the base g.
o privateValueLength is the optional private-value
length l.
----------------
See: ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc
This optional parameter was added in PKCS#3 version 1.4, released
November 1, 1993.
dhm.c currently doesn't cope well with PKCS#3 files that have this
optional final parameter included. i see errors like:
------------
dhm_parse_dhmfile returned -0x33E6
Last error was: -0x33E6 - DHM - The ASN.1 data is not formatted correctly : ASN1 - Actual length differs from expected lengt
------------
You can generate PKCS#3 files with this final parameter with recent
versions of certtool from GnuTLS:
certtool --generate-dh-params > dh.pem
The race was due to mpi_exp_mod storing a Montgomery coefficient in the
context (RM, RP, RQ).
The fix was verified with -fsanitize-thread using ssl_pthread_server and two
concurrent clients.
A more fine-grained fix should be possible, locking just enough time to check
if those values are OK and set them if not, rather than locking for the whole
mpi_exp_mod() operation, but it will be for later.
CFLAGS are reserved for external interaction via make variable, the
following should work:
$ make CFLAGS="-O3"
$ CFLAGS="-O3" make
1. Move internal flags to LOCAL_CFLAGS
2. Respect external CFLAGS
3. CFLAGS should be last compiler flags.
4. Default CFLAGS is -O optimization, remove OFLAGS.
5. Add WARNING_CFLAGS to control warning setting and enable to remove
if compiler does not support flags.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
LDFLAGS are reserved for external interaction via make variable, the
following should work:
$ make LDFLAGS="-L/xxx"
$ LDFLAGS="-L/xxx" make
1. Move internal flags to LOCAL_LDFLAGS
2. Respect external LDFLAGS
3. LDFLAGS should be last linkage flags.
Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
* rasp/mem-leak:
Fix another potential memory leak found by find-mem-leak.cocci.
Add a rule for another type of memory leak to find-mem-leak.cocci.
Fix a potential memory leak found by find-mem-leak.cocci.
Add a semantic patch to find potential memory leaks.
Fix whitespace of 369e6c20.
Apply the semantic patch rm-malloc-cast.cocci.
Add a semantic patch to remove casts of malloc.
Conflicts:
programs/ssl/ssl_server2.c
* rich/platform:
Remove dependency on sscanf in lib x509
Fix extra guard in memory_buffer_alloc
rebase from development
implemented macro overriding for polarssl_* library functions
fix bug introduced by the addition of snprintf and assert macro which caused tests to fail without polarssl_platform_c defined
add initial symbols to config and checks to check_config to allow use of macros to define standard functions
reformat and arrange additions to config alphabetically
add missing checks to check_config
add macro definition of assert using polarssl_exit
modify library/memory_buffer_alloc.c, benchmark.c and the tests main code to use polarssl_exit
add POLARSSL_PLATFORM_EXIT_ALT
modify scripts/* and tests/* to use polarssl_snprintf
modify programs/*.c to use polarssl_snprintf
modify library/debug.c to use polarssl_snprintf
modify library/x509*.c to use polarssl_snprintf
modify library/net.c to use polarssl_snprintf
modify oid.c to use polarssl_snprintf
add platform_set_snprintf
Conflicts:
library/memory_buffer_alloc.c
programs/pkey/pk_sign.c
programs/pkey/pk_verify.c
programs/pkey/rsa_sign_pss.c
programs/pkey/rsa_verify_pss.c
programs/ssl/ssl_client2.c
programs/ssl/ssl_pthread_server.c
programs/test/benchmark.c
programs/test/ssl_cert_test.c
Some people recommend using bit operations to avoid the compiler producing a
branch on `ret != 0`, but:
- this makes the code less readable,
- here I got a warning from some compilers about unsigned unary minus
- and anyway modern compilers don't produce a branch here, checked on x64 and
arm with various -O values.
