Skip to main content

Denial of Service via… SSL Certificates? CVE-2022-0778


MicoolPaul
Forum|alt.badge.img+23

Did you have this on your Infosec bingo card? Maliciously crafted SSL certificates are able to consume 100% CPU resources and thereby, create a DoS scenario! And the best part? Servers can DoS clients, the same as clients can DoS servers!

 

What is CVE-2022-0778?

CVE-2022-0778 is a vulnerability within the BN_mod_sqrt() function implemented within the OpenSSL toolkit. This function is used when working with elliptic curves in compressed formats, it is possible to, with certain variables, provide non-prime numbers that trigger an inescapable “while loop” scenario. In this scenario, endless CPU resources are consumed, attempting to solve an equation that will never reach the exit criteria required to break the loop.

As the OpenSSL toolkit is one of the most widely used implementations of SSL available, this has a wide radius of impact, so be sure to reach out to your vendors to check if they utilise OpenSSL and which versions include mitigations where applicable. This advice is especially important for any devices accessible via public or untrusted networks such as internet accessible services.

 

Which OpenSSL versions are impacted?

OpenSSL 1.0.2, 1.1.1 and 3.0.0/3.0.1 branches are affected.

The fixes are now available for these branches, with versions 1.0.2zd, 1.1.1n and 3.0.2 respectively. The fix mitigates this endless loop vulnerability I discussed earlier, by migrating to a for loop that can catch the relevant conditions, creating an escapable loop.

 

Does this need to be a valid certificate?

No, and this is probably the most dangerous part! A certificate has to be parsed before it can be validated, and this particular vulnerability is triggered during the parsing process.

 

More Information:

As always, NIST have a great overview of the vulnerability, and which vendors have notified NIST of their own documentation detailing impact/mitigation. NIST documentation available here.

Additionally, I’d like to highlight Sophos’ analysis of this vulnerability, the level of detail provided is phenomenal and includes proof of concept links for your own investigations if interested. It’s quite technical at parts, but well worth the read if that’s your area of interest, read it here.

10 comments

JMeixner
Forum|alt.badge.img+17
  • On the path to Greatness
  • 2650 comments
  • June 2, 2022

😵 Oh no….. this is very easy to exploit then. Super….

Thank you for sharing.


Rick Vanover
Forum|alt.badge.img+10

That’s interesting - what do we do to fix?


MicoolPaul
Forum|alt.badge.img+23
  • Author
  • 2361 comments
  • June 2, 2022
Rick Vanover wrote:

That’s interesting - what do we do to fix?

All we can do is make sure our OpenSSL implementations are up to date to include the fix. I haven’t had a chance to post in R&D yet Rick but I believe Veeam Backup for public clouds are all using OpenSSL and I recall a mention of it used in VBR, are the teams aware of this?


Rick Vanover
Forum|alt.badge.img+10
MicoolPaul wrote:
Rick Vanover wrote:

That’s interesting - what do we do to fix?

All we can do is make sure our OpenSSL implementations are up to date to include the fix. I haven’t had a chance to post in R&D yet Rick but I believe Veeam Backup for public clouds are all using OpenSSL and I recall a mention of it used in VBR, are the teams aware of this?

I will share with them!


Rick Vanover
Forum|alt.badge.img+10

Good news - the Updater function built-in to the Veeam backup for the cloud appliance will address this!
 

 


MicoolPaul
Forum|alt.badge.img+23
  • Author
  • 2361 comments
  • June 2, 2022

Great news Rick, figured it’d be an installed package managed by updater instead of a custom static dependency, as for VBR, sounds like from this R&D post, only Linux repos would be impacted, it does mention statically linked so whether that’s a fixed dependency? https://forums.veeam.com/post411249.html?hilit=OpenSSL#p411249


MicoolPaul
Forum|alt.badge.img+23
  • Author
  • 2361 comments
  • June 2, 2022

Just as a footnote on this subject to anyone reading and worrying, the potentially public facing Veeam Backup for public cloud offerings are the high risks here, an internal repo being DoS’d, isn’t going to achieve much in a malicious actor’s agenda, and it being an internal repo dramatically reduces risk. Just asking Rick for completeness 🙂


Chris.Childerhose
Forum|alt.badge.img+21

Wow that is quite the issue for sure.  Going to pass this along to security team to assess.


MicoolPaul
Forum|alt.badge.img+23
  • Author
  • 2361 comments
  • June 2, 2022

Definitely worth it @Chris.Childerhose, the NIST article I linked has vendors such as NetApp & SonicWALL sharing their security advisories with NIST, this list isn’t every vendor either of course! These shared libraries & frameworks are always brilliant until a vulnerability introduced, accidentally or maliciously, suddenly impacts 50% of the web! 😆


Chris.Childerhose
Forum|alt.badge.img+21
MicoolPaul wrote:

Definitely worth it @Chris.Childerhose, the NIST article I linked has vendors such as NetApp & SonicWALL sharing their security advisories with NIST, this list isn’t every vendor either of course! These shared libraries & frameworks are always brilliant until a vulnerability introduced, accidentally or maliciously, suddenly impacts 50% of the web! 😆

Absolutely agree with that. 😁


Comment