OpenSSL handshake renegotiation process in the presence of the vulnerability can lead to denial of service-vulnerability warning-the black bar safety net

One, Foreword
OpenSSL is a very popular General-purpose encryption library, available as a Web authentication service to provide SSL/TLS Protocol Implementation. Recently, there has been found in OpenSSL in the presence of several vulnerabilities. We’ve written several articles on the analysis of these vulnerabilities, including“CVE-2017-3731: the truncation of packets can cause OpenSSL denial of service”,“SSL death warning CVE-2016-8610）can lead to OpenSSL Server denial of service”, etc. Today we will analyze the is CVE-2017-3733 this high-risk level vulnerability, i.e. Encrypt-Then-MAC the encrypted message authentication code re-negotiation crash vulnerability that can lead to the OpenSSL denial of service.
In the use of the SSL/TLS Protocol to encrypt the data before OpenSSL will first play Handshake Protocol the handshake and ChangeCipherSpec protocols, change the Key Specifications of the processes.
In Handshake stage, the client and server negotiated to use which kind of encryption algorithm. Once the negotiation is complete, the client and server will each sends to the other a ChangedCipherSpec message, after which traffic will use the negotiated algorithm for encryption.
In SSL/TLS, the encrypted data and the MAC Message Authentication Code, message authentication code, using the following two ways to send:
1, MAC-then-encrypt（message authentication code added key: This mode will first calculate the plain text of the MAC, and compares it with a plain text connection, and then use the encryption algorithm to generate the final ciphertext.
2, the Encrypt-then-MAC the encrypted message authentication code: in this way it will first encrypt the plain text and the encrypted plain text of the MAC Additional in the tail, to form the final ciphertext.
If the ClientHello message does not contain the Encrypt-Then-Mac extension, then by default the use of MAC-then-encrypt mode. If the ClientHello message contains the Encrypt-Then-Mac extension, then the server will be in encrypted data after the calculation of the MAC.
If the client or server wants to change the encryption algorithm, they can be re-negotiated prior to confirmation of the cipher Suite Cipher Suites in. The re-negotiation process may occur in data transmission at any stage, you only need to in the existing SSL connection to initiate an initialization Handshake.
Second, the vulnerability is triggered
On this vulnerability, the OpenSSL official explanation is as follows:
“In the handshake re-negotiation, if the negotiation process is contained in the Encrypt-Then-Mac extension, while the original handshake are not included in the extension and Vice versa, so OpenSSL would crash depending on the used cipher Suite. The client and server will be affected.” the
Assume that the client use the default MAC-then-encrypt mode is initiated with the server in the TLS handshake process. If the client uses the Encrypt-then-MAC extension to initiate a re-negotiation process, and in the ChangeCipherSpec message before the mode of transmission of the encrypted data, then the server would crash, causing a denial of service.
When the client trigger this vulnerability when the server’s crash point is located in the“ssl3_get_record”Function, This function is located in“ssl3_record. c”file, as shown below:
! [](/Article/UploadPic/2017-5/2017522191859454. png? www. myhack58. com)
The collapse point is located in the 352 line, then the program is checking mac_size variable value is less than EVP_MAX_MD_SIZE the value of 64 bytes is:
! [](/Article/UploadPic/2017-5/2017522191859828. png? www. myhack58. com)
the if statement determines the assertions of the statement is established, i.e., determines whether the server is set up for Encypt-then-MAC logo. the if statement in the macro is as follows:
! [](/Article/UploadPic/2017-5/2017522191859320. png? www. myhack58. com)
In the re-negotiation process, when using the Encrypt-then-MAC extension sends a ClientHello packet, TLS1_FLAGS_ECRYPT_THEN_MAC identification has been set. Therefore, if the conditions are met, the program will enter the if internal processes. However, due to the ChangeCipherSpec message is also not transmitted to the server, the server does not know that it must use the Encrypt-then-MAC extension.
On 352 line to set a breakpoint, check the mac_size the value of a variable, we found that the To is 0xffffffff, this value is smaller than EVP_MAX_MD_SIZE of value 64 bytes maximum. Therefore the assertion error, causing the server to crash.
! [](/Article/UploadPic/2017-5/201752219190601. png? www. myhack58. com)
Let’s analyze the source code and see why mac_size value would be 0xffffffff. We found EVP_MD_CTX_size function is responsible for calculating mac_size variable value:
! [](/Article/UploadPic/2017-5/201752219190882. png? www. myhack58. com)
The above code, if the md（message digest, the message digest value is null, the function will return -1, and 0xffffffff is just-1 of the twos complement form. This means that the“s->read_hash”statement returns null, because in this case the server will try to use MAC-then-encrypt mode to calculate the hash value.
The above is the OpenSSL vulnerability analysis process.