Abstract:
In December 2023, security agencies from five countries in North America, Europe, and the south Pacific produced a document encouraging senior executives in all software producing organizations to take responsibility for and oversight of the security of the software their organizations produce. In February 2024, the White House released a cybersecurity outline, highlighting the December document. In this work we review the safe languages listed in these documents, and compare the safety of those languages with Erlang and Elixir, two BEAM languages.
These security agencies’ declaration of some languages as safe is necessary but insufficient to make wise decisions regarding what language to use when creating code. We propose an additional way of looking at languages and the ease with which unsafe code can be written and used. We call this new perspective \em{unsafe impedance}. We then go on to use unsafe impedance to examine nine languages that are considered to be safe. Finally, we suggest that business processes include what we refer to as an Unsafe Acceptance Process. This Unsafe Acceptance Process can be used as part of the memory safe roadmaps suggested by these agencies. Unsafe Acceptance Processes can aid organizations in their production of safe by design software.
Is there an advice there relevant to Erlang / Elixir? I would think that the BEAM VM is doing safe memory just fine already but maybe there are nuggets of wisdom in regard to f.ex. avoiding an explosion of reference-counted binaries in long-running processes (and thus steady memory bloat leading to eventual OOM app kill).
Yes, there is a specific section (3.7) of the above reference paper on the BEAM. The TLDR; is
We do categorize Erlang and Elixir as a secure by default languages as long as no unsafe code is loaded and used.
All of the other vectors of concern besides dynamically loaded code are N/A because of the lack of pointers, process memory safety, and immutability. It does say that NIFs can be an issue, but then again any raw native code would have safety questions in any language.
I skimmed the paper so I’ll have to give it a more thorough read later. Another practical takeaway I got was this:
The Erlang Ecosystem Foundation’s Security Working Group provides guidance for avoiding these poor practices [17].
…
[17] Erlang/OTP Security Working Group. 2024. Secure Coding and Deployment
Hardening. Secure Coding and Deployment Hardening Guidelines | EEF Security WG Retrieved April 25, 2024.
For example, the WG’s first recommendation (also covered in the paper) warns that long running applications can run out of atoms and crash. The existence of this document was a TIL for me
I haven’t carefully read the entire paper, but I think there is room to shore up the writing in some places. For instance, this section from the conclusion:
In the past and currently, decisions are and were made to value ease of using unsafe code. These decisions were made to overcome potential or real speed restrictions in the languages and for code reuse reasons. Such decisions tend to encourage the use of unsafe code and encourage programmers and engineers to overlook potential code safety issues found in unsafe code. Heartbleed in OpenSSL [27] is an example of reuse of unsafe code causing vulnerability in large numbers of systems. We question whether these speed and reuse decisions are still relevant.
could potentially be:
The decision to use unsafe code is often made to overcome speed restrictions or enable code reuse. OpenSSL’s Heartbleed [27] is an example where the widespread reuse of unsafe code caused large-scale system vulnerability. We question whether speed and reuse decisions are being properly weighed against risks of safety.
