Vulnerability

    SSLeay and OpenSSL

Affected

    Packages that use SSLeay and OpenSSL

Description

    Following is based on OpenSSL  and SSLeay Security Alert.   It was
    recently realised that  packages that use  SSLeay and OpenSSL  may
    suffer  from  a  security  problem:  under some circumstances, SSL
    sessions can be reused in a different context from their  original
    one. This may allow  access controls based on  client certificates
    to be bypassed.  Unfortunately,  before the the problem was  fully
    understood, it was discussed on various public lists. The  OpenSSL
    team  have  therefore  decided  to  release  an interim version of
    OpenSSL which  addresses the  problem by  disabling session  reuse
    except  in  limited  circumstances  (see  below).   Although  this
    problem is not strictly a  defect in OpenSSL, it is  rather tricky
    for applications to  be coded correctly  to avoid the  problem due
    to the sketchy nature of SSLeay/OpenSSL documentation.

    SSL sessions include a session ID which allows initial setup to be
    bypassed once a session has been established between a client  and
    server. This session ID, when presented by the client, causes  the
    same master key to be used as was used on the previous connection,
    thus saving considerable session setup time.  When the session  is
    reused  in  this  manner,  all  access  controls  based  on client
    certificates  are  bypassed,  on  the  grounds  that  the original
    session would have made the necessary checks.  Unfortunately,  the
    lack of documentation has resulted in the caching structures being
    used in certain applications without appropriate care being  taken
    to  assure  that  the  cached  sessions  are only available at the
    appropriate moments.  As a  result it is sometimes possible  for a
    specially  written  SSL  client  to  fraudulently  obtain  an  SSL
    connection which  requires access  control by  reusing a  previous
    session which  had different  or no  access control.   The problem
    affects  servers  which  support  session  reuse  and  which  have
    multiple virtual  hosts served  from a  single server,  where some
    virtual hosts  use differing  client server  verifications.   Note
    that  "different"  includes  no  verification  on  some hosts, and
    verification on others, or different CAs for different hosts.   In
    order to  exploit this  problem carefully  written client software
    would need to  be written.   The attacker would  need considerable
    knowledge of  the SSL  protocol.   Standard web  browsers will not
    and cannot be made to use SSL in this way.

    Affected software  includes all  server software  using SSLeay  or
    versions of OpenSSL prior to version 0.9.2b that support  multiple
    virtual  hosts  with  different  client  certificate verification.
    This includes, but is not limited to:

        Apache-SSL      http://www.apache-ssl.org/
        mod_ssl         http://www.engelschall.com/sw/mod_ssl/
        Raven           http://www.covalent.net/
        Stronghold      http://www.c2.net/

Solution

    A future  version will  deal with  the problem  more elegantly  by
    redoing verification on reused sessions when necessary.   Download
    OpenSSL 0.9.2b  (see http://www.openssl.org)  and build  it in the
    usual way.  Check the application for updates, and download those,
    too  (NB:  this  step  is  not  necessarily  required, the updated
    library will fix the problem).   The versions of the  applications
    listed above that you should use are:

        Apache_SSL 1.3.4+1.32
        mod_ssl 2.2.6-1.3.4
        Raven 1.4.0
        Stronghold 2.4.2

    Rebuild the application  (if needed).   If you are  an application
    author,    you    should    look     in    to    the    use     of
    SSL_set_session_id_context(),  which  can  be  used  to   reenable
    session reuse when appropriate.