Skip to content
  1. May 13, 2015
    • Matt Caswell's avatar
      Don't allow a CCS when expecting a CertificateVerify · a0bd6493
      Matt Caswell authored
      
      
      Currently we set change_cipher_spec_ok to 1 before calling
      ssl3_get_cert_verify(). This is because this message is optional and if it
      is not sent then the next thing we would expect to get is the CCS. However,
      although it is optional, we do actually know whether we should be receiving
      one in advance. If we have received a client cert then we should expect
      a CertificateVerify message. By the time we get to this point we will
      already have bombed out if we didn't get a Certificate when we should have
      done, so it is safe just to check whether |peer| is NULL or not. If it is
      we won't get a CertificateVerify, otherwise we will. Therefore we should
      change the logic so that we only attempt to get the CertificateVerify if
      we are expecting one, and not allow a CCS in this scenario.
      
      Whilst this is good practice for TLS it is even more important for DTLS.
      In DTLS messages can be lost. Therefore we may be in a situation where a
      CertificateVerify message does not arrive even though one was sent. In that
      case the next message the server will receive will be the CCS. This could
      also happen if messages get re-ordered in-flight. In DTLS if
      |change_cipher_spec_ok| is not set and a CCS is received it is ignored.
      However if |change_cipher_spec_ok| *is* set then a CCS arrival will
      immediately move the server into the next epoch. Any messages arriving for
      the previous epoch will be ignored. This means that, in this scenario, the
      handshake can never complete. The client will attempt to retransmit
      missing messages, but the server will ignore them because they are the wrong
      epoch. The server meanwhile will still be waiting for the CertificateVerify
      which is never going to arrive.
      
      RT#2958
      
      Reviewed-by: default avatarEmilia Käsper <emilia@openssl.org>
      a0bd6493
    • Gunnar Kudrjavets's avatar
      Fix the heap corruption in libeay32!OBJ_add_object. · 56d88027
      Gunnar Kudrjavets authored
      
      
      Original 'sizeof(ADDED_OBJ)' was replaced with 'sizeof(*ao)'. However,
      they return different sizes. Therefore as the result heap gets corrupted
      and at some point later debug version of malloc() detects the corruption.
      
      On x86 we can observe that as follows:
      
      sizeof(*ao) == 4
      sizeof(*ao[0]) == sizeof(ADDED_OBJ) == 8
      
      Issue reproduces with either enabling CRT debug heap or Application
      Verifier's full-page heap.
      
      Basic debugging data from the moment the corruption is first detected:
      
      0:000:x86> |
      .  0    id: 283c        create  name: openssl.exe
      0:000:x86> kcn
       #
      00 MSVCR120D!_heap_alloc_dbg_impl
      01 MSVCR120D!_nh_malloc_dbg_impl
      02 MSVCR120D!_nh_malloc_dbg
      03 MSVCR120D!malloc
      04 LIBEAY32!default_malloc_ex
      05 LIBEAY32!CRYPTO_malloc
      06 LIBEAY32!lh_insert
      07 LIBEAY32!OBJ_add_object
      08 LIBEAY32!OBJ_create
      09 openssl!add_oid_section
      0a openssl!req_main
      0b openssl!do_cmd
      0c openssl!main
      0d openssl!__tmainCRTStartup
      0e openssl!mainCRTStartup
      0f KERNEL32!BaseThreadInitThunk
      10 ntdll_77d60000!__RtlUserThreadStart
      11 ntdll_77d60000!_RtlUserThreadStart
      
      Signed-off-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      56d88027
  2. May 12, 2015
  3. May 11, 2015
  4. May 08, 2015
  5. May 07, 2015
  6. May 06, 2015
  7. May 05, 2015
  8. May 04, 2015