Some recently exposed vulnerabilities in cryptographic software highlight an old problem. Software often fails when in “exotic and rarely used configurations.” The recently-published CVE-2022-0778 vulnerability, and the related CVE-2020-0601 vulnerability, both involve software that implements Elliptic Curve Cryptography (ECC) in digital certificates. One of the most common uses of digital certificates is in TLS, which is what HTTPS is built upon, the protocol that secures access to websites. For CVE-2022-0778, the specific problem is that the code for handling Explicit ECC Curves will dive into an infinite loop if presented with malformed data, allowing attackers to launch a denial-of-service attack against some Internet-facing web servers.
Zero Trust CDR as a Service
For these two vulnerabilities, the exotic configuration at the heart of the problem is the use of Explicit ECC Curves in digital certificates, and the arbitrary trust that software typically places in them. Under normal circumstances, a digital certificate using ECC will reference the ECC Curve it is using with a “Named Curve,” which is meant to be a widely recognized standard name for the curve. Sometimes this isn’t possible, for example if consumers of the certificate might not recognize the standard name. In such cases, an “Explicit Curve” can be used instead of a “Named Curve,” where full details of the ECC Curve used are embedded in the certificate. From a security point of view, for software to automatically trust these Explicit ECC Curves is a bad idea, because trust in EC cryptography is based on trust in the ECC Curve used.
In a more idealized world, software that supports ECC in certificates would mandate the use of configurations that are known to be safe, and perform checks against Explicit Curves, blocking those that aren’t recognized. Software could, as an option, allow administrators to specify allow-lists of Explicit Curves (as well as Named Curves). The reality however is that software tends to follow “compatibility before security”, the lack of consensus over which ECC Curves can be trusted further compounding the problems of this philosophy.
To take a deeper dive into CVE-2022-0778, the vulnerability is in the implementation of an algorithm known as the Tonelli–Shanks algorithm. The Tonelli–Shanks algorithm is used to compute modulo square roots. A modulo square root operation is just like the traditional square root operation, except it takes two parameters instead of one — the integer to root, and additionally a modulus integer, which must always be a prime number. In vulnerable implementations of Tonelli–Shanks, when presented with certain non-prime (and therefore illegal) integers as the “modulus” parameter, and a relevant value to root, the implementation loops indefinitely. The “modulus” parameter that gets passed to the modulo square root operation comes from one of the attributes of the ECC Curve in use, specifically its Finite Field Modulus, or Finite Field Size. For well-designed ECC Curves the Tonelli–Shanks algorithm is not needed; more efficient modulo square root algorithms are available, and can be used given that the curve’s Finite Field Modulus meets certain conditions. However, for curves that don’t meet such conditions, software may fall back to Tonelli–Shanks, and this includes OpenSSL.
Modulo square root operations in EC cryptography typically only occur when decompressing curve points, and this is where a second unusual configuration comes into play — Compressed ECC Points. In the ECC of today, ECC Points are usually Uncompressed. Uncompressed ECC Points do not require decompression before use, do not require a modulo square root to be calculated. However, to say that Compressed ECC Points are bad because of this vulnerability would be misleading; Compressed ECC Points are less open to attack than their Uncompressed counterparts. Indeed, their use in cutting-edge EC cryptography, not yet widely available, is mandated for this reason.
Putting these details together, an attack therefore requires two ingredients —an Explicit Curve, and a Compressed ECC Point. In an attack, the attacker includes a Compressed ECC Point somewhere in the certificate, and supplies an Explicit Curve with a relevant non-prime Finite Field Modulus integer, which will get passed to the vulnerable Tonelli–Shanks implementation, causing it to loop indefinitely and thus result in denial-of-service.
The immediate problem with CVE-2022-0778 is with OpenSSL and this has been patched. The Golang ecosystem does not use OpenSSL, as it has its own TLS implementation. Golang’s TLS implementation does not suffer from this vulnerability today, but this is because it neither supports Explicit Curves nor Compressed ECC Points. Some might consider this a lack of compatibility with the standards, but others will be pleased that these unusual and potentially dangerous features are omitted. Being a relatively recent TLS implementation, Golang has the advantage of looking at the status-quo with a fresh perspective, discarding some of the details in standards that didn’t evolve to be widely used. However, Golang’s TLS implementation also has its weaknesses, most notably lack of revocation checking, its difficulty of use in private enterprise PKIs, and its relative youth compared to the battle-hardened giants of OpenSSL and Microsoft’s SChannel.
So how can a public-facing web service protect itself against such problems in the future? While this recent case is about denial-of-service, future vulnerabilities could lead to failure of authentication / secrecy or even remote code execution. Indeed, we have already seen a trusted code execution vulnerability in the related CVE-2020-0601, which also exploited Explicit Curves.
The number one defense is to configure the outer skin of the web service, so it only works with normal mechanisms, using standard profiles for the cryptography (including allow-lists of accepted ECC Curves), standard protocol features and standard data formats. This reduces the attack surface and benefits from the testing done by every other web service using the software.
Beyond that, the front edge of the web service needs to be separated from the back-end business logic. This naturally occurs when using a cloud native approach, and here there’s the added advantage that the forward-facing infrastructure is managed by the cloud provider. By decoupling the forward and rear zones, any damage is contained at the front, leaving the back-end systems untouched. With denial-of-service this still means business cannot be conducted with external parties, but at least the main corporate networks remain usable while the problem is fixed.
Forcepoint’s cloud APIs allow this to be taken one step further. The data crossing the interface between the zones is passed to the Zero Trust CDR process. This builds new data, using normal safe data constructs to ensure no malware is present, for delivery while discarding the original data, which might contain undetectable malware. As a result, the application never gets unusual or surprising data.
Resource : Dangerous Explicit Curves | Forcepoint
Software Asset Management CyberSecurity Consultants in the Middle East (gcst.ae)