Matt Caswell [Tue, 18 Oct 2016 13:13:25 +0000 (14:13 +0100)]
Ensure that libcrypto and libssl do not unload until the process exits
Because we use atexit() to cleanup after ourselves, this will cause a
problem if we have been dynamically loaded and then unloaded again: the
atexit() handler may no longer be there.
Most modern atexit() implementations can handle this, however there are
still difficulties if libssl gets unloaded before libcrypto, because of
the atexit() callback that libcrypto makes to libssl.
The most robust solution seems to be to ensure that libcrypto and libssl
never unload. This is done by simply deliberately leaking a dlopen()
reference to them.
Matt Caswell [Sat, 15 Oct 2016 14:23:03 +0000 (15:23 +0100)]
Partial revert of 3d8b2ec42 to add back DSO_pathbyaddr
Commit 3d8b2ec42 removed various unused functions. However now we need to
use one of them! This commit resurrects DSO_pathbyaddr(). We're not going to
resurrect the Windows version though because what we need to achieve can be
done a different way on Windows.
Matt Caswell [Wed, 2 Nov 2016 09:14:51 +0000 (09:14 +0000)]
Fail if an unrecognised record type is received
TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but
TLS 1.2 says you MUST send an unexpected message alert. We swap to the
TLS 1.2 behaviour for all protocol versions to prevent issues where no
progress is being made and the peer continually sends unrecognised record
types, using up resources processing them.
Richard Levitte [Tue, 1 Nov 2016 14:03:38 +0000 (15:03 +0100)]
Test recipes: remove duplicate OpenSSL::Test usage
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1815)
(cherry picked from commit 2c4a3f938ca378d2017275d299f02512b232ceaf)
Matt Caswell [Wed, 2 Nov 2016 10:34:12 +0000 (10:34 +0000)]
Fix read_ahead
The function ssl3_read_n() takes a parameter |clearold| which, if set,
causes any old data in the read buffer to be forgotten, and any unread data
to be moved to the start of the buffer. This is supposed to happen when we
first read the record header.
However, the data move was only taking place if there was not already
sufficient data in the buffer to satisfy the request. If read_ahead is set
then the record header could be in the buffer already from when we read the
preceding record. So with read_ahead we can get into a situation where even
though |clearold| is set, the data does not get moved to the start of the
read buffer when we read the record header. This means there is insufficient
room in the read buffer to consume the rest of the record body, resulting in
an internal error.
This commit moves the |clearold| processing to earlier in ssl3_read_n()
to ensure that it always takes place.
Benjamin Kaduk [Mon, 26 Sep 2016 20:30:42 +0000 (15:30 -0500)]
Fix grammar-o in CONTRIBUTING
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1625)
(cherry picked from commit e4d94269a5a41594852dc60716500580f1d47cef)
Richard Levitte [Fri, 28 Oct 2016 21:35:37 +0000 (23:35 +0200)]
HPUX: Add the forgotten $(DSTDIR) when linking DSOs
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1802)
(cherry picked from commit f46661de7806b5bae507d17185bda2bafd6c20d8)
Matt Caswell [Fri, 14 Oct 2016 12:07:00 +0000 (13:07 +0100)]
Ensure we have length checks for all extensions
The previous commit inspired a review of all the length checks for the
extension adding code. This adds more robust checks and adds checks where
some were missing previously. The real solution for this is to use WPACKET
which is currently in master - but that cannot be applied to release
branches.
Matt Caswell [Fri, 14 Oct 2016 10:49:06 +0000 (11:49 +0100)]
Fix length check writing status request extension
The status request extension did not correctly check its length, meaning
that writing the extension could go 2 bytes beyond the buffer size. In
practice this makes little difference because, due to logic in buffer.c the
buffer is actually over allocated by approximately 5k!
Matt Caswell [Thu, 27 Oct 2016 12:46:57 +0000 (13:46 +0100)]
Add a test for BIO_read() returning 0 in SSL_read() (and also for write)
A BIO_read() 0 return indicates that a failure occurred that may be
retryable. An SSL_read() 0 return indicates a non-retryable failure. Check
that if BIO_read() returns 0, SSL_read() returns <0. Same for SSL_write().
The asyncio test filter BIO already returns 0 on a retryable failure so we
build on that.
Matt Caswell [Fri, 21 Oct 2016 12:25:19 +0000 (13:25 +0100)]
A zero return from BIO_read()/BIO_write() could be retryable
A zero return from BIO_read()/BIO_write() could mean that an IO operation
is retryable. A zero return from SSL_read()/SSL_write() means that the
connection has been closed down (either cleanly or not). Therefore we
should not propagate a zero return value from BIO_read()/BIO_write() back
up the stack to SSL_read()/SSL_write(). This could result in a retryable
failure being treated as fatal.
Richard Levitte [Wed, 26 Oct 2016 16:04:40 +0000 (18:04 +0200)]
VMS: tell the C compiler to use the ISO C94 standard
The current version of the VMS compiler provides C99 features,
strictly language wise. Unfortunately, even the most recent standard
library isn't fully updated for that standard, so we need to use an
earlier standard that the compiler supports.
Most importantly, this affects the __STDC_VERSION__ value, which the
compiler unfortunately currently defaults to 199901L. With this
change we won't have to give VMS special treatment when looking for
features based on that macro.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1785)
(cherry picked from commit 4f3015bb30b7d95bb97408776b70e6a35fb91e8a)
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1584)
(cherry picked from commit a8a8a917c0c0d36162fdc0cbf84ab17282cef3e9)
David Woodhouse [Wed, 12 Oct 2016 22:10:37 +0000 (23:10 +0100)]
Disable encrypt_then_mac negotiation for DTLS.
I use the word 'negotiation' advisedly. Because that's all we were doing.
We negotiated it, set the TLS1_FLAGS_ENCRYPT_THEN_MAC flag in our data
structure, and then utterly ignored it in both dtls_process_record()
and do_dtls1_write().
Turn it off for 1.1.0; we'll fix it for 1.1.1 and by the time that's
released, hopefully 1.1.0b will be ancient history.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
Richard Levitte [Wed, 28 Sep 2016 21:39:18 +0000 (23:39 +0200)]
If an engine comes up explicitely, it must also come down explicitely
In apps/apps.c, one can set up an engine with setup_engine().
However, we freed the structural reference immediately, which means
that for engines that don't already have a structural reference
somewhere else (because it's a built in engine), we end up returning
an invalid reference.
Instead, the function release_engine() is added, and called at the end
of the routines that call setup_engine().
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1643)
(cherry picked from commit dd1abd4462e4e4fa84b8f8de2ec70375f9b0e191)
Mat [Mon, 3 Oct 2016 03:40:32 +0000 (05:40 +0200)]
Do not set load_crypto_strings_inited when OPENSSL_NO_ERR is defined
Only set the load_crypto_strings_inited to 1 when err_load_crypto_strings_int was called.
This solves the following issue:
- openssl is built with no-err
- load_crypto_strings_inited is set to 1 during the OPENSSL_init_crypto call
- During the cleanup: OPENSSL_cleanup, err_free_strings_int is called because load_crypto_strings_inited == 1
- err_free_strings_int calls do_err_strings_init because it has never been called
- Now do_err_strings_init calls OPENSSL_init_crypto
- But since we are in the cleanup (stopped == 1) this results in an error:
CRYPTOerr(CRYPTO_F_OPENSSL_INIT_CRYPTO, ERR_R_INIT_FAIL);
- which then tries to initialize everything we are trying to clean up: ERR_get_state, ossl_init_thread_start, etc Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1654)
(cherry picked from commit a1f2b0e6e07a53c0ae2c81cba319b90e54210cd6)
Andrea Grandi [Tue, 18 Oct 2016 09:26:38 +0000 (10:26 +0100)]
Add missing .pod extension to EVP_PKEY_CTX_set_tls1_prf_md
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit efba60ca7ab72cae62baad2aaaf2da32d1093c38)
Matt Caswell [Wed, 12 Oct 2016 15:43:03 +0000 (16:43 +0100)]
Ensure we handle len == 0 in ERR_err_string_n
If len == 0 in a call to ERR_error_string_n() then we can read beyond the
end of the buffer. Really applications should not be calling this function
with len == 0, but we shouldn't be letting it through either!
Thanks to Agostino Sarubbo for reporting this issue. Agostino's blog on
this issue is available here:
https://blogs.gentoo.org/ago/2016/10/14/openssl-libcrypto-stack-based-buffer-overflow-in-err_error_string_n-err-c/
Tomas Mraz [Wed, 12 Oct 2016 12:32:05 +0000 (14:32 +0200)]
Engine afalg: properly set operation type also on big endian.
Copy the whole ALG_OP_TYPE to CMSG_DATA.
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 574cffd5d5b8f57f811c8d36d930205041deedee)
Xiaoyin Liu [Mon, 26 Sep 2016 01:28:02 +0000 (21:28 -0400)]
Fix typo
I think the second "VC-WIN32" should be "VC-WIN64". Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
CLA: trivial
Richard Levitte [Wed, 12 Oct 2016 22:08:55 +0000 (00:08 +0200)]
Remove automatic RPATH - adapt shlib_wrap.sh
Looking for something starting with '-Wl,-rpath,' isn't good enough,
as someone might give something like '-Wl,--enable-new-dtags,-rpath,/PATH'.
Looking for ',-rpath,' should be safe enough.
We could remove the preloading stuff entirely, but just in case the
user has chosen to given RPATH setting arguments at configuration,
we'd better make sure testing will still work. Fair warning, there
are some configuration options that do not work with preloaded OpenSSL
libraries, such as the sanity checking ones.
Richard Levitte [Wed, 12 Oct 2016 15:05:35 +0000 (17:05 +0200)]
Remove automatic RPATH - add user rpath support
Make Configure recognise -rpath and -R to support user added rpaths
for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the
Unix Makefile, which the users can use as follows:
Richard Levitte [Wed, 12 Oct 2016 15:18:11 +0000 (17:18 +0200)]
Remove automatic RPATH
Before OpenSSL 1.1.0, binaries were installed in a non-standard
location by default, and runpath directories were therefore added in
those binaries, to make sure the executables would be able to find the
shared libraries they were linked with.
With OpenSSL 1.1.0 and on, binaries are installed in standard
directories by default, and the addition of runpath directories is
therefore not needed any more.
Rich Salz [Wed, 12 Oct 2016 19:49:06 +0000 (15:49 -0400)]
RT is put out to pasture
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1702)
(cherry picked from commit 7954dced19a7e59e7055eab95a981fa943c7d100)
The original X509_NAME decode free code was buggy: this
could result in double free or leaks if a malloc failure
occurred.
Simplify and fix the logic.
Thanks to Guido Vranken for reporting this issue.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1691)
(cherry picked from commit 6dcba070a94b1ead92f3e327cf207a0b7db6596f)
Richard Levitte [Wed, 28 Sep 2016 19:28:00 +0000 (21:28 +0200)]
apps/apps.c: initialize and de-initialize engine around key loading
Before loading a key from an engine, it may need to be initialized.
When done loading the key, we must de-initialize the engine.
(if the engine is already initialized somehow, only the reference
counter will be incremented then decremented)
Matt Caswell [Fri, 23 Sep 2016 15:58:11 +0000 (16:58 +0100)]
Fix Use After Free for large message sizes
The buffer to receive messages is initialised to 16k. If a message is
received that is larger than that then the buffer is "realloc'd". This can
cause the location of the underlying buffer to change. Anything that is
referring to the old location will be referring to free'd data. In the
recent commit c1ef7c97 (master) and 4b390b6c (1.1.0) the point in the code
where the message buffer is grown was changed. However s->init_msg was not
updated to point at the new location.
Russian GOST ciphersuites are vulnerable to the KCI attack because they use
long-term keys to establish the connection when ssl client authorization is
on. This change brings the GOST implementation into line with the latest
specs in order to avoid the attack. It should not break backwards
compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
Matt Caswell [Sat, 10 Sep 2016 20:24:40 +0000 (21:24 +0100)]
Fix a hang with SSL_peek()
If while calling SSL_peek() we read an empty record then we go into an
infinite loop, continually trying to read data from the empty record and
never making any progress. This could be exploited by a malicious peer in
a Denial Of Service attack.
Matt Caswell [Fri, 9 Sep 2016 09:53:39 +0000 (10:53 +0100)]
Fix a mem leak in NPN handling
If a server sent multiple NPN extensions in a single ClientHello then a
mem leak can occur. This will only happen where the client has requested
NPN in the first place. It does not occur during renegotiation. Therefore
the maximum that could be leaked in a single connection with a malicious
server is 64k (the maximum size of the ServerHello extensions section). As
this is client side, only occurs if NPN has been requested and does not
occur during renegotiation this is unlikely to be exploitable.
Matt Caswell [Fri, 9 Sep 2016 09:08:45 +0000 (10:08 +0100)]
Fix OCSP Status Request extension unbounded memory growth
A malicious client can send an excessively large OCSP Status Request
extension. If that client continually requests renegotiation,
sending a large OCSP Status Request extension each time, then there will
be unbounded memory growth on the server. This will eventually lead to a
Denial Of Service attack through memory exhaustion. Servers with a
default configuration are vulnerable even if they do not support OCSP.
Builds using the "no-ocsp" build time option are not affected.
I have also checked other extensions to see if they suffer from a similar
problem but I could not find any other issues.
Richard Levitte [Wed, 21 Sep 2016 12:44:42 +0000 (14:44 +0200)]
test/x509aux.c: Fix argv loop
There are cases when argc is more trustable than proper argv termination.
Since we trust argc in all other test programs, we might as well treat it
the same way in this program.
Matt Caswell [Mon, 19 Sep 2016 10:57:07 +0000 (11:57 +0100)]
Excessive allocation of memory in dtls1_preprocess_fragment()
This issue is very similar to CVE-2016-6307 described in the previous
commit. The underlying defect is different but the security analysis and
impacts are the same except that it impacts DTLS.
A DTLS message includes 3 bytes for its length in the header for the
message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect TLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
Matt Caswell [Mon, 19 Sep 2016 10:39:21 +0000 (11:39 +0100)]
Excessive allocation of memory in tls_get_message_header()
A TLS message includes 3 bytes for its length in the header for the message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect DTLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
projects / openssl / log