OpenSSL 1.1.1x for CVE-2023-5678

[jyturley]

Looking at the latest openresty containers on Docker Hub, it looks like openresty is using RESTY_OPENSSL_VERSION=1.1.1w.

I am wondering if there are any plans to update OpenSSL to the next version since there is a CVEs against it (Such as CVE-2023-5678).

Note: the alpine images that these containers are based off of have already addressed this issue, so I think this is just a matter of flippiing the version in the openresty application.

[neomantra]

Thanks for the heads-up on that... unfortunately this is a tricky situation as OpenSSL 1.1.1x does not seem to exist publicly. Click the 1.1.1x link on that CVE page and you will get a 404 page. They do not list it in their OpenSLL Downloads and there is no 1.1.1x release on GitHub.

This is because 1.1.1 is EOL and thus no longer supported; these security fixes can be received through specific support contracts with the OpenSSL maintainers. If it's not public, we can't package and distribute it.

See this upstream OpenResty issue regarding upgrading OpenSSL to the 3.0 series.

I'm going to leave the ticket open because operators should be aware of CVEs in their software.

[kernel-panic69]

CVE-2023-5678 (cve.org) link led me to CVE-2023-5678 (NIST), which led me to the following:
Make DH_check_pub_key() and DH_generate_key() safer yet (disconnected commit), Make DH_check_pub_key() and DH_generate_key() safer yet (patch for OpenSSL 3.0 branch), and Make DH_check_pub_key() and DH_generate_key() safer yet (patch for OpenSSL 3.1 branch)
This is one example of CVE patches and otherwise that can be back-ported to 1.1.1w.

[neomantra]

Thanks for these breadcrumbs! I would feel more comfortable if upstream OpenResty pulled this patch and then this project would apply it across all the flavors.

But we do patch OpenSSL in our built-from-source builds, so we could apply that patch. I'll consider doing this.