Re: OpenSSL Security Advisory

[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"
Rep

Re: OpenSSL Security Advisory

[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: CVE-2014-0195

[Florian Weimer]

On 06/06/2014 04:12 AM, Salz, Rich wrote:

Does that mean this RCE is a heap based overflow?


I/O buffers in openssl are generally (always?) from the heap, not on the stack.


The DTLS code uses on-stack buffers for discarding packets, but those 
read calls are not affected by the present issue.


--
Florian Weimer / Red Hat Product Security Team
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: AES-GCM

[Matt Caswell]

On 27 May 2014 08:00, Anant Rao  wrote:

> When I tried to decrypt it using OpenSSL in a 'c' program, the last call
> 'EVP_DecryptFinal_ex' fails. Somehow, ERR_print_errors_fp is not printing
> anything either.

If EVP_DecryptFinal_ex fails with GCM then this means that the tag has
failed to verify.

>
> I do have the IV that is used in the Java's encrypt. However, I don't know
> where BC stores the tag in the ciphertext. I tried it at the beginning and
> the end of the ciphertext, but it didn't help.
>
> That is, I tried both of the following in the decrypt:
>
> |IV|TAG|Ciphertext
>
> |IV|Ciphertext|TAG
> Both didn't work.

According to the documentation for javax.crypto.Cipher it says:
"Modes such as Authenticated Encryption with Associated Data (AEAD)
provide authenticity assurances for both confidential data and
Additional Associated Data (AAD) that is not encrypted. (Please see
RFC 5116 for more information on AEAD and AEAD algorithms such as
GCM/CCM.) Both confidential and AAD data can be used when calculating
the authentication tag (similar to a Mac). This tag is appended to the
ciphertext during encryption, and is verified on decryption."

>
> I tried both of the following as well with the same failure:
> EVP_aes_256_gcm
> EVP_aes_128_gcm
>
> I have run out of ideas what else to try. Any help would be greatly
> appreciated.

Make sure that the tag length that BouncyCastle is using is the same
as the tag length that openssl is using.

>  /* Finalise: note get no output for GCM */
> 63
> 
> EVP_EncryptFinal_ex(ctx, outbuf, &outlen);
> ...
>
> What does this mean? That we shouldn't expect any output from this call
> and/or that we should ignore it?

The openssl API is designed to work with all types of modes. In some
modes (such as CBC) output is only emitted a whole block at a time.
Therefore sometimes in the call to EVP_EncryptFinal_ex you get some
extra data added to outbuf. In GCM mode this is not the case, so no
additional data will be added to outbuf - but you still need to call
EVP_EncryptFinal_ex.

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: CVE-2014-0195

[Stuart Henderson]

On 2014-06-05, Jeffrey Walton  wrote:
> CVE-2014-0195 is a buffer overflow
> (https://www.openssl.org/news/secadv_20140605.txt):

By the way, this one is currently missing from the list on
http://www.openssl.org/news/vulnerabilities.html.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: AES-GCM

[Jens Hiller]

Hi,

I only used the CCM example that contains the same comment at the
comparable point in its code.
If I remember correctly this comment means that no data will  be added
to outbuf. Hence, outlen should be 0. I have not stepped through the
code, but that seems to be meaningful as CCM and GCM use counter modes
and therefore do not require padding (reference:
http://openssl.6102.n7.nabble.com/AES-GCM-padding-td43598.html and
various GCM documentations). Hence, there is nothing to do for the
finalization except for computing the MAC (but I have not checked in the
code if the finalization really computes the MAC).
If this is correct, you _should_ check the return value, but as
mentioned above, outlen will be 0.

Note: Please take this as ideas/hints that I provide to you for further
testing as I am also not sure about this. Unfortunately, I do not have
time to check this on my own now.

Regards
Jens

On 06/06/2014 05:37 AM, Anant Rao wrote:
> Thanks for the info!
> I looked at the demos programs in the given link
> http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=demos/evp/aesgcm.c;h=324d8a55b1481c507c7754fa7f33c30a02bdb737;hb=HEAD
> .
> 
> I have a question in encrypt:
> 
> ...
>  /* Finalise: note get no output for GCM */
> 63
> 
> EVP_EncryptFinal_ex(ctx, outbuf, &outlen);
> ...
> 
> What does this mean? That we shouldn't expect any output from this call
> and/or that we should ignore it?
> 
> 
> 
> Thanks!
> 
> 
> On Tue, May 27, 2014 at 12:33 AM, Jens Hiller
> mailto:jens.hiller.c...@hotmail.de>> wrote:
> 
> On 05/27/2014 09:00 AM, Anant Rao wrote:
> > Hi,
> >
> > I have ciphertext encrypted in Java (using BouncyCastle - BC) with
> > "AES/GCM/NoPadding" cipher.
> >
> > When I tried to decrypt it using OpenSSL in a 'c' program, the
> last call
> > 'EVP_DecryptFinal_ex' fails. Somehow, ERR_print_errors_fp is not
> > printing anything either.
> >
> > I do have the IV that is used in the Java's encrypt. However, I don't
> > know where BC stores the tag in the ciphertext. I tried it at the
> > beginning and the end of the ciphertext, but it didn't help.
> >
> > That is, I tried both of the following in the decrypt:
> >
> > |IV|TAG|Ciphertext
> >
> > |IV|Ciphertext|TAG
> > Both didn't work.
> >
> > I tried both of the following as well with the same failure:
> > EVP_aes_256_gcm
> > EVP_aes_128_gcm
> >
> > I have run out of ideas what else to try. Any help would be greatly
> > appreciated.
> > Thanks in advance!
> >
> >
> 
> Have a look at
> https://www.openssl.org/docs/crypto/EVP_EncryptInit.html#GCM_Mode
> and at the example in 'openssl/demos/evp/aesgcm.c' of the current master
> branch (git://git.openssl.org/openssl.git
> ).
> 
> Regards
> Jens
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List  
>  openssl-users@openssl.org 
> Automated List Manager  
> majord...@openssl.org 
> 
> 
> 
> 
> -- 
> 
> *Anant** **Rao*
> Server Lead
> D  / a...@noknok.com 
> 
> *Nok Nok Labs Inc.*
> 4151 Middlefield Road, Suite 200
> Palo Alto, CA 94303
> T +1 650 433 1300
> i...@noknok.com 
> 
> *www.noknok.com* 
> 
>   
> 
>  
> 
>  
> 
> 
> 
> 
> 
> 
> 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

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