Re: OpenSSL Security Advisory
On Thursday, 25 March 2021 15:03:24 CET, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [25 March 2021] = NULL pointer deref in signature_algorithms processing (CVE-2021-3449) = Severity: High An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was developed by Peter Kästle and Samuel Sapalski from Nokia. I've created a stand-alone reproducer for it using tlsfuzzer: git clone https://github.com/tlsfuzzer/tlsfuzzer.git cd tlsfuzzer # won't be necessary after https://github.com/tlsfuzzer/tlsfuzzer/pull/748 is merged: git checkout sig-algs-tests # install dependencies: python3 -m venv py3-venv py3-venv/bin/pip install --pre tlslite-ng # run the reproducer: PYTHONPATH=. py3-venv/bin/python3 scripts/test-sig-algs-renegotiation-resumption.py -h -p In case the server has renegotiation disabled, use the --no-renego option. In case the server doesn't require presence of signature_algorithms extension when signature_algorithms_cert are present (like in case of OpenSSL 1.0.2), use the --sig-algs-drop-ok option. If everything went fine, and the server didn't crash, the test will print summary like this: TOTAL: 12 SKIP: 0 PASS: 12 XFAIL: 0 FAIL: 0 XPASS: 0 It's not necessary to install dependencies to a virtual environment, but that setup is described in the official docs: https://tlsfuzzer.readthedocs.io/en/latest/quickstart.html -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Re: OpenSSL Security Advisory
On 10/09/2020 16:14, Jakob Bohm via openssl-users wrote: > On 2020-09-10 09:03, Tomas Mraz wrote: >> On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: >>> Wouldn't a more reasonable response for 1.0.2 users have been to >>> force on >>> SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected >>> cipher >>> suites >>> and telling affected people to recompile with the fix off? >> >> You seem to be mixing two different affected things. One is the static >> DH ciphersuites. There is no remediation for these except for not using >> them. Fortunately they are not really used by anyone. This can be >> achieved on the server side by simply not providing the DH certificate. >> On the client side they can be dropped from the ciphers string. This is >> the "deprecating affected cipher suites" change part. >> >> On the other hand the reuse of DH key for ephemeral DH can be only >> disabled by setting SSL_OP_SINGLE_DH_USE by the calling server >> application. This is the part relevant for wider audience. >> >> So yes, both issues can be remediated by application calling the >> OpenSSL library. On the other hand it is not always possible to change >> the application so we also provide fix to premium support customers in >> terms of changing the openssl code. >> > > > The advisory didn't include this clarification, Isn't the text below from the advisory more-or-less what Tomas said? "OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used ... Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list." > and didn't state if > 1.0.2w fixes the DHE case by doing what 1.1.x does and act like > SSL_OP_SINGLE_DH_USE is always set. The advisory says that SSL_OP_SINGLE_DH_USE was made the default in 1.0.2f: "OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701." Matt
Re: OpenSSL Security Advisory
On 2020-09-10 09:03, Tomas Mraz wrote: On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? You seem to be mixing two different affected things. One is the static DH ciphersuites. There is no remediation for these except for not using them. Fortunately they are not really used by anyone. This can be achieved on the server side by simply not providing the DH certificate. On the client side they can be dropped from the ciphers string. This is the "deprecating affected cipher suites" change part. On the other hand the reuse of DH key for ephemeral DH can be only disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. So yes, both issues can be remediated by application calling the OpenSSL library. On the other hand it is not always possible to change the application so we also provide fix to premium support customers in terms of changing the openssl code. The advisory didn't include this clarification, and didn't state if 1.0.2w fixes the DHE case by doing what 1.1.x does and act like SSL_OP_SINGLE_DH_USE is always set. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: OpenSSL Security Advisory
On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: > Wouldn't a more reasonable response for 1.0.2 users have been to > force on > SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected > cipher > suites > and telling affected people to recompile with the fix off? You seem to be mixing two different affected things. One is the static DH ciphersuites. There is no remediation for these except for not using them. Fortunately they are not really used by anyone. This can be achieved on the server side by simply not providing the DH certificate. On the client side they can be dropped from the ciphers string. This is the "deprecating affected cipher suites" change part. On the other hand the reuse of DH key for ephemeral DH can be only disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. So yes, both issues can be remediated by application calling the OpenSSL library. On the other hand it is not always possible to change the application so we also provide fix to premium support customers in terms of changing the openssl code. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: OpenSSL Security Advisory
On 2020-09-09 14:39, OpenSSL wrote: OpenSSL Security Advisory [09 September 2020] = Raccoon Attack (CVE-2020-1968) == Severity: Low The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and does not implement any "static" DH ciphersuites. OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used. These static "DH" ciphersuites are ones that start with the text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these ciphersuites all start with "TLS_DH_" but excludes those that start with "TLS_DH_anon_". OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701. Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare. Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure that affected ciphersuites are disabled through runtime configuration. Also note that the affected ciphersuites are only available on the server side if a DH certificate has been configured. These certificates are very rarely used and for this reason this issue has been classified as LOW severity. This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to allow co-ordinated disclosure with other implementations. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20200909.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: OpenSSL Security Advisory
That makes sense, thank you all.
Re: OpenSSL Security Advisory
On 21/04/2020 20:46, Sam Roberts wrote:
> The announcement claims that this affects SSL_check_chain().
>
> Is that an exhaustive list? If an application does NOT call that
> function, does this mean the vulnerability is not exploitable?
As Ben says - this is correct.
>
> I ask because the the fixed function tls1_check_sig_alg is called by
> tls1_check_chain, and that is called directly by SSL_check_chain, but
> it is also called by tls1_set_cert_validity, and that is called from
You will note that tls1_check_sig_alg is only affected if we go down the
TLSv1.3 codepath. However tls1_set_cert_validity() only has one caller
and it looks like this:
if (SSL_IS_TLS13(s)) {
...
} else {
tls1_set_cert_validity(s);
ssl_set_masks(s);
}
So it is only ever called in a non-TLSv1.3 handshake.
Matt
> inside the tls state machine, but with different parameters, so its a
> bit hard to see if it is affected or not.
>
> Thanks,
> Sam
>
> On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote:
>>
> OpenSSL Security Advisory [21 April 2020]
> =
>
> Segmentation fault in SSL_check_chain (CVE-2020-1967)
> =
>
> Severity: High
>
> Server or client applications that call the SSL_check_chain() function during
> or
> after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
> result of incorrect handling of the "signature_algorithms_cert" TLS extension.
> The crash occurs if an invalid or unrecognised signature algorithm is received
> from the peer. This could be exploited by a malicious peer in a Denial of
> Service attack.
>
> OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This
> issue did not affect OpenSSL versions prior to 1.1.1d.
>
> Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g
>
> This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April
> 2020. It was found using the new static analysis pass being implemented in
> GCC,
> -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin
> Kaduk.
>
> Note
> =
>
> This issue did not affect OpenSSL 1.0.2 however these versions are out of
> support and no longer receiving public updates. Extended support is available
> for premium support customers: https://www.openssl.org/support/contracts.html
>
> This issue did not affect OpenSSL 1.1.0 however these versions are out of
> support and no longer receiving updates.
>
> Users of these versions should upgrade to OpenSSL 1.1.1.
>
> References
> ==
>
> URL for this Security Advisory:
> https://www.openssl.org/news/secadv/20200421.txt
>
> Note: the online version of the advisory may be updated with additional
> details
> over time.
>
> For details of OpenSSL severity classifications please see:
> https://www.openssl.org/policies/secpolicy.html
>
Re: OpenSSL Security Advisory
On Tue, Apr 21, 2020 at 12:46:43PM -0700, Sam Roberts wrote: > The announcement claims that this affects SSL_check_chain(). > > Is that an exhaustive list? If an application does NOT call that > function, does this mean the vulnerability is not exploitable? That is correct (speaking only in terms of public APIs). > I ask because the the fixed function tls1_check_sig_alg is called by > tls1_check_chain, and that is called directly by SSL_check_chain, but > it is also called by tls1_set_cert_validity, and that is called from > inside the tls state machine, but with different parameters, so its a > bit hard to see if it is affected or not. As you note, the valid call chains are a bit convoluted, but the relevant codepath is only exercised for TLS 1.3 and SSL_check_chain(). -Ben
Re: OpenSSL Security Advisory
The announcement claims that this affects SSL_check_chain(). Is that an exhaustive list? If an application does NOT call that function, does this mean the vulnerability is not exploitable? I ask because the the fixed function tls1_check_sig_alg is called by tls1_check_chain, and that is called directly by SSL_check_chain, but it is also called by tls1_set_cert_validity, and that is called from inside the tls state machine, but with different parameters, so its a bit hard to see if it is affected or not. Thanks, Sam On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > OpenSSL Security Advisory [21 April 2020] > = > > Segmentation fault in SSL_check_chain (CVE-2020-1967) > = > > Severity: High > > Server or client applications that call the SSL_check_chain() function during > or > after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a > result of incorrect handling of the "signature_algorithms_cert" TLS extension. > The crash occurs if an invalid or unrecognised signature algorithm is received > from the peer. This could be exploited by a malicious peer in a Denial of > Service attack. > > OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This > issue did not affect OpenSSL versions prior to 1.1.1d. > > Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g > > This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April > 2020. It was found using the new static analysis pass being implemented in > GCC, > - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin > Kaduk. > > Note > = > > This issue did not affect OpenSSL 1.0.2 however these versions are out of > support and no longer receiving public updates. Extended support is available > for premium support customers: https://www.openssl.org/support/contracts.html > > This issue did not affect OpenSSL 1.1.0 however these versions are out of > support and no longer receiving updates. > > Users of these versions should upgrade to OpenSSL 1.1.1. > > References > == > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20200421.txt > > Note: the online version of the advisory may be updated with additional > details > over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g > RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t > vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt > 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis > Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl > aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ > vj2rIjoJHRj0EXqXhHoABqBHedilJQ== > =AXyP > -END PGP SIGNATURE-
Re: OpenSSL Security Advisory
Having reviewed the git commit for 1.1.1 I notice the following issue: The environment variables that usually point to the secure administrator directories (such as "Program Files") are not themselves secured, and not intended as a secure means of obtaining these directory locations, which are (by definition) subject to change via system configuration (initial or later!). There are official system library calls to obtain the actual locations as follows: 1. If looking for the location where a program is itself installed, use the GetModuleFilenameW(own-hinstance) call to obtain the path to once own DLL or EXE. This automatically adapts to wherever the DLL or EXE is copied or moved. This is a kernel32.dll API and returns a location with security very close to that of the binary itself.The name returned is from the in-process instance of the dynamic linker. 2. If looking for the location where the running program's top level file (such as openssl.exe or some-program-loading-an-openssl-using-plugin.exe), use that same call but pass NULL for the hinstance parameter. 3. If looking for the system-wide secured "/etc" directory, use the GetSystemDirectoryW() call and append the fixed string "\\Drivers\\etc" . This location is permanently restricted to the system administrators and already contains a few traditional unix files such as "hosts". This too is a kernel32.dll API. The name returned is from a system internal value set during OS boot. 4. If looking for the directory intended to hold system-wide configuration and data files, use the SHGetFolderPathW(CSIDL_COMMON_APPDATA) API from shfolder.dll or shell32.dll (fallback) to ask for the "all-users data directory", append a company/project name (such as "\\OpenSSL") and specify an appropriate ACL in the security argument to CreateDirectoryW() (if the directory doesn't already exist with a user-modified ACL, CreateDirectoryW will atomically detect this and return a specific error code in the per thread GetLastError() variable).Note that mkdir() only creates one level of directories per invocation and you may want different ACLs when creating missing parent directories. The values returned by SHGetFolderPathW() are typically from one or more Administrator controlled registry keys. Some of the above APIs may require their return value to be canonicalized via the GetFullPathNameW() API in corner cases, retaining the result in a global variable is advisable. On 30/07/2019 16:27, OpenSSL wrote: OpenSSL Security Advisory [30 July 2019] Windows builds with insecure path defaults (CVE-2019-1552) == Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
RE: OpenSSL Security Advisory
Thanks. -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: Wednesday, February 27, 2019 11:18 AM To: openssl-users@openssl.org Subject: Re: OpenSSL Security Advisory On 27/02/2019 18:43, Scott Neugroschl wrote: > Is this a client-side or server-side vulnerability? Or does it matter? It can apply to either side. Matt > > Thanks, > > ScottN > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 > 583-2874|Fax 805 583-0124 | > > > > > -Original Message- > From: openssl-users On Behalf Of OpenSSL > Sent: Tuesday, February 26, 2019 6:59 AM > To: openssl-proj...@openssl.org; OpenSSL User Support ML > ; OpenSSL Announce ML > > Subject: OpenSSL Security Advisory > > OpenSSL Security Advisory [26 February 2019] > > > 0-byte record padding oracle (CVE-2019-1559) > > > Severity: Moderate > > If an application encounters a fatal protocol error and then calls > SSL_shutdown() twice (once to send a close_notify, and once to receive one) > then OpenSSL can respond differently to the calling application if a 0 byte > record is received with invalid padding compared to if a 0 byte record is > received with an invalid MAC. If the application then behaves differently > based on that in a way that is detectable to the remote peer, then this > amounts to a padding oracle that could be used to decrypt data. > > In order for this to be exploitable "non-stitched" ciphersuites must be in > use. > Stitched ciphersuites are optimised implementations of certain commonly used > ciphersuites. Also the application must call SSL_shutdown() twice even if a > protocol error has occurred (applications should not do this but some do > anyway). > > This issue does not impact OpenSSL 1.1.1 or 1.1.0. > > OpenSSL 1.0.2 users should upgrade to 1.0.2r. > > This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod > Aviram, with additional investigation by Steven Collison and Andrew Hourselt. > It was reported to OpenSSL on 10th December 2018. > > Note > > > OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. > Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end > on 11th September 2019. Users of these versions should upgrade to OpenSSL > 1.1.1. > > References > == > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20190226.txt > > Note: the online version of the advisory may be updated with additional > details over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html >
Re: OpenSSL Security Advisory
On 27/02/2019 18:43, Scott Neugroschl wrote: > Is this a client-side or server-side vulnerability? Or does it matter? It can apply to either side. Matt > > Thanks, > > ScottN > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 > 583-2874|Fax 805 583-0124 | > > > > > -Original Message- > From: openssl-users On Behalf Of OpenSSL > Sent: Tuesday, February 26, 2019 6:59 AM > To: openssl-proj...@openssl.org; OpenSSL User Support ML > ; OpenSSL Announce ML > > Subject: OpenSSL Security Advisory > > OpenSSL Security Advisory [26 February 2019] > > > 0-byte record padding oracle (CVE-2019-1559) > > > Severity: Moderate > > If an application encounters a fatal protocol error and then calls > SSL_shutdown() twice (once to send a close_notify, and once to receive one) > then OpenSSL can respond differently to the calling application if a 0 byte > record is received with invalid padding compared to if a 0 byte record is > received with an invalid MAC. If the application then behaves differently > based on that in a way that is detectable to the remote peer, then this > amounts to a padding oracle that could be used to decrypt data. > > In order for this to be exploitable "non-stitched" ciphersuites must be in > use. > Stitched ciphersuites are optimised implementations of certain commonly used > ciphersuites. Also the application must call SSL_shutdown() twice even if a > protocol error has occurred (applications should not do this but some do > anyway). > > This issue does not impact OpenSSL 1.1.1 or 1.1.0. > > OpenSSL 1.0.2 users should upgrade to 1.0.2r. > > This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod > Aviram, with additional investigation by Steven Collison and Andrew Hourselt. > It was reported to OpenSSL on 10th December 2018. > > Note > > > OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. > Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end > on 11th September 2019. Users of these versions should upgrade to OpenSSL > 1.1.1. > > References > == > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20190226.txt > > Note: the online version of the advisory may be updated with additional > details over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html >
RE: OpenSSL Security Advisory
Is this a client-side or server-side vulnerability? Or does it matter? Thanks, ScottN --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -Original Message- From: openssl-users On Behalf Of OpenSSL Sent: Tuesday, February 26, 2019 6:59 AM To: openssl-proj...@openssl.org; OpenSSL User Support ML ; OpenSSL Announce ML Subject: OpenSSL Security Advisory -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [26 February 2019] 0-byte record padding oracle (CVE-2019-1559) Severity: Moderate If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). This issue does not impact OpenSSL 1.1.1 or 1.1.0. OpenSSL 1.0.2 users should upgrade to 1.0.2r. This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod Aviram, with additional investigation by Steven Collison and Andrew Hourselt. It was reported to OpenSSL on 10th December 2018. Note OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th September 2019. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20190226.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx1U+gACgkQ2cTSbQ5g RJFnlAf/U9yZtCz59BjgD0Kh7Eya5KxlmUWItdBu1r3DwbY4KDgL/Wwh4UxG3Qim D7Ht5Xsta4iAywrMRI/iPEdEQct8pcpWjq4/65lEbTYjToEnNWhIeWHH/Lw3Jfza gcVpIfbWoWc7OL7U4uPQuGWcb/PO8fJXF+HcCdZ+kIuut0peMSgN5sK/wBnmSdsM +sJXCei+jwVy/9WvCBMOooX7D8oerJ6NX12n2cNAYH/K7e2deiPZ7D/HB7T9MSv/ BgOi1UqFzBxcsNhFpY5NMTHG8pl0bmS0OiZ9bThN0YHwxFVJz6ZsVX/L5cYOAbm/ mJAdDE24XMmUAOlVZrROzCZKXADx/A== =8h8L -END PGP SIGNATURE-
Re: OpenSSL Security Advisory
The redhat podcast with Mark (Cox) probably answers this best; http://bit.ly/Th64oP On Thu, Jun 5, 2014 at 12:04 PM, Juha Saarinen j...@saarinen.org wrote: Hi Steve, That’s quite a few in one go - is this due to greater testing of OpenSSL and more scrutiny of the code by the community? Of the flaws listed, which is the one of most concern? This kind of begs the question what to do with all those embedded systems that run older versions of OpenSSL. Thanks — Juha On 5/06/2014, at 11:54 pm, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert
Re: OpenSSL Security Advisory
On 6/5/2014 11:31 PM, Green, Gatewood wrote: Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems to be missing the symbol BN_consttime_swap. By the way, the BN_consttime_swap implementation in 1.0.1g (still downloading 1.0.1h) doesn't seem to completely match its description: - If nwords is 0, the code will overflow the input buffers by pretending that nwords is 10. Adding case 0 to the bottom of the switch should fix that. - If BN_ULONG is not exactly BN_BITS2 in size, the condition may also bit mishandled, is this property guaranteed by the type definitions on all platforms? - Other than the assert checking the power-of-2 assumption, the code should work with any condition in the range 0 to (1 (BN_BITS32-1)) inclusive, but not for larger values. - The only thing that needs a and b to be different variables is the assert checking that condition. At least this is how I read the code. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
In 0.9.8za, there is a missing compiler directive to include limits.h in ssl/s3_pkt.c. Without it, compiling fails on SPARC Solaris 10 with INT_MAX being undefined on line 536, which looks like: OPENSSL_assert(s-s3-wnum INT_MAX); It appears that 1.0.0m has the same problem. I haven't looked at 1.0.1h as yet. OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack
Re: OpenSSL Security Advisory
In 0.9.8za at least, there is a missing directive to include limits.h. Without it, compilation fails on SPARC Solaris 10 with INT_MAXbeing undefined on line 536, which looks like: OPENSSL_assert(s-s3-wnum INT_MAX); It appears that 1.0.0m has the same problem. I haven't looked at 1.0.1h as yet. OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval
Re: OpenSSL Security Advisory
Hi Steve, That’s quite a few in one go - is this due to greater testing of OpenSSL and more scrutiny of the code by the community? Of the flaws listed, which is the one of most concern? This kind of begs the question what to do with all those embedded systems that run older versions of OpenSSL. Thanks — Juha On 5/06/2014, at 11:54 pm, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za
RE: OpenSSL Security Advisory
Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems to be missing the symbol BN_consttime_swap. Woody Gatewood C Green Jr (Woody) Principal Software Engineer, Product Security Champion SIEM Engineering McAfee. Part of Intel Security. Direct: 208.552.8269 Mobile: 208.206.7455 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of OpenSSL Sent: Thursday, June 05, 2014 5:54 AM To: openssl-...@openssl.org; openssl-users@openssl.org; openssl-annou...@openssl.org Subject: OpenSSL Security Advisory -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix
Re: OpenSSL Security Advisory
Ah, of course! I was so focused on not accessing that routine and not being able to just link in the obj files that the obvious solution of using the library properly escaped me! Thanks. After a Visual Studio 2012 build in directory: E:\usr_local\src\openssl-1.0.1f_32 I then was able put that change in and to compile and link very easily: cl -IE:\usr_local\src\openssl-1.0.1f_32\inc32 heartbleed.c /c link heartbleed.obj E:\usr_local\src\openssl-1.0.1f_32\out32dll\libeay32.lib E:\usr_local\src\openssl-1.0.1f_32\out32dll\ssleay32.lib I put those two dll files (ssleay32.dll and libeay32.dll) in my directory with the new exe from the build and it worked just fine. Thanks again to Tim Hudson, and of course to Rob Stradling for sharing the utility, Steve... On Fri, Apr 11, 2014 at 10:58 PM, Tim Hudson t...@cryptsoft.com wrote: On 11/04/2014 10:38 PM, Steven Kneizys wrote: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. The work around is trivial if you wanted to do that. Change to use the SSL_get_ssl_method function. This line: if (ssl3_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Simply becomes: if (SSL_get_ssl_method(v_ssl)-ssl_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Tim. -- Steve Kneizys Senior Business Process Engineer Voice: (610) 256-1396 [For Emergency Service (888)864-3282] Ferrilli Information Group -- Quality Service and Solutions for Higher Education web: http://www.ferrilli.com/ http://www.figsolutions.com/ Making you a success while exceeding your expectations.
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
some nice pictures how the bug works: http://www.xkcd.com/1354/ HIH matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 11/04/2014 12:58 AM, Viktor Dukhovni wrote: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 If you are using s_client for testing then you should add the -msg option and see what is being sent. Responding to a correctly formed heartbeat request is not an error - it is an indication that the server remains configured with heartbeat support. For example repeating that command as: (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 -msg And you can see the decoded heartbeat request and response - all with legal length values - 0x12 indicating 18 bytes of payload followed by the required 16 bytes of padding all exactly adding up to match the record size (3+18+16=37 which is the 0x0025 length field). HEARTBEATING ??? [length 0005] 18 03 03 00 3d TLS 1.2 [length 0025], HeartbeatRequest 01 00 12 00 00 c5 3c e4 48 f7 55 a8 83 62 df 03 a7 6b c2 48 05 60 e9 48 9e c1 6e 69 f4 fd 48 60 a9 35 bd 0c c3 ??? [length 0005] 18 03 03 00 3d TLS 1.2 [length 0025], HeartbeatResponse 02 00 12 00 00 c5 3c e4 48 f7 55 a8 83 62 df 03 a7 6b c2 48 05 75 07 79 df 92 dd b2 3c a6 9d 73 12 54 9c 66 57 read R BLOCK A number of users have provided various tools for testing whether or not an exploit is present. None of these tools are officially supported or blessed so are all use-at-your-own-risk. A couple of the tools others have mentioned already on this list are: https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl https://gist.github.com/robstradling/10363389 There are a whole range of checking tools that have varying approaches to how they test. Understanding what each tool does is important to understanding the effectiveness of their results in terms of claiming vulnerable or not vulnerable to the issue. Most people I've interacted with are using a combination of tools. The appropriate response to the issue is to follow the advice in the advisory - either move to a version with the patch for the defect applied or move to a version where the heartbeat code has been removed completely via compilation of the library with -DOPENSSL_NO_HEARTBEATS. If you connect to a site which does not support heartbeat (compiled out) then you will get something like this: HEARTBEATING 140153106511512:error:1413B16D:SSL routines:tls1_heartbeat:peer does not accept heartbearts:t1_lib.c:4049: ??? [length 0005] 15 03 01 00 20 TLS 1.0Alert [length 0002], warning close_notify 01 00 It is also possible to use the message callback function to block the response to heartbeat in application code if your library hasn't been patched. However the right solution is to fix the library via either of the methods mentioned in the advisory at https://www.openssl.org/news/secadv_20140407.txt Tim. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El dÃa Wednesday, April 09, 2014 a las 01:05:22AM -0700, monloi perez escribió: True. Thanks for the quick reply. On Wednesday, April 9, 2014 3:33 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan Hello, As you can read in the above change log, heartbeat support was introduced in version 1.0.1 of openssl. Does this mean that also the bug was introduced with this version in March 2012, or was it later? What is the exact bug, can someone show a svn/git diff of the first source version having the bug? Is it possible that the bug was introduced with intention (to make use of it later)? Here in Germany in the news we have rumor, that the bug was used by NSA, of course the American Goverment says no. Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 17:43, Matthias Apitz g...@unixarea.de wrote: El dÃa Wednesday, April 09, 2014 a las 01:05:22AM -0700, monloi perez escribió: True. Thanks for the quick reply. On Wednesday, April 9, 2014 3:33 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan Hello, As you can read in the above change log, heartbeat support was introduced in version 1.0.1 of openssl. Does this mean that also the bug was introduced with this version in March 2012, or was it later? As the security advisory states, the bug showed up in version 1.0.1 released in March 2012. What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Is it possible that the bug was introduced with intention (to make use of it later)? Here in Germany in the news we have rumor, that the bug was used by NSA, of course the American Goverment says no. I have read the rumor. It is wrong. I was Robins boss at the time he did the work, he worked in my lab. Neither me personally nor my lab at the university had any cooperations with any security agency (from any country). Robin worked on the OpenSSL code for multiple years. During his work with the DTLS code, he fixed a lot of bugs in that code and implemented some features, like the support of RFC 6520. He worked in the public, all his patches were submitted with his name. The intention was to improve OpenSSL, not to introduce bugs. Unfortunately, the patch above contained a bug which wasn't catched, neither by Robin, nor by the reviewers, nor by the people using the stack. It is a bug. A bug with a huge impact. Nothing more. Nothing less. Best regards Michael Tüxen Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 21:30, Matthias Apitz g...@unixarea.de wrote: El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks Here is the commit of the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=731f431497f463f3a2a97236fe0187b11c44aead Best regards Michael matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 09:30:22PM +0200, Matthias Apitz escribió: El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks ah, I see it in ssl/d1_both.c, the memcpy for the payload is done regardless if payload length and payload fit; forget my request. Thx matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12/04/14 21:30, Matthias Apitz wrote: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks Check ssl/d1_both.c /Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 03:43:29PM -0400, Michael Smith escribió: On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. agreed; and this bug wasn't hard to see (even for me, sitting in a restaurant with a netbook); in my company we do code review face to face, i.e. two persons (the coder and the reviewer) wade through the new code; one target of always questioning are copies in memory: do the amount of data fit into target location and is the source amount a valid space... matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 03:43:29PM -0400, Michael Smith escribió: On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. and one comment more: the bug works in both directions; when a client with an openssl lib/DLL with this bug connects to a well prepared SSL server, the server can fetch up to 64 kbyte of memory from the client, for example the stored saved passwords in your browser... matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 21:43, Michael Smith m...@smithbowen.net wrote: On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? My statement was referring to the Introduced with intend. I personally don't know anything about known to the NSA. Best regards Michael I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On Apr 12, 2014, at 5:40 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: Introduced with intent vs. known to the NSA -- two different things, right? My statement was referring to the Introduced with intend. Understood. I'm personally quite sure it *wasn't* introduced with intent, which is why I thought it was important to note the distinction. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL Security Advisory
The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. Steve... On Fri, Apr 11, 2014 at 7:40 AM, Walter H. walte...@mathemainzel.infowrote: On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ -- Steve Kneizys Senior Business Process Engineer Voice: (610) 256-1396 [For Emergency Service (888)864-3282] Ferrilli Information Group -- Quality Service and Solutions for Higher Education web: http://www.ferrilli.com/ http://www.figsolutions.com/ Making you a success while exceeding your expectations.
RE: OpenSSL Security Advisory
Also try your range here https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp Hth jaa -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Walter H. Sent: Friday, April 11, 2014 7:40 AM To: openssl-users@openssl.org Subject: Re: OpenSSL Security Advisory On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
In debian I solved linking directly static library. gcc -ansi -pedantic -o heartbleed heartbleed.c -lcrypto \ /usr/lib/x86_64-linux-gnu/libssl.a Regards In data venerdì 11 aprile 2014 08:38:07, Steven Kneizys ha scritto: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. Steve... On Fri, Apr 11, 2014 at 7:40 AM, Walter H. walte...@mathemainzel.infowrote: On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ -- -- Leonardo Secci mailto:leonardo.se...@unirel.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Thanks Leonardo! On 11/04/14 13:54, Leonardo Secci wrote: In debian I solved linking directly static library. gcc -ansi -pedantic -o heartbleed heartbleed.c -lcrypto \ /usr/lib/x86_64-linux-gnu/libssl.a Regards In data venerdì 11 aprile 2014 08:38:07, Steven Kneizys ha scritto: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. Steve... On Fri, Apr 11, 2014 at 7:40 AM, Walter H. walte...@mathemainzel.infowrote: On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 11/04/2014 10:38 PM, Steven Kneizys wrote: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. The work around is trivial if you wanted to do that. Change to use the SSL_get_ssl_method function. This line: if (ssl3_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Simply becomes: if (SSL_get_ssl_method(v_ssl)-ssl_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Tim.
Re: OpenSSL Security Advisory
-Original Message- From: Matthias Apitz [mailto:g...@unixarea.de] Sent: Thursday, April 10, 2014 6:41 AM To: Apitz,Matthias Subject: Fwd: RE: OpenSSL Security Advisory - Forwarded message from Salz, Rich rs...@akamai.com - Date: Wed, 9 Apr 2014 15:43:28 -0400 From: Salz, Rich rs...@akamai.com To: openssl-users@openssl.org openssl-users@openssl.org Subject: RE: OpenSSL Security Advisory Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. My example tests only for those who have disabled TLs heartbeats, which is the safest thing, but not necessarily the only thing, to do. Hello, I have instrumented an openssl 1.0.1f as posted by Victor: guru@hein:~/openssl-1.0.1f diff ssl/t1_lib.c.unpatched ssl/t1_lib.c 2671c2671 s2n(payload, p); --- s2n(0x4000, p); but I still see HEARTBEATING, for example even from www.openssl.org: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 ... HEARTBEATING DONE Do I something wrong? Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. To compile: $ gcc -ansi -pedantic -o heartbleed heartbleed.c -lssl -lcrypto Examples: $ ./heartbleed www.ibm.com:443 NOT VULNERABLE (TLS Heartbeat extension not supported by the server) $ ./heartbleed secure.comodo.net:443 NOT VULNERABLE (TLS Heartbeat extension supported by the server) $ ./heartbleed mail.visservansolkema.nl:443 VULNERABLE! -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Thu, Apr 10, 2014 at 10:57:35AM +0200, Matthias Apitz wrote: I have instrumented an openssl 1.0.1f as posted by Victor: guru@hein:~/openssl-1.0.1f diff ssl/t1_lib.c.unpatched ssl/t1_lib.c 2671c2671 s2n(payload, p); --- s2n(0x4000, p); but I still see HEARTBEATING, for example even from www.openssl.org: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 ... HEARTBEATING DONE Do I something wrong? That logs the request, you also need to see the reply... With servers that reply to the hearbeat you should see: ... HEARTBEATING read R BLOCK DONE -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan
Re: OpenSSL Security Advisory
True. Thanks for the quick reply. On Wednesday, April 9, 2014 3:33 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan
Re: OpenSSL Security Advisory
How do I determine whether or not the web servers I run are affected? They are Apache 2.4, built for 64 bit Windows and downloaded from Apachelounge. I have no idea what version of openssl it was built with. Does anyone here know if the feature that introduces the risk can be turned off, without introducing other risks? If so, how? Also, could the security keys we bought have been compromised? Any advice on how I can protect my servers better would be appreciated. Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. On Mon, Apr 7, 2014 at 4:31 PM, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/ QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/ OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd J37YgDNuefzrsA+B5/o7 =szjb -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
http://filippo.io/Heartbleed/#www.unlocator.com On Wed, Apr 9, 2014 at 2:05 PM, Ted Byers r.ted.by...@gmail.com wrote: How do I determine whether or not the web servers I run are affected? They are Apache 2.4, built for 64 bit Windows and downloaded from Apachelounge. I have no idea what version of openssl it was built with. Does anyone here know if the feature that introduces the risk can be turned off, without introducing other risks? If so, how? Also, could the security keys we bought have been compromised? Any advice on how I can protect my servers better would be appreciated. Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. On Mon, Apr 7, 2014 at 4:31 PM, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/ QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/ OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd J37YgDNuefzrsA+B5/o7 =szjb -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Hi Ted,
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
How do I determine whether or not the web servers I run are affected?
They are Apache 2.4, built for 64 bit Windows and downloaded from
Apachelounge. I have no idea what version of openssl it was built with. Does
anyone here know if the feature that introduces the risk can be turned off,
without introducing other risks? If so, how?
you can check for yourself:
- http://filippo.io/Heartbleed/
- http://possible.lv/tools/hb/
- https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl
Also, could the security keys we bought have been compromised?
Certainly yes. You should replace them. I read today that some CAs offer free
replacements.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
RE: OpenSSL Security Advisory
Ø How do I determine whether or not the web servers I run are affected? Here's a simple way: echo B | openssl s_client -connect $HOST:$PORT if you see heartbeating at the end, then $HOST is vulnerable. How can you tell if private keys have been taken? You can't, really. You can estimate the likelihood by looking closely at how OpenSSL_Malloc() return values are used and layed out. The risk is that an allocated ssl-record buffer is right up against a private key being stored. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: OpenSSL Security Advisory
Thanks Rich, I have obtained the new, patched, release of Apache from Apache lounge, and applied the patch to one server, which the online services say fix the problem on it, but your simple way of checking still says heartbeating at the end. Does that mean that the patch didn't truly work? I get the heartbeating message on both unpatched and patched servers. Should that make me worry about the patched machines? Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. On Wed, Apr 9, 2014 at 9:54 AM, Salz, Rich rs...@akamai.com wrote: Ø How do I determine whether or not the web servers I run are affected? Here's a simple way: echo B | openssl s_client -connect $HOST:$PORT if you see heartbeating at the end, then $HOST is vulnerable. How can you tell if private keys have been taken? You can't, really. You can estimate the likelihood by looking closely at how OpenSSL_Malloc() return values are used and layed out. The risk is that an allocated ssl-record buffer is right up against a private key being stored. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: OpenSSL Security Advisory
Thanks Patrick. Apache lounge already has a patched release released. So, once I deploy that, and get my certificates reissued, I ought to be OK. Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. On Wed, Apr 9, 2014 at 8:37 AM, Eisenacher, Patrick patrick.eisenac...@bdr.de wrote: Hi Ted, -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- How do I determine whether or not the web servers I run are affected? They are Apache 2.4, built for 64 bit Windows and downloaded from Apachelounge. I have no idea what version of openssl it was built with. Does anyone here know if the feature that introduces the risk can be turned off, without introducing other risks? If so, how? you can check for yourself: - http://filippo.io/Heartbleed/ - http://possible.lv/tools/hb/ - https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl Also, could the security keys we bought have been compromised? Certainly yes. You should replace them. I read today that some CAs offer free replacements. HTH, Patrick Eisenacher
Re: OpenSSL Security Advisory
On Wed, Apr 09, 2014 at 10:55:23AM -0400, Ted Byers wrote: I get the heartbeating message on both unpatched and patched servers. Should that make me worry about the patched machines? No, unfortunately both patched and unpatched systems respond the same way to valid heartbeat requests as send by s_client(1). To detect a difference, you need to send invalid heartbeat requests whose payload is shorter than promised. If you patch a copy of the source code for OpenSSL 1.0.1 as below, and build statically linked and run ./apps/openssl s_client ... from the build tree: --- a/ssl/t1_lib.c +++ b/ssl/t1_lib.c @@ -2702,7 +2702,7 @@ tls1_heartbeat(SSL *s) /* Message Type */ *p++ = TLS1_HB_REQUEST; /* Payload length (18 bytes here) */ - s2n(payload, p); + s2n(0x4000, p); /* Sequence number */ s2n(s-tlsext_hb_seq, p); /* 16 random bytes */ then you can detect the difference. Patched systems won't respond to the malformed heartbeat request. Replace echo B | with something like: (sleep 10; echo B; sleep 10) | ... to make sure that the handshake is complete by the time the request is sent, and the client does not disconnect too quickly. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Ø I get the heartbeating message on both unpatched and patched servers. Should that make me worry about the patched machines? Not necessarily. If they updated to the 'g' release, then they are doing buffer-overrun checking and you're safe. You can probably find out by connecting to your server (via s_client again) and seeing what it says in the server line, as in echo HEAD / HTTP/1.0 | openssl s_client -connect $HOST:$PORT The server usually says things like apache/2.0 openssl/1.0.1g ... and other modules that are bundled in. To be safest, heartbeats should just be disabled. Nobody really uses them. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: OpenSSL Security Advisory
- Forwarded message from Salz, Rich rs...@akamai.com - Date: Wed, 9 Apr 2014 09:54:25 -0400 From: Salz, Rich rs...@akamai.com To: openssl-users@openssl.org openssl-users@openssl.org Subject: RE: OpenSSL Security Advisory Ø How do I determine whether or not the web servers I run are affected? Here's a simple way: echo B | openssl s_client -connect $HOST:$PORT if you see heartbeating at the end, then $HOST is vulnerable. How can you tell if private keys have been taken? You can't, really. You can estimate the likelihood by looking closely at how OpenSSL_Malloc() return values are used and layed out. The risk is that an allocated ssl-record buffer is right up against a private key being stored. /r$ Hello Rich, Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: $ echo B | openssl s_client -connect akamai.com:https ... Verify return code: 20 (unable to get local issuer certificate) --- HEARTBEATING 675358796:error:1413B16D:SSL routines:SSL_F_TLS1_HEARTBEAT:peer does not accept heartbearts:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/t1_lib.c:2562: Thanks for clarification. matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. My example tests only for those who have disabled TLs heartbeats, which is the safest thing, but not necessarily the only thing, to do. -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL security advisory
On Mon 12/03/12 4:02 PM , open...@master.openssl.org (OpenSSL) sent: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [12 Mar 2012] FTAO Dr Steve Henson, Not that it's important, but the FAQ in 0.9.8u archive says: * Which is the current version of OpenSSL? The current version is available from . OpenSSL 1.0.0h was released on Mar 12th, 2012. Should this be 0.9.8u or should the FAQ mention both forks? Regards, Carl __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
The windows binaries do not appear to have been upgraded yet. It is possible that some of them are affected, I should think. Thanks. -Original Message- From: owner-openssl-annou...@openssl.org [mailto:owner-openssl- annou...@openssl.org] On Behalf Of OpenSSL Sent: Wednesday, January 18, 2012 8:21 AM To: openssl-annou...@master.openssl.org; openssl- d...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL Security Advisory -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [18 Jan 2011] === DTLS DoS attack (CVE-2012-0050) A flaw in the fix to CVE-2011-4108 can be exploited in a denial of service attack. Only DTLS applications using OpenSSL 1.0.0f and 0.9.8s are affected. Thanks to Antonio Martin, Enterprise Secure Access Research and Development, Cisco Systems, Inc. for discovering this bug and preparing a fix. Affected users should upgrade to OpenSSL 1.0.0g or 0.9.8t. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20120118.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTxbTZqLSm3vylcdZAQIVsgf/b+bSo2XrK9aWx1MCvgcz9Y1rJS8mOfLS c1E9ZpIp2uXcHai9PNhtJ8MRW3pVpyHMxqNQ/9ULXYBjRwVl9YT2ipDBN4iZda9M 3Rh3g6vuWwbpNDNnd9xiuTVq8y7cVk1U0VXoOZ9tXIkkKgEITXiAqH1qmo9nthkT Rv/5cgWmfplnhz0gMANHreRh3cZr/BhQaKHZAZ8Fsa2EqRHdyZagGlwspGqQab85 dT8jiNYABnQDWju28tjpMT/W8vnW0/zTXll21hbNj/R+D/L3lhLY8XNhYsoQrCZo UIY+quRAsdggLWrFizDA3vxsEdtU1z/5yE+4bs5hzaJhTe0RJUieNw== =Dkux -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Announcement Mailing List openssl-annou...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 1/19/2012 10:59 AM, John A. Wallace wrote: The windows binaries do not appear to have been upgraded yet. It is possible that some of them are affected, I should think. Thanks. They are up now. -Original Message- From: owner-openssl-annou...@openssl.org [mailto:owner-openssl- OpenSSL Security Advisory [18 Jan 2011] Just noticed the wrong year on the advisory e-mail. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Tue, Sep 06, 2011 at 03:40:30PM +0200, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [6 September 2011] Two security flaws have been fixed in OpenSSL 1.0.0e CRL verification vulnerability in OpenSSL = Under certain circumstances OpenSSL's internal certificate verification routines can incorrectly accept a CRL whose nextUpdate field is in the past. (CVE-2011-3207) This issue applies to OpenSSL versions 1.0.0 through 1.0.0d. Versions of OpenSSL before 1.0.0 are not affected. Users of affected versions of OpenSSL should update to the OpenSSL 1.0.0e release, which contains a patch to correct this issue. Thanks to Kaspar Brand o...@velox.ch for identifying this bug and suggesting a fix. TLS ephemeral ECDH crashes in OpenSSL = OpenSSL server code for ephemeral ECDH ciphersuites is not thread-safe, and furthermore can crash if a client violates the protocol by sending handshake messages in incorrect order. (CVE-2011-3210) This issue applies to OpenSSL 0.9.8 through 0.9.8s (experimental ECCdraft ciphersuites) and to OpenSSL 1.0.0 through 1.0.0d. Affected users of OpenSSL should update to the OpenSSL 1.0.0e release, which contains a patch to correct this issue. If you cannot immediately upgrade, we recommend that you disable ephemeral ECDH ciphersuites if you have enabled them. Thanks to Adam Langley a...@chromium.org for identifying and fixing this issue. Which applications are affected === Applications are only affected by the CRL checking vulnerability if they enable OpenSSL's internal CRL checking which is off by default. For example by setting the verification flag X509_V_FLAG_CRL_CHECK or X509_V_FLAG_CRL_CHECK_ALL. Applications which use their own custom CRL checking (such as Apache) are not affected. Only server-side applications that specifically support ephemeral ECDH ciphersuites are affected by the ephemeral ECDH crash bug and only if ephemeral ECDH ciphersuites are enabled in the configuration. You can check to see if application supports ephemeral ECDH ciphersuites by looking for SSL_CTX_set_tmp_ecdh, SSL_set_tmp_ecdh, SSL_CTRL_SET_TMP_ECDH, SSL_CTX_set_tmp_ecdh_callback, SSL_set_tmp_ecdh_callback, SSL_CTRL_SET_TMP_ECDH_CB in the source code. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20110906.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTmYhWqLSm3vylcdZAQKsnQgAsD+GwbfpXuZyhLNcHrJjTiHgfVWQLiFq 6RupYmgfxPiCrGdSEvp6Uh3Y+bcOOoDXTXujk7T6RTRU4iYiARFkXo8bUtH47dWO AfwOyMxiM88G9TYj69RUjKNP70j1rEATIz+m4kpnDgmmsodDNsPj56k4gptsoELc S4Cb4+97uCBv1mkVFgvu71RVXbIwqOMt/vveHUttQQLEcdu2XcUylbMarDaOcZui e9AjYX3LoqdhPRl2v01tuJf3c8wmNTE+GtsO8hwda6eo8Mu/BAnqtFsiFRVjmJ2M vgj1Ot/SPQHcpDu7N3V3GY4tdY8iDHWZ5FfbyaoXvzM6guS+o4cDww== =xfeL -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Will this affect openssl 1.0.1 ? -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God, Queen and country! Never Satan President Republic! Beware AntiChrist rising! https://www.fullyfollow.me/rootnl2k IT is done! http://groups.google.com/group/rec.arts.drwho/about __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Auto Reply: Re: OpenSSL Security Advisory
I will be on vacation from Sep/05/2011 thru Sep/16/2011 (back in the office on Sep 19). Have a great day ! Huie-Ying __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
-Original Message- From: owner-openssl-us...@openssl.org ssl/s2_srvr.c ssl/s3_srvr.c : The error in those two file seems to mean that server verification of DSA signed clients certificates is also affected. DSA cannot be used with SSLv2 so it is not . Is it not also affected about SSLv3? Thanks. Takurou Saitou __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Dr. Stephen Henson wrote: On Wed, Jan 07, 2009, Victor Duchovni wrote: This is not very clear to me. Which signatures are poorly verified: 1. The server's signature on SSL/TLS protocol messages that must be signed under the server's private key (corresponding to the private key in its certificate)? [ITYM ... corresponding to the public key in its certificat...] Yes it is 1 only. Certificate chain validation is not affected nor other forms of DSA/ECDSA signature verification such as S/MIME. Stephen, can you elaborate on that response because from the patch it seems that more than only client validation of the server signature in SSL sessions is affected. cms/cms_sd.c is affected, but the consequence is only a missing error message, right ? ssl/s2_srvr.c ssl/s3_srvr.c : The error in those two file seems to mean that server verification of DSA signed clients certificates is also affected. apps/verify.c is affected. This is the app file, not crypto, so chain validation that is done in crypto is not affected. But if someone happens to rely on the command line tool to do the verification, he may be affected. apps/spkac.c is affected. This will not impact many people (command line verification of Netscape format certificate request) but should be noted. apps/x509.c is affected, but the impact seems extremely low affecting only the code path to generate a self signed cert. Also it may be important to insist on the point that anybody who has developed applications using openssl and using the existing code as a model (cut/paste) is quite likely to be impacted by this problem. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Fri, Jan 09, 2009, Jean-Marc Desperrier wrote: Stephen, can you elaborate on that response because from the patch it seems that more than only client validation of the server signature in SSL sessions is affected. cms/cms_sd.c is affected, but the consequence is only a missing error message, right ? Yes. ssl/s2_srvr.c ssl/s3_srvr.c : The error in those two file seems to mean that server verification of DSA signed clients certificates is also affected. DSA cannot be used with SSLv2 so it is not affected. apps/verify.c is affected. This is the app file, not crypto, so chain validation that is done in crypto is not affected. But if someone happens to rely on the command line tool to do the verification, he may be affected. apps/spkac.c is affected. This will not impact many people (command line verification of Netscape format certificate request) but should be noted. Agreed. apps/x509.c is affected, but the impact seems extremely low affecting only the code path to generate a self signed cert. Also it may be important to insist on the point that anybody who has developed applications using openssl and using the existing code as a model (cut/paste) is quite likely to be impacted by this problem. A detailed code analysis showed two cases where X509_verify_cert() could return -1. One is due to programmer error: not setting the certificate. The other is if an X509_LOOKUP requests a retry. This is something which has been about since the SSLeay days but never used. Effectively that means the function X509_verify_cert() in real world usage only returns 0 for failure and 1 for success. My colleagues however wanted to include the additional checks as a precautionary measure. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
This vulnerability only comes into play during active TLS sessions. Certificate chain validation is not affected. S/MIME is not affected. Quoting Dr Henson (a later message, Message-ID 20090107184137.ga99...@openssl.org): Certificate chain validation is not affected nor other forms of DSA/ECDSA signature verification such as S/MIME. -Kyle H On Thu, Jan 8, 2009 at 2:35 AM, Harakiri harakiri...@yahoo.com wrote: --- On Wed, 1/7/09, Dr. Stephen Henson st...@openssl.org wrote: Incorrect checks for malformed signatures - --- It is not perfectly clear to me if regular certificate validiations and smime signature validiation is also affected by this. Could you please elaborate if this vul could be used while verifying certificate (chains) and/or smime signatures? Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
--- On Wed, 1/7/09, Dr. Stephen Henson st...@openssl.org wrote: Incorrect checks for malformed signatures - --- It is not perfectly clear to me if regular certificate validiations and smime signature validiation is also affected by this. Could you please elaborate if this vul could be used while verifying certificate (chains) and/or smime signatures? Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Wed, Jan 07, 2009 at 02:17:09PM +0100, Dr. Stephen Henson wrote: Several functions inside OpenSSL incorrectly checked the result after calling the EVP_VerifyFinal function, allowing a malformed signature to be treated as a good signature rather than as an error. This issue affected the signature checks on DSA and ECDSA keys used with SSL/TLS. One way to exploit this flaw would be for a remote attacker who is in control of a malicious server or who can use a 'man in the middle' attack to present a malformed SSL/TLS signature from a certificate chain to a vulnerable client, bypassing validation. This vulnerability is tracked as CVE-2008-5077. The OpenSSL security team would like to thank the Google Security Team for reporting this issue. Who is affected? = Everyone using OpenSSL releases prior to 0.9.8j as an SSL/TLS client when connecting to a server whose certificate contains a DSA or ECDSA key. Use of OpenSSL as an SSL/TLS client when connecting to a server whose certificate uses an RSA key is NOT affected. Verification of client certificates by OpenSSL servers for any key type is NOT affected. This is not very clear to me. Which signatures are poorly verified: 1. The server's signature on SSL/TLS protocol messages that must be signed under the server's private key (corresponding to the private key in its certificate)? OR 2. Certificate Authority (CA) signatures of the server certificate or intermediate CA certificates? OR 3. Both or other (please elaborate). If it is just 1 and limited to DSA or ECDSA server keys, and given that almost keys in the wild are RSA keys (no public CAs are signing ECDSA certs AFAIK). Is the exposure just in environments where some private-CA (or non-CA mechanism) supports trust for DSA or ECDSA certs? If it is 2, then which keys must be DSA or ECDSA the server's or the CA's? It sounds as the though X.509 trust chain validation is not effected, and the exposure is just with server signatures of protocol messages (i.e. 1 only), but this is not completely clear at least to me. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Wed, Jan 07, 2009, Victor Duchovni wrote: This is not very clear to me. Which signatures are poorly verified: 1. The server's signature on SSL/TLS protocol messages that must be signed under the server's private key (corresponding to the private key in its certificate)? [ITYM ... corresponding to the public key in its certificat...] Yes it is 1 only. Certificate chain validation is not affected nor other forms of DSA/ECDSA signature verification such as S/MIME. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Does the release of 0.9.8j also include the FIPS module support? (i.e., is this a bug-fix only release, or does this include what you have been working on for the past few months as well?) -Kyle H On Wed, Jan 7, 2009 at 4:10 AM, Dr. Stephen Henson st...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [07-Jan-2009] Incorrect checks for malformed signatures - --- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Does the release of 0.9.8j also include the FIPS module support? do you mean anything other than this? http://www.mail-archive.com/openssl-users@openssl.org/msg55535.html This is the first full release of OpenSSL that can link against the validated FIPS module version 1.2 _ Windows LiveTM: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
I got the notice of the release several hours after the security advisory. Not sure what happened, but I've since received it. Thank you, Dr Henson and everyone who works on OpenSSL! -Kyle H On Wed, Jan 7, 2009 at 5:23 PM, Giang Nguyen cau...@hotmail.com wrote: Does the release of 0.9.8j also include the FIPS module support? do you mean anything other than this? http://www.mail-archive.com/openssl-users@openssl.org/msg55535.html This is the first full release of OpenSSL that can link against the validated FIPS module version 1.2 _ Windows LiveTM: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Kyle Hamilton wrote: I got the notice of the release several hours after the security advisory. Not sure what happened, but I've since received it. Thank you, Dr Henson and everyone who works on OpenSSL! -Kyle H On Wed, Jan 7, 2009 at 5:23 PM, Giang Nguyen cau...@hotmail.com wrote: Does the release of 0.9.8j also include the FIPS module support? do you mean anything other than this? http://www.mail-archive.com/openssl-users@openssl.org/msg55535.html This is the first full release of OpenSSL that can link against the validated FIPS module version 1.2 I forgot to ask earlier today, but does the security vulnerability affect 0.9.7m? If so, any plans for an official release? (Or is 0.9.7 officially retired and I simply missed the memo?) -- Thomas Hruska Shining Light Productions Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Wed, Jan 07, 2009 at 07:46:59PM -0700, Thomas J. Hruska wrote: I forgot to ask earlier today, but does the security vulnerability affect 0.9.7m? Yes, but only in the unlikely case that you operate clients that establish authenticated sessions with servers that use DSA certificates. This said, vendors such as Redhat have issued updated 0.9.6 and 0.9.7 packages for older platforms. The ciphers in question are: DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export you could disable these ciphers if DSA (aka DSS) support is not required. A 0.9.7 client with a cipherlist of DEFAULT:!aDSS would not be vulnerable (but would also not inter-operate with DSA servers). In a sample of ~384,000 STARTTLS mail deliveries, only 11 deliveries used DSS certificates. This represents ~27,000 unique SMTP server IP addresses of which only 6 had DSS certificates. All 6 certificates were self-signed (so already no MITM protection for most clients). SMTP traffic is of course an atypical sample, web client data is perhaps more interesting. Another caveat is that in this sample aNULL ciphers were used whenever available (mostly opportunistic TLS with peer Postfix 2.3+ servers, as other MTAs typically don't enable anonymous TLS by default). So some servers could have had DSS certificates that went unobserved. There were ~58,000 anonymous (ADH) deliveries to ~2900 distinct SMTP IP addresses. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Does the release of 0.9.8j also include the FIPS module support? (i.e., is this a bug-fix only release, or does this include what you have been working on for the past few months as well?) The actual 0.9.8j release announcement stated: This is the first full release of OpenSSL that can link against the validated FIPS module version 1.2 -Brad __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory: PRNG weakness in versions up to 0.9.6a
Is it just me, or is this advisory not linked to on the main webpage? Kris PGP signature
