# wolfssl before 5.5.1: CVE-2022-39173 Buffer overflow when refining cipher suites ================================================================================== ## INFO ======= The CVE project has assigned the id CVE-2022-39173 to this issue. Severity: high 7.5 Affected version: before 5.5.1 End of embargo: The embargo for this vulnerability ended 29th of September, 2022 ## SUMMARY ========== In wolfSSL before 5.5.1 malicious clients can cause a buffer-overflow during a resumed TLS 1.3 handshake. If an attacker resumes a previous TLS session by sending a maliciously crafted Client Hello, followed by another maliciously crafted Client Hello. In total 2 Client Hellos have to be sent. One which pretends to resume a previous session and a second one as a response to a Hello Retry Request message. The malicious Client Hellos contain a list of supported cipher suites, which contain at least `⌊sqrt(150)⌋ + 1 = 13` duplicates and less than 150 ciphers in total. The buffer-overflow occurs in the `RefineSuites` function. An overflow of 44700 bytes has been confirmed. Therefore, large portions of the stack can get overwritten, including return addresses. We confirmed the vulnerability by sending packets over TCP to a Wolfssl server, freshly built from the sources with the `--enable-session-ticket` flags (or simply `--enable-all`). We can provide sources for our software (tlspuffin) that produce those packets (and that automatically found the attack trace). The command given at the end of this document triggers the buffer overflow. It is very likely that there is a way to craft an exploit which can cause a RCE. We have not yet created such an exploit as it would likely depend on the memory layout of the binary which uses wolfSSL. Moreover, the size of the overflow can be fine-tuned in order to not smash the stack and continue the execution with a too large length of suites buffer and that will cause other routines that iterate over thus buffer (e.g., `FindSuiteSSL`) to misbehave. Hypothetically, this might be exploited to make the server use a cipher it should not accept such as `nullcipher` that would open up new attack vectors such as downgrade attacks. While this has not been confirmed yet, the buffer overflow itself has been confirmed. ## DETAILS ========== Line numbers below are valid for the wolfSSL Git tag [v5.4.0-stable](https://github.com/wolfSSL/wolfssl/tree/v5.4.0-stable). The bug we found is in the `RefineSuites` function. In the following we want to explain why the function is able to overflow the `suites` array. ```c /* Refine list of supported cipher suites to those common to server and client. * * ssl SSL/TLS object. * peerSuites The peer's advertised list of supported cipher suites. */ static void RefineSuites(WOLFSSL* ssl, Suites* peerSuites) { byte suites[WOLFSSL_MAX_SUITE_SZ]; word16 suiteSz = 0; word16 i, j; XMEMSET(suites, 0, WOLFSSL_MAX_SUITE_SZ); for (i = 0; i < ssl->suites->suiteSz; i += 2) { for (j = 0; j < peerSuites->suiteSz; j += 2) { if (ssl->suites->suites[i+0] == peerSuites->suites[j+0] && ssl->suites->suites[i+1] == peerSuites->suites[j+1]) { suites[suiteSz++] = peerSuites->suites[j+0]; suites[suiteSz++] = peerSuites->suites[j+1]; } } } ssl->suites->suiteSz = suiteSz; XMEMCPY(ssl->suites->suites, &suites, sizeof(suites)); #ifdef WOLFSSL_DEBUG_TLS [...] #endif } ``` tls13.c:4355 The `RefineSuites` function expects a `WOLFSSL` struct which contains a list of acceptable ciphers suites (`ssl->suites->suites`), as well as an array of peer cipher suites (`peerSuites`). Both inputs are bounded by `WOLFSSL_MAX_SUITE_SZ`, which is equal to 300 bytes or 150 cipher suites. Let us assume that `ssl->suites` consists of a single cipher suite like `TLS_AES_256_GCM_SHA384` and the `peerSuites` list contains the same cipher repeated thirteen times. The `RefineSuites` function will iterate for each element in `ssl->suites` over `peerSuites` and append the suite to `suites` if it is a match. The `suites` array has a maximum length of `WOLFSSL_MAX_SUITE_SZ == 300 bytes == 150 suites`. With the just mentioned example input, the length of `suites` will now equal thirteen. The `suites` array is now copied to the `WOLFSSL` struct in the last line of the listing above. Therefore, `ssl->suites` contains now thirteen times the `TLS_AES_256_GCM_SHA384` cipher suite. Let us now call the same `RefineSuites` function again on the modified `WOLFSSL` struct and the same `peerSuites` list. The `RefineSuites` function will iterate for each element in `ssl->suites` over `peerSuites` and append the suite to `suites` if it is a match. Because `ssl->suites` contains already 13 times the `TLS_AES_256_GCM_SHA384` cipher suite, in total 13 x 13 = 169 cipher suites are written to `suites`. 169 cipher suites require 338 bytes, which is more than what's available on the stack. The `suites` buffer overflows. The maximum size of `peerSuites` is 150 cipher suites. Therefore, an overflow of 44700 bytes is possible and has been confirmed. The buffer `ssl->suites->suites` is supposed to be reset to only contain the acceptable ciphers at each session start, and thus initially contains no duplicate. However, by provoking a `HELLO CLIENT RETRY REQUEST`, it is possible to make the server call `RefineSuites` twice as explained next. ## TRIGGERING THE BUFFER OVERFLOW ================================= In order to cause the above buffer-overflow, it is required to call `RefineSuites` twice. Malicious clients need to perform the handshake in a certain way to reach this situation. The buffer overflow at the attacked server can be obtained at least in the following situation: 1. Resume the previous session by sending a second Client Hello (`CH2`) with the following criteria: - Exclude the `support_group_extension`, to cause a Hello Retry Request - Include a binder which cryptographically binds this session to the previous one. - Include a list of cipher suites that contains a repetition of `n` times the same cipher `c` with `13 <= n < 150`, deemed acceptable by the server. The server will parse this message, enters the state `SERVER_HELLO_RETRY_REQUEST_COMPLETE` and stores at least `n` times the cipher `c` in `ssl->suites->suites` by calling `RefineSuites`. 2. Sending a third Client Hello (`CH3`) with the same criteria as in step 2. The server will parse this message and because `ssl->suites->suites` already contains `n` times the cipher `c`, `RefineSuites` will write in `suites` at least until `suites[nˆ2]` which overflows since `nˆ2 > 300`. ## DETAILS ABOUT STEP 1. ======================== During step 2., we want to cause the server to perform a Hello Retry Request. This is possible by not sending a supported group in the `CH2`. By not sending a support group extension, the function `TLSX_SupportedGroups_Find` will return false. ```c static int TLSX_SupportedGroups_Find(WOLFSSL* ssl, word16 name) { ... /* Check consistency now - extensions in any order. */ if (!TLSX_SupportedGroups_Find(ssl, clientKSE->group)) continue; ... ``` tls.c:8374 This will cause clientKSE to be `NULL` and `doHelloRetry` will be set to 1. ```c int TLSX_KeyShare_Establish(WOLFSSL *ssl, int* doHelloRetry) { ... /* No supported group found - send HelloRetryRequest. */ if (clientKSE == NULL) { /* Set KEY_SHARE_ERROR to indicate HelloRetryRequest required. */ *doHelloRetry = 1; return TLSX_KeyShare_SetSupported(ssl); } ... ``` tls.c:9273 Finally, the server enters the state `SERVER_HELLO_RETRY_REQUEST_COMPLETE` in the function `VerifyServerSuite` while verifying the server suite when processing `CH2`. ```c /* Make sure server cert/key are valid for this suite, true on success * Returns 1 for valid server suite or 0 if not found * For asynchronous this can return WC_PENDING_E */ static int VerifyServerSuite(WOLFSSL* ssl, word16 idx) { ... if (IsAtLeastTLSv1_3(ssl->version) && ssl->options.side == WOLFSSL_SERVER_END) { int doHelloRetry = 0; /* Try to establish a key share. */ int ret = TLSX_KeyShare_Establish(ssl, &doHelloRetry); if (doHelloRetry) { ssl->options.serverState = SERVER_HELLO_RETRY_REQUEST_COMPLETE; } ... } ... ``` tls.c:30688 ## DETAILS ABOUT STEP 2. ==================== The server is now in a state in which it expects another Client Hello (`CH3`) from the client. The server is now in the state `SERVER_HELLO_RETRY_REQUEST_COMPLETE` and will process the third ClientHello (`CH3`) with the call of `ProcessReply` before reaching the `TLS13_ACCEPT_SECOND_REPLY_DONE` state. ```c int wolfSSL_accept_TLSv13(WOLFSSL* ssl) { ... case TLS13_ACCEPT_FIRST_REPLY_DONE : if (ssl->options.serverState == SERVER_HELLO_RETRY_REQUEST_COMPLETE) { ssl->options.clientState = CLIENT_HELLO_RETRY; while (ssl->options.clientState < CLIENT_HELLO_COMPLETE) { if ((ssl->error = ProcessReply(ssl)) < 0) { WOLFSSL_ERROR(ssl->error); return WOLFSSL_FATAL_ERROR; } } } ssl->options.acceptState = TLS13_ACCEPT_SECOND_REPLY_DONE; WOLFSSL_MSG("accept state ACCEPT_SECOND_REPLY_DONE"); FALL_THROUGH; ... ``` tls13.c:10909 ## VULNERABILITY VARIANTS ========================= ### Adjusting the overflow Note that the length of the list of ciphers in `CH2` does not necessarily have to be the same as the one of `CH1` and can be adjusted to fine-tune the size of the overflow. ### Make the server parse `CH2` Note also that, on the contrary to `CH1`, `CH2` does not necessarily have to put the server in the `SERVER_HELLO_RETRY_REQUEST_COMPLETE` state (which should be forbidden by the TLS 1.3 RFC) or make it return an error, and can thus contain a supported group, which could be included to possibly make the server continue the processing of `CH2` without returning an error. We have confirmed that we can make the server parses `CH2` until the end and starts computing a Server Hello with `ssl->suites->suiteSz` that exceeds 300. ### Resuming an existent session It is also possible to trigger the vulnerability by trying to resume an existent and genuine session established through a full initial handshake (step 0.): 0. Sending an initial genuine Client Hello (`CH1`) to the server and then completing a full handshake, thus establishing a PSK. ## EXPLOITATION =============== We suspect that it is possible to craft an exploit which could lead to RCE if any of the above bytes coincides with the memory address of executable code. Depending on the memory layout of the binary it could be possible to gain RCE. More bytes could be used to overflow `suites` if more ciphers were configured to be accepted with the server, e.g., with options like `--enable-blake2`. We confirmed that this could also be exploited to smash the stack and cause the server to crash with a segmentation fault by using a large list of ciphers. Finally, by fine-tuning the length of the overflow and by including the supported group in `CH3`, it could be possible to make the server process `CH3` with a `ssl->suites->suites->suiteSz` value that exceeds 300. This way, routines like `FindSuiteSSL` that will iterate over `ssl->suites->suites` (allocated on 300 bytes) until `ssl->suites->suiteSz` (>300) will also iterate over bytes that contain other fields such as `ssl->suites->hashSigAlgo`. It is likely that this could be exploited to make such routines return arbitrary values. For example, it might be exploited to make the server use a cipher it should not accept such as `nullcipher`; thus breaking confidentiality. ## FURTHER CONCERNS ================== We observed that the server is accepting the `CH2` Client Hello message and issues a Hello Retry Request, even though `CH2` does not contain supported groups. Clients are not allowed to add the supported groups extension in the retry Client Hello (`CH3`) according to the RFC 8446 in section [4.1.2](https://www.rfc-editor.org/rfc/rfc8446#section-4.1.2). The addition of supported groups is not allowed when retrying the Client Hello. We suggest aborting the handshake when receiving `CH2` instead of offering the client a retry.