wolfSSL prior to 5.6.6 did not check that messages in one (D)TLS record do not span key boundaries. As a result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the server containing first a ServerHello message and then the rest of the first server flight would be accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL client would accept an unencrypted flight from the server. This does not compromise key negotiation and authentication so it is assigned a low severity rating.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - wolfSSL SP Math All RSA implementation is vulnerable to the Marvin Attack, new variation of a timing
    Bleichenbacher style attack, when built with the following options to configure: --enable-all
    CFLAGS="-DWOLFSSL_STATIC_RSA" The define “WOLFSSL_STATIC_RSA” enables static RSA cipher suites, which is
    not recommended, and has been disabled by default since wolfSSL 3.6.6. Therefore the default build since
    3.6.6, even with "--enable-all", is not vulnerable to the Marvin Attack. The vulnerability is specific to
    static RSA cipher suites, and expected to be padding-independent. The vulnerability allows an attacker to
    decrypt ciphertexts and forge signatures after probing with a large number of test observations. However
    the server’s private key is not exposed. (CVE-2023-6935)

  - wolfSSL prior to 5.6.6 did not check that messages in one (D)TLS record do not span key boundaries. As a
    result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most
    extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the
    server containing first a ServerHello message and then the rest of the first server flight would be
    accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL
    client would accept an unencrypted flight from the server. This does not compromise key negotiation and
    authentication so it is assigned a low severity rating. (CVE-2023-6937)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - wolfSSL prior to 5.6.6 did not check that messages in one (D)TLS record do not span key boundaries. As a     result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most     extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the     server containing first a ServerHello message and then the rest of the first server flight would be     accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL     client would accept an unencrypted flight from the server. This does not compromise key negotiation and     authentication so it is assigned a low severity rating. (CVE-2023-6937)

Note that Nessus relies on the presence of the package as reported by the vendor.

The version of mariadb installed on the remote Azure Linux 3.0 host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the CVE-2023-6937 advisory.

  - wolfSSL prior to 5.6.6 did not check that messages in one (D)TLS record do not span key boundaries. As a     result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most     extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the     server containing first a ServerHello message and then the rest of the first server flight would be     accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL     client would accept an unencrypted flight from the server. This does not compromise key negotiation and     authentication so it is assigned a low severity rating. (CVE-2023-6937)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The version of mariadb installed on the remote CBL Mariner 2.0 host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the CVE-2023-6937 advisory.

  - wolfSSL prior to 5.6.6 did not check that messages in one (D)TLS record do not span key boundaries. As a     result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most     extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the     server containing first a ServerHello message and then the rest of the first server flight would be     accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL     client would accept an unencrypted flight from the server. This does not compromise key negotiation and     authentication so it is assigned a low severity rating. (CVE-2023-6937)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Type	Severity
427025	Alpine: multiple wolfssl packages: security update to 5.6.6-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	Local	medium
427025	Alpine: multiple wolfssl packages: security update to 5.6.6-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	Local	medium
227586	Linux Distros Unpatched Vulnerability : CVE-2023-6937	Nessus	Misc.	Local	medium
215618	Azure Linux 3.0 Security Update: mariadb (CVE-2023-6937)	Nessus	Azure Linux Local Security Checks	Local	medium
212790	CBL Mariner 2.0 Security Update: mariadb (CVE-2023-6937)	Nessus	MarinerOS Local Security Checks	Local	medium

Detections

Analytics

CVE-2023-6937

medium

Tenable Plugins

medium

medium

medium

medium

medium