Erlang & Application Security

“Application Security of Erlang Concurrent System” (2008) is the title of a paper written by Kenji Rikitake and Koji Nakao (the first author is associated with the Network Security Incident Response Group, Japan). This was the first paper I found with an explicit and committed focus on Security requirements and principles.

Mr Rikitake is also known for his work on encryption solutions for Erlang – see for example the following presentation : ). Now, while encryption is certainly a fundamental aspect of information Security, it does not exhaust by far its meaning. For this reason is that the paper I comment here is (as indicated above) is the “first” I found with an explicit focus on Security.

Rikitake and Nakao motivate their work saying that “The reinforcement of security capability of Erlang is essential to defend the software from wide-area Internet attacks,” in a sense that confirms the overall sense that Erlang does have excessively “light” resources for Security. After a summary of Erlang functionality (sections 1 and 2 of the paper), the authors address in part 3 (Hardening the Erlang systems). They write: “From security point of view, distributed Erlang systems have fundamental weaknesses, and require hardening the message passing facility against possible attacks.”

Some sections of the paper –which can be found here: – are worth reproducing in some extension for people interested in Erlang Security, at this section constitutes almost a *catalogue* of the  Security problems a developer or software architect will find when implementing Erlang systems (see pages 4 and 5 of the commented text):

“The node authentication to decide whether two nodes are allowed to connect to each other is performed by sharing the same passphrase string called cookie. Each Erlang node has a set of the cookie strings for each connecting neighbor node, and uses the strings to perform a challenge-response authentication when connected two nodes start to establish a link as a pair of distributed nodes. The contents of the data links between the Erlang nodes, however, are not encrypted at all using the default inet_tcp_dist
driver module, while Erlang allows to choose an alternative driver.

“Erlang/OTP provides slave module as a part of the standard libraries. One of the functions slave:startcan use the Secure Shell (SSH) as a method of authentication, by invoking a remote Erlang shell through SSH. This function, however, does not encrypt the data links at all. The node mapping is still through epmd and the Erlang nodes still directly connects each other over TCP
without encryption on the transport layer.

“Links between epmd processes are vulnerable is well known, so denial-of-service (DoS) attacks are possible. The TCP/IP sockets are bound to INADDR_ANY and cannot be configured to be bound to a specific interface/address. The epmd links are not encrypted at all, so the port should be isolated by a firewall, or be enclosed in a virtual private network (VPN), to prevent attacks. Links between Erlang nodes are vulnerable as well as epmd to external attacks, provided the attacker has obtained the information by tapping into the epmd communication channels. While the IP source address and TCP port number range can be
configured for each Erlang VM, the choice of port numbers is arbitrary, so controlling access via a firewall is difficult. Links between Erlang nodes are not encrypted at all as default, unless using an alternative SSL/TLS driver  inet_ssldist, provided
as a part of Erlang/OTP code.

“Erlang is a user process for the host OS, so the access control must be performed. OS-level virtualization such as FreeBSD jail and User-mode Linux, or even detailed virtualization software such as VMware ESXi hypervisor. Erlang nodes and epmd have two different set of access control methods, and difficult to configure. The parameters disperse in many configuration options and cannot be centrally managed without an external program.”

(Note: the term “epmd” refers to the Erlang/OTP neighbour node discovery daemon. The reader is strongly encouraged to read the original paper to fully understand the technical references addressed by Rikitake and Nakao, in particular the references to network ports and addresses. )

Rikitake and Nakao’s paper may be short and perhaps too “indicative” but it nevertheless does a great job in highlighting the Security issues around an Erlang implementation. If anything, the serious system architect needs to heed the authors’ advice contained in the conclusion:

“The current status of Erlang systems are similar to the situation of the Internet before SSH was invented in 1995; nodes are unconditionally trusting each other, at least for the data channels. The major problem is how to establish a secure P2P link and a set of trusted nodes over an untrusted network such as the Internet. The Erlang distributed node supporting structure is also similar to generic remote procedure call (RPC) subsystems.” (Page 5)

Turning to the cryptographic aspect of Security, the paper shows some options for future enhancements of Erlang:

“Exchanging SSL/TLS certificates is not the only solution; establishment of a pre-shared-key network will be a practical solution to connect large number of hosts over the Internet, and is applicable to Erlang multi-node networks. On a concurrent system, key components of the security algorithms do not scale well. Generating cryptographic random numbers and encrypting/decrypting a cryptographic data stream require keeping the internal states for each stream handled. While current Erlang systems separate the cryptographic functions to another subsystem based on OpenSSL , adding a robust support structure in Erlang will soon be necessary. Efficient cryptographic algorithms for concurrent execution is an essential research for making Erlang secure.” (Page 5 – Conclusion and future works).

Rikitake and Nakao’s research programme, described at the end of the paper looks very promising and I hope to be able to refer to it in the future.