wolfSSL versions prior to 5.5.2 suffer from a heap buffer over-read with WOLFSSL_CALLBACKS and can be triggered with a single Client Hello message.
22c8bd75668677a45f903b9289dfd4de5cffd44e8f21af11820559278a985e59# wolfSSL before 5.5.2: Heap-buffer over-read with WOLFSSL_CALLBACKS
====================================================================
## INFO
=======
The CVE project has assigned the id CVE-2022-42905 to this issue.
Severity: 9.1 CRITICAL
Affected version: before 5.5.2
End of embargo: Ended October 28, 2022
Blog Post: https://blog.trailofbits.com/2023/01/12/wolfssl-vulnerabilities-tlspuffin-fuzzing-ssh/
## SUMMARY
==========
If wolfSSL callback functions are enabled (i.e., the flag `WOLFSSL_CALLBACKS` is
enabled), then a malicious client or network attacker can send a Client Hello
message to a server that when parsed by the server will trigger a buffer
over-read on the heap of at least 5 bytes. Similarly, a malicious server or a
network attacker can send a Hello Retry Request message to a client that when
parsed by the client will trigger a buffer over-read on the heap of at least 15
bytes.
The `AddPacketInfo` is given a buffer that should be the input buffer and that
actually is shifted by 5 bytes on the left, i.e., instead of reading
`input[0]..input[length]`, the function will read `input[-5]..input[length]` and
store it in a buffer that is exposed through the wolfSSL API. Note that `input`
is stored on the heap and `input[-5]` to `input[-1]` might store sensitive data
that should not be given to `AddPacketInfo`, for example when callback functions
are used as logging facility (through the API functions `wolfSSL_accept_ex` and
`wolfSSL_connect_ex`).
This buffer over-read can be triggered at a server with a single Client Hello
message. We have confirmed this with a proof-of-concept test case given below on
wolfSSL 5.5.0, on the version from the master branch, and on version 5.4.0. A
similar buffer over-read can be triggered at a client with the same wolfSSL
versions.
## DETAILS
==========
(Note: All code snippets and line numbers are with respect to the git hash
`#43715d1bb5b8c5b8b18cba4be3171fd1dd7eb046` on remote
`[email protected]:wolfssl/wolfssl.git`.)
When executing the first proof of concept test case given below, we reach a call
to `DoTls13HandShakeMsgType` from `tls13.c:DoTls13HandShakeMsg:10443` when the
server parses the Client Hello message, with the following values:
```c
size = 16520;
totalSz = 16524;
*inOutIdx = 4;
type = 1;
input; // buffer containing the input to be processed, before input,
there seems to be another input stored
```
`*inOutIdx=4` because of the call to `GetHandshakeHeader` at line
`tls13.c:10411`.
We enter the function `tls13.c:DoTls13HandShakeMsgType` and because
`WOLFSSL_CALLBACKS` flag is defined, we enter this snippet:
```c
#if defined(WOLFSSL_CALLBACKS)
/* add name later, add on record and handshake header part back on */
if (ssl->toInfoOn) {
int add = RECORD_HEADER_SZ + HANDSHAKE_HEADER_SZ;
AddPacketInfo(ssl, 0, handshake, input + *inOutIdx - add,
size + add, READ_PROTO, ssl->heap);
AddLateRecordHeader(&ssl->curRL, &ssl->timeoutInfo);
}