DHEater vulnerability

[BareqAZ]

The DHEater vulnerability is a serious vulnerability that can lead to a denial of service attack, it has been given the identifier CVE-2002-20001 and a base score of 7.5. a single client can easily disturb the service and possibly cause the other clients to timeout.
This specifically affects the Diffie-Hellman algorithms and as far as I know, there isn't really a way to patch this apart from disabling the Diffie-Hellman altogether.
https://github.com/c0r0n3r/dheater
https://nvd.nist.gov/vuln/detail/CVE-2002-20001
elliptic-curve Diffie-Hellman shouldn't be affected.

There is also CVE-2022-40735 which can also target Diffie-Hellman and can lead to a denial of service attack.
https://nvd.nist.gov/vuln/detail/CVE-2022-40735

Should we stop recommending Diffie-Hellman?

[jtesta]

@BareqAZ : thanks for bringing this to my attention!

I did some testing, and it seems that this denial-of-service requires unlimited new connections to the server (at least against OpenSSH). Once rate limiting is imposed, the server's CPU consumption decreases from 99% to under 1%. I used the following iptables commands to limit 10 new connections per 10 seconds (note that you'd also need to add these rules with ip6tables so that IPv6 connections are also limited):

iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j DROP

So I think declaring all DHE key exchanges as failures would be excessive. Admins can easily add rate-limiting to stop the DoS (which also adds the benefit of significantly reducing brute-force credential guessing). I think I should update the hardening guides to include the rate-limiting commands above, but also point out that another option is to disable DHE algorithms entirely and just use x25519 and sntrup761x25519. Admins can choose which solution they'd prefer.

As far as the ssh-audit tool goes, I should research whether or not DHEater testing can be implemented (the deciding factor would be if any large-number math is required, since ssh-audit would then need to add a library dependency, which we've been trying to avoid). If so, then I'm thinking the following strategy can be added:

1. Perform DHEater testing with, say, 64 threads at the very end of ssh-audit's execution (to prevent rate limiting from interfering with its other testing).
2. It wouldn't be easy for a client to deduce that the server's CPU is at 100%, but if the test is run for 5.0 seconds and we notice that, say, over 500 DHE handshakes were successful, we can flag this issue in the UI as a warning (or maybe failure?).
3. A specific DHEater testing mode can be implemented so admins can run it against their servers continuously while directly observing the CPU consumption.
4. There should be an option to disable DHEater testing for general scans. By default, it should be enabled, however.

Unfortunately, the above strategy is not compatible with the PR you submitted. I do very much appreciate the initiative you've shown, as well as the work you put in! Moving forward, I'd suggest that you talk with project maintainers first before writing significant patches. I've had to learn this lesson the hard way, too, in the past; its disappointing to put a lot of work into something just for it to be ignored or rejected. Just thought I'd give you some constructive feedback!

Thanks again for reporting this issue!

[BareqAZ]

@jtesta Great investigation!

I wasn't aware that it was possible to alleviate this issue with rate limiting, I tested your method on a couple of different SSH servers and it works, I should've probably researched and tested this a bit more beforehand.
Regardless based on this information I agree with your approach we should have a solid and consistent way of testing whether a target server is vulnerable before declaring a failure/warning.

[c0r0n3r]

Dear @BareqAZ and @jtesta,

Let me add some information to your conversation about CVE-2002-20001 and CVE-2022-40735, as the author of these CVEs.

I completely agree that the comprehensive check of weather a server is vulnerable to the D(HE)at attack (D(HE)ater is the name of the PoC implementation) is a difficult task. I also agree that rate limiting can be effective against this and other types of DoS attacks, making it indispensable.

However, the effectiveness of the D(HE)at attack (CVE-2002-20001) higly depends on the Diffie-Hellman (DH) implementation of the underlaying cryptographic library beyond the server configuration. In the SSH protocol an attacker can enforce two modular exponentiations (the resource demanding part of the DH key exchange, by sending KEX init and DH KEX/GEX init messages to the server. It means that 100% utilization on a single CPU core can be achived by sending half as many messages as many modular exponentiations the CPU core can calculate (not considering other task should be done during the handshake).

One can get concrete numbers by running the following command:

openssl speed ffdh

The output of that command contains how many DH operations a single CPU core is able to perform using different public key sizes. It can be a few thousands in the case of a 2048-bit keys, but it also can be a few hundreds using a 8192-bit keys. This amount dramatically decreases if the implementation is vulnerable to "long exponent" issue (CVE-2022-40735), as OpenSSL was up to version 3.0.6. The DH key generation speed can be 10 ops/sec or lower in a low-end CPU, using 8192-bit key size. Fortunately, even if OpenSSH uses an OpenSSL version vulnerable to CVE-2022-40735, it does not become affected as it sets DH exponent sizes.

Considering the significant differences in the effectivenes of the D(HE)at attack, I decided to report the larger key sizes as a threat in CryptoLyzer (cryptographic settings analyzer for TLS/SSH/DNSSEC/....). 3072-bit key size provide 128-bit security (NIST SP 800-57 Part 1 Rev. 5 Table 2) which considered secure and it's performance is fair enough compared to the slower elliptic-curves. To achieve 192 bits of security, one has to use 8192-bit key size, which slow enough to carry risk of a DoS attack (without rate limiting). Using DH key exchange you cannot achieve 256-bit security in practice as it would require 15360-bit key size. In addition it would be slow most of the popular cryptographic libraries do not support that large keys.

[jtesta]

Just now, I checked into master a rather extensive implementation of the DHEat vulnerability. This will be included in v3.2.0, whose release is imminent.

I've also conducted an in-depth research project analyzing the effects this DoS has against cloud-based VMs. This, too, will be released very, very soon. I'll drop the link here when its been published.

Thanks @BareqAZ for bringing this issue to my attention, and thanks @c0r0n3r for the additional info!

[c0r0n3r]

@jtesta, meanwhile we have published a full technical paper on IEEE Access with the title D(HE)at: A Practical Denial-of-Service Attack on the Finite Field Diffie–Hellman Key Exchange and a project page on GitLab about the attack.

[jtesta]

I've published the article I mentioned a few days ago: An Analysis of the DHEat DoS Against SSH in Cloud Environments