Re: OpenSSL Security Advisory

2021-03-25 Thread Hubert Kario

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

2020-09-10 Thread Matt Caswell



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

2020-09-10 Thread Jakob Bohm via openssl-users

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

2020-09-10 Thread Tomas Mraz
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

2020-09-09 Thread Jakob Bohm via openssl-users

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

2020-04-21 Thread Sam Roberts
That makes sense, thank you all.


Re: OpenSSL Security Advisory

2020-04-21 Thread Matt Caswell



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

2020-04-21 Thread Benjamin Kaduk via openssl-users
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

2020-04-21 Thread Sam Roberts
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

2019-07-30 Thread Jakob Bohm via openssl-users

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

2019-02-27 Thread Scott Neugroschl
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

2019-02-27 Thread Matt Caswell



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

2019-02-27 Thread Scott Neugroschl
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

2014-06-06 Thread Geoffrey Thorpe
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

2014-06-06 Thread Jakob Bohm

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

2014-06-06 Thread Jeff Wieland

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

2014-06-05 Thread Jeff Wieland

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

2014-06-05 Thread Juha Saarinen
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

2014-06-05 Thread Green, Gatewood
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

2014-04-14 Thread Steven Kneizys
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)

2014-04-14 Thread Matthias Apitz

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

2014-04-14 Thread Tim Hudson
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)

2014-04-12 Thread Matthias Apitz
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)

2014-04-12 Thread Michael Tuexen
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)

2014-04-12 Thread Matthias Apitz
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)

2014-04-12 Thread Michael Tuexen
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)

2014-04-12 Thread Matthias Apitz
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)

2014-04-12 Thread Michael Smith

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)

2014-04-12 Thread Jan Danielsson
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)

2014-04-12 Thread Matthias Apitz
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)

2014-04-12 Thread Matthias Apitz
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)

2014-04-12 Thread Michael Tuexen
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)

2014-04-12 Thread Michael Smith

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

2014-04-11 Thread Walter H.

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

2014-04-11 Thread Steven Kneizys
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

2014-04-11 Thread JAaron Anderson

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

2014-04-11 Thread Leonardo Secci
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

2014-04-11 Thread Rob Stradling

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

2014-04-11 Thread Tim Hudson
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

2014-04-10 Thread Matthias Apitz
  -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

2014-04-10 Thread Rob Stradling

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

2014-04-10 Thread Viktor Dukhovni
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

2014-04-09 Thread Alan Buxey
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

2014-04-09 Thread monloi perez
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

2014-04-09 Thread Ted Byers
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

2014-04-09 Thread Ali Jawad
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

2014-04-09 Thread Eisenacher, Patrick
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

2014-04-09 Thread Salz, Rich
Ø  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

2014-04-09 Thread Ted Byers
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

2014-04-09 Thread Ted Byers
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

2014-04-09 Thread Viktor Dukhovni
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

2014-04-09 Thread Salz, Rich
Ø  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

2014-04-09 Thread Matthias Apitz
 - 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

2014-04-09 Thread Salz, 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:

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

2012-03-12 Thread carlyoung
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

2012-01-19 Thread John A. Wallace
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

2012-01-19 Thread Thomas J. Hruska

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

2011-09-06 Thread The Doctor
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

2011-09-06 Thread huieying . lee
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

2009-01-14 Thread Takurou Saitou
 -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

2009-01-09 Thread Jean-Marc Desperrier

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

2009-01-09 Thread Dr. Stephen Henson
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

2009-01-08 Thread Kyle Hamilton
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

2009-01-08 Thread Harakiri

--- 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

2009-01-07 Thread Victor Duchovni
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

2009-01-07 Thread Dr. Stephen Henson
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

2009-01-07 Thread Kyle Hamilton
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

2009-01-07 Thread Giang Nguyen

 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

2009-01-07 Thread Kyle Hamilton
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

2009-01-07 Thread Thomas J. Hruska

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

2009-01-07 Thread Victor Duchovni
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

2009-01-07 Thread Brad House
 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

2001-07-15 Thread Kris Kennaway

Is it just me, or is this advisory not linked to on the main webpage?

Kris

 PGP signature