Executive Summary

This vulnerability exists in the Erlang/OTP ssl module, specifically in the inet_tls_dist module responsible for distribution-over-TLS. The function inet_tls_dist:check_ip/1 is intended to enforce a LAN allowlist by verifying the peer's IP address. However, it incorrectly uses the function inet:sockname/1, which returns the local socket address, instead of inet:peername/1, which returns the actual peer IP address.

Because of this mistake, the local IP and the supposed peer IP always appear the same, causing the subnet mask comparison to always succeed. This flaw allows any holder of a CA-signed TLS certificate to bypass the LAN restriction and gain full Erlang distribution access to the node, including executing remote procedure calls and loading code remotely.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have serious security impacts because it allows unauthorized users to bypass LAN-based access restrictions on Erlang nodes using TLS distribution.

• An attacker with a valid CA-signed TLS certificate can gain full Erlang distribution access to the node.
• The attacker can perform remote procedure calls (rpc:call/4) on the node.
• The attacker can load arbitrary code remotely (code:load_binary/3), potentially leading to full compromise.

Overall, this compromises confidentiality, integrity, and availability of the affected Erlang nodes.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves verifying if your Erlang/OTP environment is using the vulnerable versions of the ssl module and if distribution-over-TLS is configured with the LAN allowlist feature enabled.

Specifically, check if the inet_tls_dist:check_ip/1 function is in use and whether it incorrectly uses inet:sockname/1 instead of inet:peername/1 to obtain the peer IP address.

You can inspect the Erlang/OTP version and ssl module version to see if they fall within the affected ranges: OTP versions from 26.0 before 29.0.2, 28.5.0.2, and 27.3.4.13; ssl versions 11.0 before 11.7.2, 11.6.0.2, and 11.2.12.9.

To detect if the vulnerability is exploitable on your system, verify if TLS distribution is configured with the check_ip flag enabled and if the cluster uses a shared CA for TLS certificates.

While no explicit commands are provided in the resources, you can use Erlang shell commands to check versions and configuration, for example:

• Check Erlang/OTP version: `erlang:system_info(otp_release).`
• Check SSL application version: `application:which_applications().` and look for ssl version.
• Inspect distribution configuration for TLS and check_ip flag in your node's configuration files or runtime parameters.
• Review the source code or loaded modules to confirm if inet_tls_dist:check_ip/1 uses inet:sockname/1 instead of inet:peername/1.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation involves applying the patch that fixes the incorrect use of inet:sockname/1 by replacing it with inet:peername/1 in the inet_tls_dist:check_ip/1 function.

If patching is not immediately possible, a recommended workaround is to implement a custom SSL verify_fun option that correctly checks the peer IP address using inet:peername/1 on the socket.

Additionally, ensure that TLS distribution is configured securely, and consider disabling the check_ip flag until the fix is applied.

Upgrading Erlang/OTP and ssl to fixed versions 29.0.2, 28.5.0.2, or 27.3.4.13 (or later) is advised to fully remediate the vulnerability.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows an attacker holding a valid CA-signed TLS certificate to bypass LAN allowlist restrictions and gain full Erlang distribution access to the node, including executing remote procedure calls and loading code. Such unauthorized access can lead to breaches of confidentiality, integrity, and availability of data and systems.

Because of these impacts, organizations using affected Erlang/OTP versions may face challenges in maintaining compliance with standards and regulations like GDPR and HIPAA, which require strict access controls and protection of sensitive data. Unauthorized access enabled by this vulnerability could result in data exposure or manipulation, potentially violating these regulatory requirements.

Mitigations such as applying patches or implementing custom verification functions are necessary to restore proper access controls and help maintain compliance.

Useful 0 Not Useful 0