You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King, III (JIRA)" <ji...@apache.org> on 2015/03/30 19:15:54 UTC

[jira] [Created] (THRIFT-3061) C++ TSSLSocket shutdown delay/vulnerability

James E. King, III created THRIFT-3061:
------------------------------------------

             Summary: C++ TSSLSocket shutdown delay/vulnerability
                 Key: THRIFT-3061
                 URL: https://issues.apache.org/jira/browse/THRIFT-3061
             Project: Thrift
          Issue Type: Bug
          Components: C++ - Library
    Affects Versions: 0.9.2, 0.9.1, 0.9, 0.8
            Reporter: James E. King, III


In the C++ implementation of TSSLSocket, during close() the following code sequence is found:
{noformat}
void TSSLSocket::close() {
  if (ssl_ != NULL) {
    int rc = SSL_shutdown(ssl_);
    if (rc == 0) {
      rc = SSL_shutdown(ssl_);
    }
{noformat}
According to the OpenSSL documentation, while it is "nice" to attempt to shutdown SSL in this way, it is not required when the code is performing a unilateral shutdown (meaning the underlying connection will be closed).  It is only necessary to call SSL_Shutdown twice like this if the socket (and configured SSL therein) is going to be reused.

It is possible to have a misbehaving client that does not handle this part of the shutdown process properly and fail to reply, and also fail to close.  The most likely embodiment would be a program designed specifically to fail to reply to the "close notify" and hold the socket open in order to produce a denial-of-service attack.  Another possibility is a poorly written client.

Given the OpenSSL documentation states that calling SSL_Shutdown once is sufficient when the socket is going to be closed, I recommend that we remove the second SSL_Shutdown call and prevent something that can block the close() call.  We have seen this happen, and it interacts with THRIFT-2441.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)