Certificate verification vulnerability in Erlang/OTP 23.2
Posted 2021-01-15 12:06:59.472819
The ssl application version 10.2, part of Erlang/OTP 23.2 and 23.2.1, has a regression in the certificate verification logic. This could result in MitM attacks on clients, as well as unauthorized access to servers that rely on client certificates.
The vulnerability is tracked as CVE-2020-35733. A fix is available as part of ssl-10.2.1, in Erlang/OTP 23.2.2. I will post further details in a follow-up post once everyone has had a chance to upgrade.
The purpose of this post is to help you understand how the issue may affect you. The short version: if you are using an affected version of Erlang/OTP, on development machines, build servers and/or deployment targets, you should probably upgrade as soon as possible.
1. Is my application affected?
Certificate verification is primarily used by clients to detect attempts to intercept network traffic or impersonate servers. If your application includes any network clients that use TLS, it is almost certainly affected. Please refer to question 2 for details.
Some servers rely on client certificates to authenticate clients, and they too can be affected. Please refer to question 3 for more information.
2. Are the clients in my application affected?
If the application is running Erlang/OTP 23.2 and it connects to servers using TLS, the answer is almost certainly yes. Some clients do not enable certificate verification, but then such clients would have been susceptible to MitM attacks all along, regardless of Erlang/OTP version.
Some examples of affected clients include:
- HTTP clients, including the built-in
httpc, as well as 3rd party clients such as Hackney, HTTPoison, Tesla and Mint; the fact that many of these clients use a custom ‘verify_fun’ (e.g. ssl_verify_fun) does not change that
- SMTP (mail) clients
- MQTT and RabitMQ clients
- Redis clients
- API clients that build on any of the above, e.g. to access AWS, Google APIs, Stripe, Sentry, etc.
Clients that build on the SSH protocol, such as SFTP, are not affected.
3. Is my (web) server at risk?
TLS servers, such as web servers, generally do not perform certificate verification, unless explicitly configured to request a certificate from clients (“mutual TLS”). Therefore in practice most servers are not affected.
Servers that delegate the TLS termination to a reverse proxy (e.g. Nginx) or load balancer (e.g. HAProxy) are not affected, even if they do require client certificates.
However, if your server…
- Relies on client certificates (“mutual TLS”); and
- Uses Erlang/OTP’s built-in ssl application, rather than external TLS termination; and
- Is running Erlang/OTP 23.2 or 23.2.1
…then malicious users may be able to produce fake client certificates that will be accepted by the server. If that is the case, deploy the fix as soon as possible.
4. Is my development/build environment affected?
Possibly. Fetching packages from Hex should be safe, because the Hex client verifies the signature on downloaded packages. But API interactions with the Hex server could be intercepted, which would leak your API credentials. An attacker could then publish malicious modifications to your packages, leading to code execution vulnerabilities for the users of those packages. Do not publish Hex packages until after you have upgraded.
If you are using a tool such as
asdf, uninstall Erlang/OTP 23.2 and 23.2.1, and install 23.2.2 as soon as possible.
Off BEAM: Secure Coding for the BEAM
Posted 2020-05-04 07:26:41.557621
At CodeBEAM SF 2020 I presented the EEF’s Secure Coding and Deployment Hardening Guidelines. The talk was recorded and was recently published on YouTube, but unfortunately the first 10 minutes are missing.
Update: the full talk is now available, thanks to Code Sync and their video production crew! Here’s the new video; I left the old post with the ‘missing introduction’ below the fold for posterity…Continue reading...
Why Mix no longer installs from HTTP(S) URLs
Posted 2020-01-01 20:02:12.309037
As of Elixir 1.9.3 the use of HTTP or HTTPS URLs in various Mix commands is deprecated, and in 1.10 this functionality will be disabled altogether. This affects the
local.rebar Mix commands.
In this post I will explain why the use of URLs was a security risk, what are the alternatives, and why those alternatives (including Hex) are safe.
The issue here is that neither Erlang/OTP nor Elixir ships with a CA trust store, and picking up the CA trust store from the operating system is quite hard to do in a reliable, cross-platform way. Without a trust store it is not possible to verify the server’s certificate, which means there is no protection against man-in-the-middle (MitM) attacks. In case of plain HTTP URLs this must have been pretty obvious to users, but when using HTTPS people might be forgiven for thinking they’d be safe from such attacks.
The affected Mix tasks were used to fetch code for local execution or for inclusion into a software product that might be used in production. A MitM attack would allow the attacker to inject malicious code, stealing data or taking over the developer’s machine, build server or even production systems.Continue reading...
- Creating an SBoM for Mix projects (Posted 2019-10-24 19:44:48.169213)
- Learn you some `:ssl` for much security (Posted 2019-04-09 12:43:35.136065)
- Hex package registry vulnerability (Posted 2019-01-29 14:13:52.780049)
- OCSP stapling for Erlang/OTP (Posted 2018-07-11 18:42:50.698413)
- PSA: retiring TLS test domains (Posted 2018-07-11 07:30:04.473948)
- Dual cert RSA/ECDSA server with Erlang/OTP 21 (Posted 2018-07-03 18:55:58.000000)
- Erlang/OTP 21 (Posted 2018-06-23 08:36:19.000000)
- Erlang/OTP 20.3 (Posted 2018-03-14 19:00:53.000000)
- CipherSuites package updated (Posted 2018-03-12 20:16:18.000000)
- Practical security for Elixir/Phoenix (Posted 2018-01-05 08:35:18.000000)
- Security training at ElixirConf EU 2018 (Posted 2017-11-02 20:48:35.000000)
- Unauthorized Erlang? (Posted 2017-04-15 08:26:16.000000)
- Hostname verification with Erlang/OTP 19.3 (Posted 2017-03-17 06:35:40.000000)
- Plug vulnerabilities: impact assessment (Posted 2017-03-01 13:16:28.000000)
- Catching up (Posted 2017-02-27 09:28:27.000000)
- The great HTTPS client shoot-out (Posted 2016-11-05 08:03:50.000000)
- "aRSA+ECDH+AES:@STRENGTH" FTW (Posted 2016-07-05 17:30:20.000000)
- Thou shalt not trust thy neighbour's password (Posted 2016-06-24 19:20:05.000000)
- Who wants cookies? (Posted 2016-06-13 19:35:52.000000)
- Erlang/OTP 19.0 (Posted 2016-06-06 19:02:02.000000)
- ElixirConf.EU talk: video (Posted 2016-06-01 18:52:50.000000)