CVE-2021-45098 (C, published 2021-12-16T05:15Z)
Description: value: An issue was discovered in Suricata before 6.0.4. It is possible to bypass/evade any HTTP-based signature by faking an RST TCP packet with random TCP options of the md5header from the client side. After the three-way handshake, it's possible to inject an RST ACK with a random TCP md5header option. Then, the client can send an HTTP GET request with a forbidden URL. The server will ignore the RST ACK and send the response HTTP packet for the client's request. These packets will not trigger a Suricata reject action.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/OISF/suricata
Files changed:
src/decode-tcp.c
src/decode-tcp.h
src/stream-tcp.c
Commit message: stream/tcp: handle RST with MD5 or AO header

Special handling for RST packets if they have an TCP MD5 or AO header option.
The options hash can't be validated. The end host might be able to validate
it, as it can have a key/password that was communicated out of band.

The sender could use this to move the TCP state to 'CLOSED', leading to
a desync of the TCP session.

This patch builds on top of
843d0b7a10bb ("stream: support RST getting lost/ignored")

It flags the receiver as having received an RST and moves the TCP state
into the CLOSED state. It then reverts this if the sender continues to
send traffic. In this case it sets the following event:

    stream-event:suspected_rst_inject;

Bug: #4710.


Vulnerable code:

Fixed code:
                /* RFC 2385 MD5 option */
                case TCP_OPT_MD5:
                    SCLogDebug("MD5 option, len %u", olen);
                    if (olen != 18) {
                        ENGINE_SET_INVALID_EVENT(p,TCP_OPT_INVALID_LEN);
                    } else {
                        /* we can't validate the option as the key is out of band */
                        p->tcpvars.md5_option_present = true;
                    }
                    break;
                /* RFC 5925 AO option */
                case TCP_OPT_AO:
                    SCLogDebug("AU option, len %u", olen);
                    if (olen < 4) {
                        ENGINE_SET_INVALID_EVENT(p,TCP_OPT_INVALID_LEN);
                    } else {
                        /* we can't validate the option as the key is out of band */
                        p->tcpvars.ao_option_present = true;
                    }
                    break;
#define TCP_OPT_MD5                          0x13   /* 19: RFC 2385 TCP MD5 option */
#define TCP_OPT_AO                           0x1d   /* 29: RFC 5925 TCP AO option */
    bool md5_option_present;
    bool ao_option_present;
            /* if state is still "closed", it wasn't updated by our dispatch. */
            if (ssn->state == TCP_CLOSED)
                ssn->state = ssn->pstate;
    /* RFC 2385 md5 signature header or RFC 5925 TCP AO headerpresent. Since we can't
     * validate these (requires key that is set/transfered out of band), we can't know
     * if the RST will be accepted or rejected by the end host. We accept it, but keep
     * tracking if the sender of it ignores it, which would be a sign of injection. */
    if (p->tcpvars.md5_option_present || p->tcpvars.ao_option_present) {
        TcpStream *receiver_stream;
        if (PKT_IS_TOSERVER(p)) {
            receiver_stream = &ssn->server;
        } else {
            receiver_stream = &ssn->client;
        }
        SCLogDebug("ssn %p: setting STREAMTCP_STREAM_FLAG_RST_RECV on receiver stream", ssn);
        receiver_stream->flags |= STREAMTCP_STREAM_FLAG_RST_RECV;
    }