Skip to content
  1. Apr 27, 2015
  2. Apr 24, 2015
  3. Apr 22, 2015
    • Loganaden Velvindron's avatar
      Fix CRYPTO_strdup · 6e5d1307
      Loganaden Velvindron authored
      
      
      The function CRYPTO_strdup (aka OPENSSL_strdup) fails to check the return
      value from CRYPTO_malloc to see if it is NULL before attempting to use it.
      This patch adds a NULL check.
      
      RT3786
      
      Signed-off-by: default avatarMatt Caswell <matt@openssl.org>
      (cherry picked from commit 37b0cf936744d9edb99b5dd82cae78a7eac6ad60)
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 20d21389c8b6f5b754573ffb6a4dc4f3986f2ca4)
      6e5d1307
  4. Apr 21, 2015
  5. Apr 20, 2015
  6. Apr 18, 2015
  7. Apr 17, 2015
  8. Apr 16, 2015
  9. Apr 14, 2015
    • Matt Caswell's avatar
      Fix ssl_get_prev_session overrun · 5101c35c
      Matt Caswell authored
      
      
      If OpenSSL is configured with no-tlsext then ssl_get_prev_session can read
      past the end of the ClientHello message if the session_id length in the
      ClientHello is invalid. This should not cause any security issues since the
      underlying buffer is 16k in size. It should never be possible to overrun by
      that many bytes.
      
      This is probably made redundant by the previous commit - but you can never be
      too careful.
      
      With thanks to Qinghao Tang for reporting this issue.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 5e0a80c1)
      5101c35c
    • Matt Caswell's avatar
      Check for ClientHello message overruns · 35bac916
      Matt Caswell authored
      
      
      The ClientHello processing is insufficiently rigorous in its checks to make
      sure that we don't read past the end of the message. This does not have
      security implications due to the size of the underlying buffer - but still
      needs to be fixed.
      
      With thanks to Qinghao Tang for reporting this issue.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit c9642eb1ff79a30e2c7632ef8267cc34cc2b0d79)
      35bac916
  10. Apr 11, 2015
  11. Apr 10, 2015
  12. Apr 08, 2015
    • Richard Levitte's avatar
      Have mkerr.pl treat already existing multiline string defs properly · 42802a94
      Richard Levitte authored
      
      
      Since source reformat, we ended up with some error reason string
      definitions that spanned two lines.  That in itself is fine, but we
      sometimes edited them to provide better strings than what could be
      automatically determined from the reason macro, for example:
      
          {ERR_REASON(SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER),
           "Peer haven't sent GOST certificate, required for selected ciphersuite"},
      
      However, mkerr.pl didn't treat those two-line definitions right, and
      they ended up being retranslated to whatever the macro name would
      indicate, for example:
      
          {ERR_REASON(SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER),
           "No gost certificate sent by peer"},
      
      Clearly not what we wanted.  This change fixes this problem.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (cherry picked from commit 2cfdfe09)
      42802a94
    • Richard Levitte's avatar
      Ignore the non-dll windows specific build directories · 9e63eeaf
      Richard Levitte authored
      
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 37d92b1b)
      9e63eeaf
    • Richard Levitte's avatar
      Appease clang -Wshadow · 700c0eb8
      Richard Levitte authored
      
      
      The macros BSWAP4 and BSWAP8 have statetemnt expressions
      implementations that use local variable names that shadow variables
      outside the macro call, generating warnings like this
      
      e_aes_cbc_hmac_sha1.c:263:14: warning: declaration shadows a local variable
            [-Wshadow]
          seqnum = BSWAP8(blocks[0].q[0]);
                   ^
      ../modes/modes_lcl.h:41:29: note: expanded from macro 'BSWAP8'
                                  ^
      e_aes_cbc_hmac_sha1.c:223:12: note: previous declaration is here
          size_t ret = 0;
                 ^
      
      Have clang be quiet by modifying the macro variable names slightly
      (suffixing them with an underscore).
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 2da2a434)
      700c0eb8
    • Richard Levitte's avatar
      Appease clang -Wgnu-statement-expression · a4ba7163
      Richard Levitte authored
      
      
      We use GNU statement expressions in crypto/md32_common.h, surrounded
      by checks that GNU C is indeed used to compile.  It seems that clang,
      at least on Linux, pretends to be GNU C, therefore finds the statement
      expressions and then warns about them.
      
      The solution is to have clang be quiet about it.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 04958e84)
      a4ba7163
    • Richard Levitte's avatar
      Appease clang -Wempty-translation-unit · d21cbd7d
      Richard Levitte authored
      
      
      ebcdic.c:284:7: warning: ISO C requires a translation unit to contain at least one
            declaration [-Wempty-translation-unit]
            ^
      1 warning generated.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit c25dea53)
      d21cbd7d
    • Emilia Kasper's avatar
      Harden SSLv2-supporting servers against Bleichenbacher's attack. · ae50d827
      Emilia Kasper authored
      
      
      There is no indication that the timing differences are exploitable in
      OpenSSL, and indeed there is some indication (Usenix '14) that they
      are too small to be exploitable. Nevertheless, be careful and apply
      the same countermeasures as in s3_srvr.c
      
      Thanks to Nimrod Aviram, Sebastian Schinzel and Yuval Shavitt for
      reporting this issue.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      ae50d827
  13. Apr 02, 2015
  14. Mar 31, 2015