what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

wolfSSL WOLFSSL_CALLBACKS Heap Buffer Over-Read

wolfSSL WOLFSSL_CALLBACKS Heap Buffer Over-Read
Posted Jan 20, 2023
Authored by Maximilian Ammann

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.

tags | exploit
advisories | CVE-2022-42905
SHA-256 | 22c8bd75668677a45f903b9289dfd4de5cffd44e8f21af11820559278a985e59

wolfSSL WOLFSSL_CALLBACKS Heap Buffer Over-Read

Change Mirror Download
# 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
`git@github.com: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);
}
#endif
```

`tls13.c:DoTls13HandShakeMsgType:10094`

We have that `RECORD_HEADER_SZ = 5` and `HANDSHAKE_HEADER_SZ = 4` so `add = 9`
while `*inOutIdx` is still set to `4`. Therefore, the pointer indicating the
beginning of the alleged input that is given to the `AddPacketInfo` function
(argument `data`) is `data = input + *inOutIdx - add = input - 5`. This buffer
starts 5 bytes before the actual input buffer. The argument `sz = size + add` is
the total length of the input, which is too long here `16529` instead of `16524`
bytes.

It seems the snippet above makes a wrong assumption about the past increases of
`*inOutIdx`, which has not been increased by `RECORD_HEADER_SZ` as no record
header has been parsed yet.

Next, in `internal.c:AddPacketInfo:25153`, see the snippet:

```c
/* add data, put in buffer if bigger than static buffer */
info->packets[info->numberPackets].valueSz = sz;

if (sz < MAX_VALUE_SZ)
XMEMCPY(info->packets[info->numberPackets].value, data, sz);
else {
info->packets[info->numberPackets].bufferValue = (byte*)XMALLOC(sz,
heap, DYNAMIC_TYPE_INFO);

if (!info->packets[info->numberPackets].bufferValue)
/* let next alloc catch, just don't fill, not fatal here */
info->packets[info->numberPackets].valueSz = 0;
else
XMEMCPY(info->packets[info->numberPackets].bufferValue, data, sz);
}
```

`internal.c:AddPacketInfo:25169`

and recall that `sz = 16529`, `data = input - 5`. The last line will write
`input[-5]..input[16524]` into `info->packets[0]`. Recall that
`info->packets[0]` equals `ssl->timeoutInfo->packets[0]`.

It turns out `ssl->timeoutInfo` and in particular the content of
`ssl->timeoutInfo->packets[0]` is exposed to the wolfSSL user through the
functions `wolfSSL_connect_ex` and `wolfSSL_accept_ex` whose declarations are as
follows (where `typedef int (*TimeoutCallBack)(TimeoutInfo*);` from `ssl.h`);
see also the
[wolfSSL documentation](https://www.wolfssl.com/documentation/manuals/wolfssl/chapter06.html).

Therefore, in addition to the over-read per se, this might be exploited to
exfiltrate sensitive data, depending on the use case.

## POTENTIAL EXPLOITATION
=========================

We found no systematic exploit using this bug but it could be exploited in some
specific use cases. We note that this problem only occurs when
`WOLFSSL_CALLBACKS` is enabled, but we found no documentation forbidding the use
of this flag in production.

For instance, a wolfSSL server could be configured to use the API function
`wolfSSL_connect_ex` with an argument `srvTimeoutCB`. This argument could be a
function that logs on disk the content of `timeoutInfo->packets` when the
incoming message has a packet name (packetName) "ClientHello". The rationale
being that logging Client Hello messages should not expose sensitive and secret
information on disk (assuming logs are not well-protected). Because of this bug,
the log will contain extra data from the heap that do not correspond to the
received Client Hello message and that could be sensitive data.

Here is a threat model for which this could be a problem:

- attacker has partial access to the architecture, for example log files (log
files could be stored at rest and because considered less sensitive, they are
less secured),
- wolfSSL server is set up to use callback functions to log some allegedly
non-sensitive information, for example it logs the received packets (let us
say client hello for now) that were rejected by the server for future
inspection. But it does not log full handshake.

Then the attacker can trigger at will the bug to write in the log some bytes of
the heap, it could theoretically fine-tune the timing to exfiltrate data of
interest.

## POTENTIAL REMEDIATION
========================

First, the use of `WOLFSSL_CALLBACKS` could be vehemently discouraged in
production. Second, the flawed logic of `tls13.c:DoTls13HandShakeMsgType`
exposed above should be fixed. The addition of `RECORD_HEADER_SZ` to `add`
should be conditionded by whether a record layer header was processed or not.

In `internal.c:AddPacketInfo` and for a similar input message without a record
header, the lines below call `ssl->protoMsgCb` on a (right) shifted input
buffer:

```c
ssl->protoMsgCb(written, version, type,
(const void *)(data + RECORD_HEADER_SZ),
(size_t)(sz - RECORD_HEADER_SZ),
ssl, ssl->protoMsgCtx);
```

This does not trigger a buffer overflow but yields inconsistent log messages.

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close