5cb4d6466a
Follow on from CVE-2016-2179 The investigation and analysis of CVE-2016-2179 highlighted a related flaw. This commit fixes a security "near miss" in the buffered message handling code. Ultimately this is not currently believed to be exploitable due to the reasons outlined below, and therefore there is no CVE for this on its own. The issue this commit fixes is a MITM attack where the attacker can inject a Finished message into the handshake. In the description below it is assumed that the attacker injects the Finished message for the server to receive it. The attack could work equally well the other way around (i.e where the client receives the injected Finished message). The MITM requires the following capabilities: - The ability to manipulate the MTU that the client selects such that it is small enough for the client to fragment Finished messages. - The ability to selectively drop and modify records sent from the client - The ability to inject its own records and send them to the server The MITM forces the client to select a small MTU such that the client will fragment the Finished message. Ideally for the attacker the first fragment will contain all but the last byte of the Finished message, with the second fragment containing the final byte. During the handshake and prior to the client sending the CCS the MITM injects a plaintext Finished message fragment to the server containing all but the final byte of the Finished message. The message sequence number should be the one expected to be used for the real Finished message. OpenSSL will recognise that the received fragment is for the future and will buffer it for later use. After the client sends the CCS it then sends its own Finished message in two fragments. The MITM causes the first of these fragments to be dropped. The OpenSSL server will then receive the second of the fragments and reassemble the complete Finished message consisting of the MITM fragment and the final byte from the real client. The advantage to the attacker in injecting a Finished message is that this provides the capability to modify other handshake messages (e.g. the ClientHello) undetected. A difficulty for the attacker is knowing in advance what impact any of those changes might have on the final byte of the handshake hash that is going to be sent in the "real" Finished message. In the worst case for the attacker this means that only 1 in 256 of such injection attempts will succeed. It may be possible in some situations for the attacker to improve this such that all attempts succeed. For example if the handshake includes client authentication then the final message flight sent by the client will include a Certificate. Certificates are ASN.1 objects where the signed portion is DER encoded. The non-signed portion could be BER encoded and so the attacker could re-encode the certificate such that the hash for the whole handshake comes to a different value. The certificate re-encoding would not be detectable because only the non-signed portion is changed. As this is the final flight of messages sent from the client the attacker knows what the complete hanshake hash value will be that the client will send - and therefore knows what the final byte will be. Through a process of trial and error the attacker can re-encode the certificate until the modified handhshake also has a hash with the same final byte. This means that when the Finished message is verified by the server it will be correct in all cases. In practice the MITM would need to be able to perform the same attack against both the client and the server. If the attack is only performed against the server (say) then the server will not detect the modified handshake, but the client will and will abort the connection. Fortunately, although OpenSSL is vulnerable to Finished message injection, it is not vulnerable if *both* client and server are OpenSSL. The reason is that OpenSSL has a hard "floor" for a minimum MTU size that it will never go below. This minimum means that a Finished message will never be sent in a fragmented form and therefore the MITM does not have one of its pre-requisites. Therefore this could only be exploited if using OpenSSL and some other DTLS peer that had its own and separate Finished message injection flaw. The fix is to ensure buffered messages are cleared on epoch change. Reviewed-by: Richard Levitte <levitte@openssl.org> |
||
|---|---|---|
| .. | ||
| dtls1_bitmap.c | ||
| README | ||
| rec_layer_d1.c | ||
| rec_layer_s3.c | ||
| record.h | ||
| record_locl.h | ||
| ssl3_buffer.c | ||
| ssl3_record.c | ||
Record Layer Design
===================
This file provides some guidance on the thinking behind the design of the
record layer code to aid future maintenance.
The record layer is divided into a number of components. At the time of writing
there are four: SSL3_RECORD, SSL3_BUFFER, DLTS1_BITMAP and RECORD_LAYER. Each
of these components is defined by:
1) A struct definition of the same name as the component
2) A set of source files that define the functions for that component
3) A set of accessor macros
All struct definitions are in record.h. The functions and macros are either
defined in record.h or record_locl.h dependent on whether they are intended to
be private to the record layer, or whether they form part of the API to the rest
of libssl.
The source files map to components as follows:
dtls1_bitmap.c -> DTLS1_BITMAP component
ssl3_buffer.c -> SSL3_BUFFER component
ssl3_record.c -> SSL3_RECORD component
rec_layer_s3.c, rec_layer_d1.c -> RECORD_LAYER component
The RECORD_LAYER component is a facade pattern, i.e. it provides a simplified
interface to the record layer for the rest of libssl. The other 3 components are
entirely private to the record layer and therefore should never be accessed
directly by libssl.
Any component can directly access its own members - they are private to that
component, e.g. ssl3_buffer.c can access members of the SSL3_BUFFER struct
without using a macro. No component can directly access the members of another
component, e.g. ssl3_buffer cannot reach inside the RECORD_LAYER component to
directly access its members. Instead components use accessor macros, so if code
in ssl3_buffer.c wants to access the members of the RECORD_LAYER it uses the
RECORD_LAYER_* macros.
Conceptually it looks like this:
libssl
|
---------------------------|-----record.h--------------------------------------
|
_______V______________
| |
| RECORD_LAYER |
| |
| rec_layer_s3.c |
| ^ |
| _________|__________ |
|| ||
|| DTLS1_RECORD_LAYER ||
|| ||
|| rec_layer_d1.c ||
||____________________||
|______________________|
record_locl.h ^ ^ ^
_________________| | |_________________
| | |
_____V_________ ______V________ _______V________
| | | | | |
| SSL3_BUFFER | | SSL3_RECORD | | DTLS1_BITMAP |
| |--->| | | |
| ssl3_buffer.c | | ssl3_record.c | | dtls1_bitmap.c |
|_______________| |_______________| |________________|
The two RECORD_LAYER source files build on each other, i.e.
the main one is rec_layer_s3.c which provides the core SSL/TLS layer. The second
one is rec_layer_d1.c which builds off of the SSL/TLS code to provide DTLS
specific capabilities. It uses some DTLS specific RECORD_LAYER component members
which should only be accessed from rec_layer_d1.c. These are held in the
DTLS1_RECORD_LAYER struct.