5 ms·

OpenSSL security advisory: Infinite loop reachable when parsing certificates

179 points by psanford 5y ago

beny23 5y ago
I wouldn't have thought this an issue if you're behind an AWS WAF or LB? (and assuming AWS is patched already)
- acdha 5y ago
  For an intermediary like a WAF, load-balancer, or CDN to help it needs to do all of the certificate processing and keep your backend app from seeing the certificate at all. If you are terminating HTTPS at the edge and using HTTP internally that's very likely but if you're using an NLB instead of an ALB, it's not. Similarly, you'd also want to see if there's any application-level path where a certificate would be included in an uploaded file but that's far less common.
- jamespwilliams 5y ago
  I think nearly everything at AWS uses s2n and not OpenSSL these days
  - justinsaccount 5y ago
    Has s2n been fips certified? I thought some things (govcloud?) were still using openssl due to fips requirements.
    - znep 5y ago
      I'm not sure what they are using right now, but they currently have the "AWS-LC Cryptographic Module" listed as being in process for validation which may be sufficient for s2n. I know there are other AWS features/services that are lined up behind that validation for FIPS support.
- jcims 5y ago
  Depends if s2n is vulnerable to the same bug. Of course AWS doesn't protect you against application bugs so if your application has an SSRF vulnerability (presumably otherwise unexploitable) an attacker might be able to DoS you. They don't mention S/MIME or things like signed binaries or SAML assertions but those seem plausibly vulnerable as well.
- nazlorenzo 5y ago
  This vulnerability affects parsing maliciously crafted certificates, so it will mostly affect clients. If your app is fetching data from a 3rd party and validating its certificate, it may be vulnerable, regardless of how you are fronting requests to your site.
  - lmilcin 5y ago
    > This vulnerability affects parsing maliciously crafted certificates, so it will mostly affect clients. Actually, it is the opposite. You seem to be unaware of the fact that servers do receive certificates from the clients which are then parsed. Which is already mentioned in the advisory document: "Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates <---- here - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters"
    - alexw91 5y ago
      That's not how the TLS handshake works. The TLS server must be configured to request a certificate from the client in order for the client to know that it needs to send a client certificate to the server, and that server-side configuration is disabled for ~99%+ of endpoints. TLS server implementations should be aborting the TLS connection for violating the TLS Handshake state machine if a client attempts to send a client certificate when it wasn't requested. So while this bug affects both clients and servers, 100% of clients are parsing the server's TLS cert during the TLS handshake, but less than ~1% of servers are parsing a client's certificate during a handshake.
      - lmilcin 5y ago
        There is very little reason to DOS a client and a lot of reasons to attack servers. There is a huge number of public facing services that implement mutual auth and all those are potentially vulnerable to DOS. While clients can just decide to not connect to a web service that causes their browser to malfunction (and why have you connected there in the first place?), services are usually not at liberty to ignore a client at this stage. So yes, those servers that do request client certificate are targets and my point still stands that servers are much more affected than the clients. What would be an affected client? You keep connecting to this infected website that causes your browser to die? Somebody embedded some tracking on their page that now points to an infected website? Everybody will just move on and it is hard to say you are very much affected by this problem. Whereas if you are a service and you are affected you absolutely need to implement a fix.
olliej 5y ago
So it’s a timing attack? :D :D :D
unixbane 5y ago
how is it even possible to have the question of whether there can be an infinite loop during establishing a data channel? just make the user provide the public key and do a handshake [1]. X.509 is literally a non-practical academic idea like CSS. software is bad because everyone accepts bad ideas. 1. yes, having things done the right way where they need to be done makes sense. think of the user after. for instance, you could just make his stupid cloud device aggregate all the keys he needs automatically
- moltke 5y ago
  >provide the public key Which format? What algorithim? How do you prevent it from being sent to the wrong domain and enabling MITM phishing? X.509 has a lot of issues but they've thought through a number of things. Whatever you replace it with would have similar problems. Even if you "just sent a key" it would have to be parsed in some way (Say it's RSA, you'd still have to pull the module and exponent out before you could do anything with it, if the channel is text you'd probably do some base64 decoding etc.)
  - unixbane 5y ago
    Standards are good. > How do you prevent it from being sent to the wrong domain and enabling MITM phishing? TOFU. Petnames. > it would have to be parsed in some way Encoding a key is trivial, even with an ad-hoc serialization format. Nothing near what X.509 does.
- Nursie 5y ago
  > X.509 is literally a non-practical academic idea Non-practical but https has been running on it for decades now? Yeah there are issues with it and as someone that's worked with it a lot at the profile design and issuing level, I think it's high time we came up with a replacement and ditched ASN.1 entirely. But ... It's hard to see it as a non-practical, academic idea when it's out there, deeply embedded in the internet, everywhere. > just make the user provide the public key Doesn't solve the problems X.509 addresses. There's a lot more going on than a method to exchange keys.
0xdeadb00f 5y ago
Dare I ask if LibreSSL is affected?
- rurban 5y ago
  yes, fixed here: https://cvsweb.openbsd.org/src/lib/libcrypto/bn/bn_sqrt.c?rev=1.10&content-type=text/x-cvsweb-markup https://cvsweb.openbsd.org/src/lib/libcrypto/bn/bn_sqrt.c?re... they removed a lot of cruft, but this is needed
vinkabuki 5y ago
Is BoringSSL affected?
- DannyBee 5y ago
  Not to the same degree. See: https://github.com/google/boringssl/commit/c7a3c46574e7fc32357b2cc68f961c56c72b0ca4 https://github.com/google/boringssl/commit/c7a3c46574e7fc323... In particular: " In OpenSSL, this loop resulted in a DoS vulnerability, CVE-2022-0778. BoringSSL is mostly unaffected by this. In particular, this case is not reachable in BoringSSL from certificate and other ASN.1 elliptic curve parsing code. Any impact in BoringSSL is limited to: - Callers of EC_GROUP_new_curve_GFp that take untrusted curve parameters - Callers of BN_mod_sqrt that take untrusted moduli"

179 points by psanford 5y ago

beny23 5y ago

I wouldn't have thought this an issue if you're behind an AWS WAF or LB? (and assuming AWS is patched already)

acdha 5y ago
For an intermediary like a WAF, load-balancer, or CDN to help it needs to do all of the certificate processing and keep your backend app from seeing the certificate at all. If you are terminating HTTPS at the edge and using HTTP internally that's very likely but if you're using an NLB instead of an ALB, it's not. Similarly, you'd also want to see if there's any application-level path where a certificate would be included in an uploaded file but that's far less common.
jamespwilliams 5y ago
I think nearly everything at AWS uses s2n and not OpenSSL these days
- justinsaccount 5y ago
  Has s2n been fips certified? I thought some things (govcloud?) were still using openssl due to fips requirements.
  - znep 5y ago
    I'm not sure what they are using right now, but they currently have the "AWS-LC Cryptographic Module" listed as being in process for validation which may be sufficient for s2n. I know there are other AWS features/services that are lined up behind that validation for FIPS support.
jcims 5y ago
Depends if s2n is vulnerable to the same bug. Of course AWS doesn't protect you against application bugs so if your application has an SSRF vulnerability (presumably otherwise unexploitable) an attacker might be able to DoS you. They don't mention S/MIME or things like signed binaries or SAML assertions but those seem plausibly vulnerable as well.
nazlorenzo 5y ago
This vulnerability affects parsing maliciously crafted certificates, so it will mostly affect clients. If your app is fetching data from a 3rd party and validating its certificate, it may be vulnerable, regardless of how you are fronting requests to your site.
- lmilcin 5y ago
  > This vulnerability affects parsing maliciously crafted certificates, so it will mostly affect clients. Actually, it is the opposite. You seem to be unaware of the fact that servers do receive certificates from the clients which are then parsed. Which is already mentioned in the advisory document: "Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates <---- here - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters"
  - alexw91 5y ago
    That's not how the TLS handshake works. The TLS server must be configured to request a certificate from the client in order for the client to know that it needs to send a client certificate to the server, and that server-side configuration is disabled for ~99%+ of endpoints. TLS server implementations should be aborting the TLS connection for violating the TLS Handshake state machine if a client attempts to send a client certificate when it wasn't requested. So while this bug affects both clients and servers, 100% of clients are parsing the server's TLS cert during the TLS handshake, but less than ~1% of servers are parsing a client's certificate during a handshake.
    - lmilcin 5y ago
      There is very little reason to DOS a client and a lot of reasons to attack servers. There is a huge number of public facing services that implement mutual auth and all those are potentially vulnerable to DOS. While clients can just decide to not connect to a web service that causes their browser to malfunction (and why have you connected there in the first place?), services are usually not at liberty to ignore a client at this stage. So yes, those servers that do request client certificate are targets and my point still stands that servers are much more affected than the clients. What would be an affected client? You keep connecting to this infected website that causes your browser to die? Somebody embedded some tracking on their page that now points to an infected website? Everybody will just move on and it is hard to say you are very much affected by this problem. Whereas if you are a service and you are affected you absolutely need to implement a fix.

olliej 5y ago

So it’s a timing attack? :D :D :D

unixbane 5y ago

how is it even possible to have the question of whether there can be an infinite loop during establishing a data channel? just make the user provide the public key and do a handshake [1]. X.509 is literally a non-practical academic idea like CSS. software is bad because everyone accepts bad ideas. 1. yes, having things done the right way where they need to be done makes sense. think of the user after. for instance, you could just make his stupid cloud device aggregate all the keys he needs automatically

moltke 5y ago
>provide the public key Which format? What algorithim? How do you prevent it from being sent to the wrong domain and enabling MITM phishing? X.509 has a lot of issues but they've thought through a number of things. Whatever you replace it with would have similar problems. Even if you "just sent a key" it would have to be parsed in some way (Say it's RSA, you'd still have to pull the module and exponent out before you could do anything with it, if the channel is text you'd probably do some base64 decoding etc.)
- unixbane 5y ago
  Standards are good. > How do you prevent it from being sent to the wrong domain and enabling MITM phishing? TOFU. Petnames. > it would have to be parsed in some way Encoding a key is trivial, even with an ad-hoc serialization format. Nothing near what X.509 does.
Nursie 5y ago
> X.509 is literally a non-practical academic idea Non-practical but https has been running on it for decades now? Yeah there are issues with it and as someone that's worked with it a lot at the profile design and issuing level, I think it's high time we came up with a replacement and ditched ASN.1 entirely. But ... It's hard to see it as a non-practical, academic idea when it's out there, deeply embedded in the internet, everywhere. > just make the user provide the public key Doesn't solve the problems X.509 addresses. There's a lot more going on than a method to exchange keys.

0xdeadb00f 5y ago

Dare I ask if LibreSSL is affected?

rurban 5y ago
yes, fixed here: https://cvsweb.openbsd.org/src/lib/libcrypto/bn/bn_sqrt.c?rev=1.10&content-type=text/x-cvsweb-markup https://cvsweb.openbsd.org/src/lib/libcrypto/bn/bn_sqrt.c?re... they removed a lot of cruft, but this is needed

vinkabuki 5y ago

Is BoringSSL affected?

DannyBee 5y ago
Not to the same degree. See: https://github.com/google/boringssl/commit/c7a3c46574e7fc32357b2cc68f961c56c72b0ca4 https://github.com/google/boringssl/commit/c7a3c46574e7fc323... In particular: " In OpenSSL, this loop resulted in a DoS vulnerability, CVE-2022-0778. BoringSSL is mostly unaffected by this. In particular, this case is not reachable in BoringSSL from certificate and other ASN.1 elliptic curve parsing code. Any impact in BoringSSL is limited to: - Callers of EC_GROUP_new_curve_GFp that take untrusted curve parameters - Callers of BN_mod_sqrt that take untrusted moduli"