alexander ነጋሲ

Denial-of-service CVE research

CVE-2022-3786: X.509 email address variable length buffer overflow causing DoS

CVE-2022-3786 is a high-severity buffer overflow vulnerability that affects OpenSSL versions 3.0–3.0.6. The vulnerability affects the validation of the email address field in X.509 certificates. To exploit this vulnerability an attacker will have to craft a malicious address in a certificate, signed by a trusted certificate authority (CA), to trigger a buffer overflow They would add an arbitrary amount of bytes containing the ‘.’ character. This overflow would cause the system to crash, leading to a denial of service (DoS). Since the attacker can only cause an overflow with the period character and is not able to manipulate the memory, the attacker is unable to gain control of the system unlike its counterpart CVE-2022-3602.

The vulnerability was first discovered during an internal code review by the OpenSSL project. CVE-2022-3786 was publicly disclosed near the end of October 2022, as well as a related issue CVE-2022-3602. A patch version 3.07 was released on November 1 to resolve this issue.

The diagram below shows the difference between a system that can be exploited and a system that cannot be exploited using some test cases.

OpenSSL 3.x.x is used by several popular Linux distributions and operation systems. Here are a few that were affected by this vulnerability:

After the attack has been successful, there would be logs in the system that would capture unexpected termination due to the buffer overflow. For example, on Linux system logs, /var/log/syslog or /var/log/messages, will show crashes, file dumps, or segmentation faults on OpenSSL’s handling of certificates if there was a DoS.

An intrusion detection system (IDS) that is capable of detecting an abnormal email field length in certificates can easily flag the exploit as suspicious. Since the overflow requires the attacker to craft a long sequence of ‘.’ characters, the IDS could be configured to catch these types of vulnerabilities. Since OpenSSL is mainly focused on providing secure communication over HTTPS, the IDS can look for any indication of unusual patterns, such as sudden crashes or timeouts in the TLS handshake.

The root of the vulnerability comes from the lack of proper bounds checking with the OpenSSL process in the email address field of the X.509 certificate. Specifically, it fails to check the number of ‘.’ characters, allowing an attacker to cause a buffer overflow. They fixed the issue by adding a proper bound check to prevent buffer overflow and restrict how many bytes it can write to memory. The three figures below resolved the OpenSSL vulnerability known as CVE-2022-3786.

To conclude, the vulnerability addressed in the release of OpenSSL version 3.0.7, fixed the buffer flow, significantly reducing the risk and ensuring security across the affected Linux distributions. Being able to catch and resolve the issue in a reasonable amount of time, ensured that no systems were seriously compromised. This reinforces the importance of prompt vulnerability management.

CVE-2023-44487: HTTP/2 Rapid Reset vulnerability causing DoS

1 Background and scope

CVE-2023-44487, also known as the HTTP/2 Rapid Reset attack, is a high severity DoS vulnerability (7.5 CVSS) that exploits the design of the HTTP/2 protocol to overwhelm server resources with minimal client effort. By exploiting the RST_STREAM frame feature in HTTP/2, attackers can rapidly cancel multiple streams after initiating them, causing significant resource consumption on the server side without requiring substantial bandwidth from the attacker.

First observed in mid-2023, this attack gained publicity for its ability to mount massive Layer 7 DoS attacks, with cloud providers like AWS, Google, and Cloudflare reporting record-setting attack peaks exceeding hundreds of millions of requests per second. This vulnerability is particularly dangerous due to its reliance on HTTP/2’s stream multiplexing capability, which was designed to improve web communication efficiency but when abused allows attackers to launch asymmetric and devastating DoS attacks. The scope of this vulnerability is significant, with 35% of all public websites using HTTP/2 as of October 2024. The preceding and succeeding HTTP versions HTTP/1.1 and HTTP/3 remain unaffected.

2 Protocol flaw and exploitation

The root cause of the Rapid Reset vulnerability lies in how HTTP/2 allows clients to unilaterally reset streams without coordination with the server. Specifically, the RST_STREAM frame allows clients to signal the cancellation of streams that are in-flight, but without necessarily closing the underlying TCP connection. This creates a resource exhaustion attack vector where the server is forced to do significant work (allocating memory, decompression of headers, URL mapping) for requests that are immediately canceled​

Attackers can open multiple streams, send requests, and then immediately reset them, effectively forcing the server into a cycle of high resource consumption while ignoring the server’s setting for maximum number of concurrent streams allowed. This is what allows attackers to execute such large-scale attacks from botnets or other lightweight systems at very low operational costs​.

3 Proof-of-concept demonstration

Using the proof-of-concept (PoC) application reset-rabbit developed by Patrick Tulskie, we can reproduce a DoS on a vulnerable webserver. The setup involves building a Docker container containing a test Apache webserver and then launching a Go exploit script to open and immediately cancel streams in an indefinite loop.

The following command executes the exploit script: ./reset-rabbit -url https://localhost -limit 1

The URL to send requests to is set to localhost and the number of concurrent goroutines is limited to 1. The website status is reported via the attacker’s terminal and can be verified by visiting the specified URL.

Figure 1: Live report of (a) website status and (b) HTTP/2 requests sent to dockerized webserver

4 Traces in system logs and detection

System logs during a Rapid Reset attack are characterized by many RST_STREAM frames following HEADERS frames almost instantaneously. This atypical traffic sequence can be detected by monitoring traffic behavior. However, due to the unique nature of the attack not being based on a software bug or misconfiguration and lacking in clear indicators of compromise, it may take some time before intrusion detection systems trigger alerts.

Resource monitoring tools like htop can provide comprehensive resource utilization statistics during the DoS attack to help analysts better distinguish between baseline and anomalous activity. The following screenshots present such evidence from the successful PoC exploit.

Figure 2: View of CPU usage in htop (a) before and (b) after PoC exploit (Note: CPU usage maxed out momentarily after the exploit but could not be captured due to the Docker container freezing early)

5 Conclusion and countermeasures

CVE-2023-44487 highlights the dangers of design flaws within protocol efficiency mechanisms. While HTTP/2 was designed to streamline communication by multiplexing streams over its predecessor HTTP/1.1, this attack takes advantage of that very feature to inflict large-scale service disruptions. The provided demonstration and analysis illustrate how the attack works in practice and requires minimal bandwidth. Various mitigations have been implemented by webserver technologies and providers including rate limiting RST_STREAM frames from clients and enforcing stream concurrency limits more strictly, as well as IP-based blocking, to counteract abusive stream resets.

CVE-2020-10735: Python int() conversion vulnerability causing DoS

CVE-2020-10735 is a vulnerability found in the C implementation of python. According to CVE Mitre, this vulnerability was first disclosed on March 20th, 2020. The first issue opened in the github repo for CPython was on September 5th, 2022, and it was published to the National Vulnerability Database a couple of days later on September 9th. The bug was officially patched in Python versions x.x.14 on September 6. The flaw essentially was, in algorithms that ran in quadratic time complexity O(n^2) using non-binary bases (such as base 10), the function int() could take in a string integer with with 100,000 digits and finish parsing in 5ms, while for 1,000,000 digits it could take 50s. Integer strings with even larger numbers could significantly slow the system to be unresponsive, which can cause denial of service.

As of 2024, this vulnerability has mostly been mitigated with new patches of python 3.7, 3.8, and 3.12. The fix as disclosed in an issue released on September 14, 2022 has set a maximum string digit of 4300. There have been some discussions questioning why it was set to this, and the development team decided that value because it was high enough for common libraries to use while functioning correctly, while ensuring those with less powerful CPUs were still safe from DoS attacks. For needs that require a larger limit, the global environment setting can be altered. One would simply need to make a call to change the max string digits.

To demonstrate how this vulnerability can be exploited, we can do a simple example. Suppose we create a python script cve_test.py that has:

import time
start_time = time.time()
fac = 1000000
int("2" + "0" * fac)
end_time = time.time()

print(f" {fac} time: {end_time - start_time} seconds")

We will try to convert a large integer string of 2×10^100,000, and get the following error:

This is the expected response, as the current python version 3.12.0 has the fix for this CVE with the digit limit for string digits. In order to test this CVE, we will import the system library, and set the max string digits to 0, essentially making the python environment vulnerable to CVE 2020-10735 again.

import sys
import time
sys.set_int_max_str_digits(0)

The results are as follows:

As we can see in the results, the time it takes to complete the conversion increases significantly each time we add a digit, the time taken to process it increases at a much faster rate. This result highlights how attackers can cause a denial of service on a victim by submitting large numbers for conversions, which could overwhelm system resources. There haven’t been any significant real world examples of this exploit as many popular applications are built with input size limits, such as web servers; web servers often put a limit on the size of the request that can be sent, as well as a limit of how many requests can be sent. However, it is still important to patch this CVE or else attacker’s could potentially still exploit it. An example would be IBM’s BMC firmware. BMC firmware version OP910 utilizes python to help handle HTTPS requests, and although python is not used to process the request body, if someone with BMC administrator privilege uses python directly in the command line, the system can be vulnerable to CVE-2020-10735 if an attempt is made to process very large strings of numbers and subsequently cause a Denial of Service attack.

An intrusion detection system could detect someone attempting to exploit this vulnerability through monitoring of excessive CPU or memory resources and or scanning for any injections of large processing requests. Trace logs in our operating systems can also show high resource consumption of CPU and memory.

If we take a closer look into the loop that handles the converting a string, we can see why with larger inputs, more resources are being consumed. The loop will need to iterate over every character and process it which is expensive.

while (_PyLong_DigitValue[Py_CHARMASK(*scan)] < base || *scan == '_') {
    . . .
    ++scan;
}

Overall, CVE-2020-10375 is indeed a weak point in python that could be taken advantage of. Using a function to convert a string of digits to an integer is a seemingly simple task, and we can sometimes take for granted the ability to perform simple tasks without ensuring best security practices are in place. CVE-2020-10375 is a good example of why we need to take the time to write code that is secure; without a basic limiter on max string digits, our system is vulnerable to denial of service when attempting to use int() to process very large integer strings.

Conclusion

Denial of Service (DoS) vulnerabilities can have serious consequences even though they do not grant attackers control over a system. The DoS vulnerabilities work by exhausting the system resources in the target system, causing crashes or disruptions in their services. Disruptions in critical infrastructure such as healthcare systems, financial institutions, or essential infrastructure can result in economic losses and damage a company’s reputation. We can minimize these vulnerabilities by ensuring systems are regularly patched and monitored.

DoS attacks can be part of a larger attack strategy as well. They can initially serve as a distraction, or even as a way to test the defense of a system. Intrusion detection systems (IDS) have an important role in this case. They help identify and mitigate these threats and vulnerabilities, no matter how small they might be. By detecting early patterns, we can monitor and assess the risk associated with the disruption.

Each of the CVEs we studied offers a distinct method of exploiting system weaknesses. CVE-2022-3786 highlights how input validation failures in widely used libraries like OpenSSL can be weaponized, affecting multiple operating systems and distributions. On the other hand, CVE-2020-10735 demonstrates how an algorithmic vulnerability in Python’s int() function can lead to significant delays in processing large integers, opening systems to DoS attacks by exploiting weaknesses in computational inefficiencies. CVE-2023-44487 reveals how HTTP’s stream-multiplexing feature, while designed for efficiency, can be manipulated to mount large-scale DoS attacks with a small botnet.

Although each vulnerability differs in its technical details, they all share the commonality of resource exhaustion as the primary vector of attack. These DoS vulnerabilities reveal the importance of not only securing software applications but also ensuring that protocols and algorithms are resilient against misuse. Attackers increasingly target design features like input processing or network communication efficiency, making it crucial for organizations to maintain vigilance through the application of best security practices and mindful protection schemes. As pertaining to the CVEs covered here, proper bounds checking, computational limit enforcement, and heuristic-based protocol-level mitigations would achieve wide-ranging protection against the possible DoS attacks faced.

Our PoCs and analysis demonstrate that while DoS attacks do not allow direct control of the system, their ability to stop services makes them highly disruptive, especially in environments reliant on continuous availability. Organizations must prioritize preventative measures, such as timely patches and constant monitoring and detection to minimize the impact of these vulnerabilities.