Critical OpenSSL update: will we be covered if we update our underlying OS version of OpenSSL?

Elixir uses OpenSSL through Erlang. I don’t know the details of how that is handled very well.
I imagine we are exposed to this undisclosed issue.

Will we be covered if we update our underlying OS version of OpenSSL and rebuild Erlang or are we dependent on an Erlang/OTP update?
I’d imagine the Hex Docker images need an update for example.

I’d rather stay on top of it in case it is another Heartbleed.

4 Likes

AFAIK Erlang uses OpenSSL only for ptimitives and I highly doubt that this problem is related to crypto primitives. My bet is that it is related to TLS layer in which case it is not an issue for Erlang.

3 Likes

The vulnerability only affects OpenSSL Version 3.0.0 - 3.0.6 and most installations are still using the maintained OpenSSL 1.1 code train. Very few base OSs are running OpenSSL 3 by default such as Ubuntu 22 and RHEL 9.x. So any images based on those MAY need to be recreated, but that would depend on how the maintainer has the container built and if they are utilizing OpenSSL 3.

It looks like OTP just gained full production compatibility with OpenSSL 3 in the latest 25.1 release [release notes]. It requires a minimum of OpenSSL 0.9.8 and it looks like Brew is pinned to use OpenSSL 1.1.1.

Hope that helps.

4 Likes

For anyone who wants to check which version is installed on your server you can connect via SSH and run openssl version.

3 Likes

All helpful responses. I think we have some containers built on Ubuntu so will check those.

1 Like

https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html

Seems like non an issue for Erlang applications that use public_key application for cert validation and verification.

2 Likes