Internally libssl in OpenSSL calls X509verifycert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSLconnect() or SSLdohandshake()) to not indicate success and a subsequent call to SSLgeterror() to return the value SSLERRORWANTRETRYVERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSLCTXsetcertverifycallback(). Since most applications do not do this the SSLERRORWANTRETRYVERIFY return value from SSLgeterror() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509verifycert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. Fixed in OpenSSL 3.0.1 (Affected 3.0.0).
{ "cpes": [ "cpe:2.3:a:nodejs:node.js:*:*:*:*:-:*:*:*" ], "severity": "High" }