Skip to content
  1. Mar 21, 2018
  3. Mar 20, 2018
  5. Mar 15, 2018
  7. Mar 14, 2018
  9. Mar 12, 2018
  11. Mar 11, 2018
  13. Mar 08, 2018
  15. Mar 07, 2018
  17. Mar 05, 2018
  19. Mar 04, 2018
  21. Mar 03, 2018
  23. Mar 02, 2018
  25. Mar 01, 2018
  27. Feb 26, 2018
    • Dr. Matthias St. Pierre's avatar
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · b3f9b401
      Dr. Matthias St. Pierre authored 
      Fixes #5405, #1381

The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes.
When processing input in PEM format it can happen in rare cases that

- the trailing PEM marker crosses the boundary of a chunk, and
- the beginning of the following chunk contains valid base64 encoded data.

This happened in issue #5405, where the PEM marker was split into
"-----END CER" and "TIFICATE-----" at the end of the first chunk.

The decoding of the first chunk terminated correctly at the '-' character,
which is treated as an EOF marker, and b64_read() returned. However,
when called the second time, b64_read() read the next chunk and interpreted
the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes
'4c 81 48 08 04 c4'.

This patch restores the assignment of the error code to 'ctx->cont', which
was deleted accidentally in commit 5562cfac

 and which prevents b64_read()
from reading additional data on subsequent calls.

This issue was observed and reported by Annie Yousar.

Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5422)
      b3f9b401
  29. Feb 22, 2018
  31. Feb 21, 2018
  33. Feb 13, 2018
  35. Feb 09, 2018
  37. Feb 02, 2018
  39. Feb 01, 2018
    • David Benjamin's avatar
      Don't leak the exponent bit width in BN_mod_exp_mont_consttime. · 4981e6fc
      David Benjamin authored 
      

The exponent here is one of d, dmp1, or dmq1 for RSA. This value and its
bit length are both secret. The only public upper bound is the bit width
of the corresponding modulus (RSA n, p, and q, respectively).

Although BN_num_bits is constant-time (sort of; see bn_correct_top notes
in preceding patch), this does not fix the root problem, which is that
the windows are based on the minimal bit width, not the upper bound. We
could use BN_num_bits(m), but BN_mod_exp_mont_consttime is public API
and may be called with larger exponents. Instead, use all top*BN_BITS2
bits in the BIGNUM. This is still sensitive to the long-standing
bn_correct_top leak, but we need to fix that regardless.

This may cause us to do a handful of extra multiplications for RSA keys
which are just above a whole number of words, but that is not a standard
RSA key size.

Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5154)

(cherry picked from commit 39eeb64f)
      4981e6fc
    • David Benjamin's avatar
      Make BN_num_bits_word constant-time. · 66509ddb
      David Benjamin authored 
      

(This patch was written by Andy Polyakov. I only wrote the commit
message. Mistakes in the analysis are my fault.)

BN_num_bits, by way of BN_num_bits_word, currently leaks the
most-significant word of its argument via branching and memory access
pattern.

BN_num_bits is called on RSA prime factors in various places. These have
public bit lengths, but all bits beyond the high bit are secret. This
fully resolves those cases.

There are a few places where BN_num_bits is called on an input where the
bit length is also secret. This does *not* fully resolve those cases as
we still only look at the top word. Today, that is guaranteed to be
non-zero, but only because of the long-standing bn_correct_top timing
leak. Once that is fixed, a constant-time BN_num_bits on such inputs
must count bits on each word.

Instead, those cases should not call BN_num_bits at all. In particular,
BN_mod_exp_mont_consttime uses the exponent bit width to pick windows,
but it should be using the maximum bit width. The next patch will fix
this.

Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu
for reporting this issue.

Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5154)

(cherry picked from commit 972c87df)
      66509ddb
  41. Jan 30, 2018
    • Matt Caswell's avatar
      Make sure we check an incoming reneg ClientHello in DTLS · d498e526
      Matt Caswell authored 
      

In TLS we have a check to make sure an incoming reneg ClientHello is
acceptable. The equivalent check is missing in the DTLS code. This means
that if a client does not signal the ability to handle secure reneg in the
initial handshake, then a subsequent reneg handshake should be rejected by
the server. In the DTLS case the reneg was being allowed if the the 2nd
ClientHello had a renegotiation_info extension. This is incorrect.

While incorrect, this does not represent a security issue because if
the renegotiation_info extension is present in the second ClientHello it
also has to be *correct*. Therefore this will only work if both the client
and server believe they are renegotiating, and both know the previous
Finished result. This is not the case in an insecure rengotiation attack.

I have also tidied up the check in the TLS code and given a better check
for determining whether we are renegotiating or not.

Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5192)
      d498e526
  43. Jan 24, 2018
  45. Jan 23, 2018
  47. Jan 22, 2018
  49. Jan 21, 2018