If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.

HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

Quicly is an IETF QUIC protocol implementation intended primarily for use within the H2O HTTP server. Prior to commit dccf5d4, Quicly was vulnerable to stateless reset injection through lack of packet entry validation. The QUIC protocol is designed to withstand packet injection attacks, once the handshake is complete. Only packets that carry some secret patterns are considered as stateless resets. Quicly allows the peer to share up to 4 such patterns per connection. However, until now, it failed to determine which of the 4 slots that it uses to retain the secret patterns contains a valid entry. As the slots are zero-initialized, the failure meant that, unless the peer advertised 4 of such patterns, an all-zero pattern was treated as a stateless reset.In effect, this allowed an on-path attacker to reset QUIC connections governed by Quicly. This issue has been fixed by commit dccf5d4.

Bleichenbacher's attack on PKCS #1 v1.5 padding for RSA in Microchip Libraries for Applications 2018-11-26 All up to 2018-11-26. The vulnerability can allow one to use Bleichenbacher's oracle attack to decrypt an encrypted ciphertext by making successive queries to the server using the vulnerable library, resulting in remote information disclosure.

Bleichenbacher's attack on PKCS #1 v1.5 padding for RSA in STM32 cryptographic firmware library software expansion for STM32Cube (UM1924). The vulnerability can allow one to use Bleichenbacher's oracle attack to decrypt an encrypted ciphertext by making successive queries to the server using the vulnerable library, resulting in remote information disclosure.

In certain IETF OAuth 2.0-related specifications, when the JSON Web Token Profile for OAuth 2.0 Client Authentication mechanism is used, there are ambiguities in the audience values of JWTs sent to authorization servers. The affected RFCs may include RFC 7523, and also RFC 7521, RFC 7522, RFC 9101 (JAR), and RFC 9126 (PAR).

The Service Location Protocol (SLP, RFC 2608) allows an unauthenticated, remote attacker to register arbitrary services. This could allow the attacker to use spoofed UDP traffic to conduct a denial-of-service attack with a significant amplification factor.

Common Vulnerabilities and Exposures assigned an identifier CVE-2004-2761 to the following vulnerability:

The MD5 Message-Digest Algorithm is not collision resistant, which makes it easier for context-dependent attackers to conduct spoofing attacks, as demonstrated by attacks on the use of MD5 in the signature algorithm of an X.509 certificate.

References: http://www.kb.cert.org/vuls/id/836068 http://eprint.iacr.org/2004/199 http://eprint.iacr.org/2005/067 http://www.win.tue.nl/hashclash/rogue-ca/ http://www.phreedom.org/research/rogue-ca/ http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/

An issue was discovered in the IPv6 protocol specification, related to ICMP Packet Too Big (PTB) messages. (The scope of this CVE is all affected IPv6 implementations from all vendors.) The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily.

We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario.

Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic.

References: https://tools.ietf.org/html/rfc8021 Patches: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=9d289715eb5c252ae15bd547cb252ca547a3c4f2

In QUIC in RFC 9000, the Latency Spin Bit specification (section 17.4) does not strictly constrain the bit value when the feature is disabled, which might allow remote attackers to construct a covert channel with data represented as changes to the bit value. NOTE: The "Sheridan, S., Keane, A. (2015). In Proceedings of the 14th European Conference on Cyber Warfare and Security (ECCWS), University of Hertfordshire, Hatfield, UK." paper says "Modern Internet communication protocols provide an almost infinite number of ways in which data can be hidden or embed whithin seemingly normal network traffic."

Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length and Ethernet to Wifi frame conversion (and optionally VLAN0 headers).

Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length (and optionally VLAN0 headers)

Layer 2 network filtering capabilities such as IPv6 RA guard or ARP inspection can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers.

Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using combinations of VLAN 0 headers, LLC/SNAP headers, and converting frames from Ethernet to Wifi and its reverse.

IPv4-in-IPv6 and IPv6-in-IPv6 tunneling (RFC 2473) do not require the validation or verification of the source of a network packet, allowing an attacker to spoof and route arbitrary traffic via an exposed network interface. This is a similar issue to CVE-2020-10136.

IPv6-in-IPv4 tunneling (RFC 4213) allows an attacker to spoof and route traffic via an exposed network interface.

GRE and GRE6 Protocols (RFC2784) do not validate or verify the source of a network packet allowing an attacker to spoof and route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.

Proposed Generic UDP Encapsulation (GUE) (IETF Draft) do not validate or verify the source of a network packet allowing an attacker to spoof and route arbitrary traffic via an exposed network interface that can lead to spoofing, access control bypass, and other unexpected network behaviors. This can be considered similar to CVE-2020-10136.

Affected Vendor IETF Every vendor who implements a product supporting RADIUS

Affected Product RFC 2865

Affected Version RFC 2865

Significant ICS/OT impact? no

Reporter Nadia Heninger [nadiah.edu] University of California San Diego

Vendor contacted? yes We have reached out to the IETF. This vulnerability will affect a large number of vendors and we have not reached out to any individual vendors yet.

Description We have an efficient forgery attack against the Response Authenticator used to authenticate RADIUS server Access-Accept or Access-Reject messages. This is a protocol vulnerability against RFC 2865 and applies to RADIUS/UDP. It allows a man-in-the-middle attacker to forge a valid Access-Accept response to a client request that has been rejected by the RADIUS server, and gain access to the network resources and devices for which the RADIUS client may authorize users.

The Response Authenticator is an MD5 hash of values from the RADIUS client request and server response together with a fixed shared secret (unknown to our attacker) that is shared between the RADIUS client and server. The first byte of an Access-Accept and Access-Reject message differ. The attacker executes a so-called chosen-prefix collision attack on MD5 to change the message type in the first byte and any relevant packet attributes while ensuring that the Access-Reject and forged Access-Accept both produce the same Response Authenticator. Once an MD5 chosen-prefix hash collision has been computed, any fixed value appended to the two messages will continue to produce an MD5 hash collision. In particular, the attacker can compute a collision with known values such that when the client or server append the secret to compute the Response Authenticator, it will still produce the same hash value.

Computing an MD5 chosen-prefix hash collision requires predicting the Access-Reject message and appending as few as 80 bytes of collision block gibberish to the Access-Request sent to the server. In our attack, the attacker encapsulates this collision-block gibberish in Proxy-State attributes that are required by the RFC to be returned by the server in its response and are hence also present in the Access-Reject produced by the server. These gibberish values ensure the Response Authenticator computed from the Access-Reject and will be a correct Response Authenticator for the forged Access-Accept. Exploit To exploit this vulnerability, an attacker needs man-in-the-middle network access between the RADIUS client and server, and the client and server must be using RADIUS/UDP to communicate. The attacker also needs to be able to trigger a RADIUS client Access-Request, by for example entering a username and (incorrect) password at a login prompt on a victim device. The simplest case is when the client is using PAP authentication.

The attacker observes the Access-Request packet (in particular the random ID and Request Authenticator values included in the request) and predicts the attributes that will be returned in the Access-Reject response that is expected to be returned by the server.

The attacker then computes an MD5 chosen-prefix collision online, before the client times out its request. With our computing power, we are currently able to compute such a collision in as little as 5 to 6 minutes; we expect to continue to improve this, and a well-resourced attacker with the ability to implement this attack on FPGAs would certainly be able to improve this time to seconds.

Once the attacker has computed the MD5 collision, the attacker inserts the corresponding collision blocks into one or more Proxy-State attributes in the request, and removes any Message-Authenticator attributes from the request. (This is allowed and undetectable when using PAP authentication.) The attacker sends this modified client request to the RADIUS server.

The attacker then receives the expected Access-Reject response from the RADIUS server, and copies the Response Authenticator value from the Access-Reject to the colliding Access-Accept packet that it forges. This packet will include some Proxy-State attributes containing the collision block gibberish; we have verified that these attributes are accepted by clients.

The attacker then forwards its modified Access-Accept response to the client, which should successfully let the attacker log in.

We have attached a file poc.md showing logs and values with a sample colliding request. Impact An attacker gains access to any resource for which RADIUS is used for authentication/authorization. RADIUS/UDP appears to be commonly used within enterprise networks and organizations to provide admin access to routing infrastructure, user logins for VPNs, for Wi-Fi access via WPA-enterprise, and as a lightweight authentication mechanism for a variety of networked devices and hardware. RADIUS is supported by cloud authentication services like Duo and Okta as well. Discovery This vulnerability was discovered by Mike Milano, Sharon Goldberg, Nadia Heninger, Dan Shumow, Marc Stevens, Miro Haller, and Adam Suhl. We discovered it by reading the RFC, examining the behavior of the RADIUS client and server implementations we currently have access to (FreeRadius, Okta, a Cisco ASA 5505), and optimizing Marc Stevens's Hashclash MD5 collision software for our particular case.

Has been exploited? no

Is public? no

Disclosure Plans? yes We plan to submit a paper to the Usenix Security conference. The paper will be confidential except to the program committee. The submission deadline is February 8 and the conference takes place August 14-16. We are fine with coordinating the public disclosure deadline with vendors.

The IPv6 protocol allows remote attackers to cause a denial of service via crafted IPv6 type 0 route headers (IPV6RTHDRTYPE0) that create network amplification between two routers.

The TLS protocol 1.2 and earlier supports the rsafixeddh, dssfixeddh, rsafixedecdh, and ecdsafixedecdh values for ClientCertificateType but does not directly document the ability to compute the master secret in certain situations with a client secret key and server public key but not a server secret key, which makes it easier for man-in-the-middle attackers to spoof TLS servers by leveraging knowledge of the secret key for an arbitrary installed client X.509 certificate, aka the "Key Compromise Impersonation (KCI)" issue.

The Internet Key Exchange v1 main mode is vulnerable to offline dictionary or brute force attacks. Reusing a key pair across different versions and modes of IKE could lead to cross-protocol authentication bypasses. It is well known, that the aggressive mode of IKEv1 PSK is vulnerable to offline dictionary or brute force attacks. For the main mode, however, only an online attack against PSK authentication was thought to be feasible. This vulnerability could allow an attacker to recover a weak Pre-Shared Key or enable the impersonation of a victim host or network.