Skip to content
  1. Apr 03, 2018
  3. Apr 02, 2018
  5. Mar 29, 2018
  7. Mar 28, 2018
  9. Mar 21, 2018
  11. Mar 20, 2018
  13. Mar 19, 2018
  15. Mar 15, 2018
  17. Mar 02, 2018
  19. Feb 28, 2018
  21. Feb 27, 2018
    • Dr. Matthias St. Pierre's avatar
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · d070b4ae
      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)
      d070b4ae
    • Matt Caswell's avatar
      Update copyright year · 0d664759
      Matt Caswell authored 
      

Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      0d664759
  23. Feb 23, 2018
  25. Feb 14, 2018
    • Viktor Dukhovni's avatar
      Avoid fragile aliasing of SHA224/384 update/final · babab8e7
      Viktor Dukhovni authored 
      

This is purported to save a few cycles, but makes the code less
obvious and more brittle, and in fact breaks on platforms where for
ABI continuity reasons there is a SHA2 implementation in libc, and
so EVP needs to call those to avoid conflicts.

A sufficiently good optimizer could simply generate the same entry
points for:

        foo(...) { ... }
    and
        bar(...) { return foo(...); }

but, even without that, the different is negligible, with the
"winner" varying from run to run (openssl speed -evp sha384):

    Old:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k

    New:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k

Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      babab8e7
  27. Feb 06, 2018
  29. Jan 23, 2018
  31. Jan 09, 2018
  33. Jan 07, 2018
  35. Dec 15, 2017
  37. Dec 09, 2017
  39. Dec 08, 2017
  41. Nov 20, 2017
  43. Nov 13, 2017
  45. Nov 05, 2017
  47. Oct 31, 2017
  49. Oct 30, 2017