News

• Our tool (i.e., X.509DoSTool) is now available on GitHub.

• The X.509DoS Attack will be presented at USENIX Security '25.

Introduction

X.509DoS represents a class of denial-of-service (DoS) attacks that exploit vulnerabilities in the implementation of parsing or validation of X.509 certificates. Since these processes typically occur before signature verification, an attacker can craft malicious certificates without requiring access to the private key for re-signing. Therefore, any project that uses X.509-related APIs from cryptographic libraries with implementation vulnerabilities and attempts to handle certificates from untrusted external sources may be vulnerable to the X.509DoS attack. Given the widespread use of X.509 certificates in public key infrastructure (PKI), various scenarios could introduce the X.509DoS threat, including TLS handshakes, application signature verification, and more.

Paper

Bing Shi, Wenchao Li, Yuchen Wang, Xiaolong Bai, and Luyi Xing. X.509DoS: Exploiting and Detecting Denial-of-Service Vulnerabilities in Cryptographic Libraries using Crafted X.509 Certificates. In 34th USENIX Security Symposium (USENIX Security 25)

Demo Videos

• The demonstration video on using the X.509DoSTool (coming soon) 

• The demonstration video of the experiment on a test website that implements mutual TLS authentication using Botan 

• The demonstration video of the experiment on macOS based on S/MIME email

Q & A

Q. What is X.509DoS attack?

A. X.509DoS represents a class of DoS attacks that exploit vulnerabilities in the implementation of parsing or validation of X.509 certificates. By crafting malicious certificates, an attacker can send them to the party responsible for handling certificates in specific scenarios, thereby turning it into a victim of a DoS attack.

Q. What are some typical scenarios where X.509DoS attacks could be launched?

A. Some typical scenarios include:

• TLS handshake: In a mutual TLS handshake, both the server and the client have the opportunity to send certificates to each other. Once a client or server uses a vulnerable implementation to handle certificates, it could be susceptible to a DoS attack. In the context of HTTPS, this is typically manifested as the website running on the server being inaccessible or the client's browser being unable to function properly.

• App signature verification: In an operating system, the handling of certificates is typically managed by a specific process. If this process uses a vulnerable implementation and becomes unresponsive after processing certificates, it may cause other apps within the system to fail to launch, as they are unable to complete signature verification. 

• S/MIME mail: In an S/MIME communication, the recipient needs to retrieve the certificate sent by the sender in the email for identity verification and other operations. If the recipient uses a vulnerable implementation to process the certificate during this procedure, it could potentially impact the recipient's email client or even the entire operating system.

The second and third points mentioned above can also be combined to launch a remote DoS attack based on S/MIME emails. For further details, please refer to our attack example targeting Apple's macOS: Banana Mail.

Q. Are the vulnerabilities exploited in X.509DoS attacks directly related to X.509 certificates?

A. Not necessarily. In fact, the vulnerabilities exploited by X.509 DoS attacks primarily reside in three types of modules within the cryptographic libraries: the mathematical module, the ASN.1 module, and the X.509 module. The X.509 module provides implementations for operations such as certificate chain validation, and vulnerabilities within this module can be considered directly related to X.509 certificates. However, the first two modules primarily provide implementations for mathematical operations required by cryptographic algorithms and the encoding/decoding of ASN.1 objects. These implementations may not be directly related to X.509 certificates, but vulnerabilities within them can often be exploited by X.509 certificates.

Q. Does the crafted certificate need to be issued by a trusted CA?

A. No, the attack occurs during certificate parsing or validation, which happens before the certificate's signature is verified. This makes the attack independent of whether the certificate is signed by a trusted CA. As a result, the attacker does not need a certificate from a trusted CA; self-signed certificates are sufficient to launch this type of attack.

Q. Which types of DoS attacks does X.509DoS focus on?

A. X.509DoS primarily focuses on the following three specific types of DoS attacks:

• CPU Exhaustion: This impact typically arises from excessive looping, including both infinite loops (CWE-835)and pseudo-infinite loops (CWE-834)

• Memory Exhaustion: This impact typically arises from excessive memory allocation, including both large-scale one-time allocations (CWE-789) and continuous allocations resulting from loops (CWE-1325)

• Crash: Crashes can stem from various causes. Besides those caused by memory allocations, we primarily focus on crashes introduced by computation, which are more likely to be reproducible across different libraries. For example, crashes due to out-of-bounds array indexing (CWE-129) are generally more widespread than those caused by double free (CWE-415) in cryptographic contexts, as steps for index calculation in the former may be reused

Q. What vulnerabilities could potentially be exploited to launch X.509DoS attacks?

A. We discovered 18 new vulnerabilities during this process, the details of which are presented in Table 3 of our paper. Additionally, we have listed 12 previously known vulnerabilities in Table 4 of the paper. These vulnerabilities can be viewed as examples that could be potentially exploited to launch X.509DoS attacks.

Q. How to minimize the introduction of X.509DoS threats for cryptographic library developers?

A. Here are some strategies for reference:

• Secure Programming: Textbooks and standards are important reference for cryptographic library developers. However, these resources primarily serve educational or instructional purposes and may not fully address security concerns. Therefore, developers should place greater emphasis on secure programming practices, particularly by performing strict validation of user inputs. In addition, good programming habits can help reduce the occurrence of issues, such as introducing a counter in a complex while-loop to ensure it exits after a certain number of iterations, or checking whether the allocated memory size exceeds a threshold before allocating.

• Efficient Implementation: Many of the vulnerabilities exploited by X.509DoS attacks are caused by the excessive complexity of the implementation when handling large numbers or large amounts of data. Using efficient implementations can reduce the impact of such attacks under the same conditions, thereby increasing the attacker's cost (for example, increasing the size of numbers or the amount of data may lead to a larger certificate size, which could be indirectly limited in scenarios such as TLS).

• Eliminating redundant features: Some cryptographic libraries are not affected by X.509 DoS attacks, not because they have implemented specific mitigations, but because they lack support for certain features. Although this results in reduced functionality and should not be considered a primary defense strategy, it indirectly highlights that additional features can introduce additional risks. Developers should carefully evaluate the necessity of features based on the intended use of the library. For example, removing support for redundant features like custom elliptic curves can effectively reduce the likelihood of introducing X.509DoS threats.

Q. Are there other attack vectors that could lead to similar impacts as crafted X.509 certificates?

A. Yes, many vulnerable implementations are not necessarily limited to the processing of X.509 certificates. Other commonly used materials in PKI, such as public key files and certificate signing requests (CSRs), may also trigger these vulnerabilities. Additionally, ASN.1-related vulnerabilities may be triggered during certain protocol interactions.

Contact

• Bing Shi: roadicing@protonmail.com