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…
In this blog post I will try to fill in the missing parts, using the and my speakers’ notes. Hopefully this introduction will provide some context for the video and for the document itself.
The BEAM platform lets us develop uniquely robust systems for mission critical applications. But in the presence of malicious users, even a BEAM application is only as strong as its weakest link.
…in the presence of software errors
Joe Armstrong’s paper “Making reliable distributed systems in the presence of software errors” focusses on how software errors affect reliability, and describes how the BEAM mitigates the effect of software errors that inevitably exist in any non-trivial project. But software errors can also introduce security weaknesses, which may be exploited by a malicious user. No amount of supervision, let-it-crash cool-aid and trapping exits can prevent logic errors that may lead to vulnerabilities.
SSDLC and Secure Coding Practices
So, like any other software project, BEAM projects need a Secure Software Development Life Cycle (SDLC). Such a process consists of many activities, spanning the project lifecycle from inception to retirement, each with its own strengths and weaknesses: threat modelling, static analysis, dynamic security scanning, penetration testing, 3rd party vulnerability tracking, etc.
Secure coding is one of those activities, and it deals with what happens in the editor. It is supposed to make the programmer stop and think: am I doing the right thing? Even if 9 times out of 10, after a moment’s reflection, the conclusion is that it is safe to continue, if the 10th time a weakness is noticed, it can be fixed before the code is even committed. If that weakness had not been spotted during coding, it would hopefully be caught by one of the later SSDLC activities, but it would incur the extra overhead of a bug report, a patch, a new release, verification testing. And of course, if it does not get caught the consequences can be far worse.
Examples
Secure coding practices often take the form of “don’t do this, do that instead”. A common example from the C programming language would be: don’t use strcpy, use strncpy instead. The former function can easily lead to buffer overflows, by making assumptions about the size of the target buffer. The strncpy function makes those assumptions explicit, forcing the programmer to think about buffer sizes and about what should happen if the data doesn’t fit.
It is not always black and white, however: let’s look at client side DOM manipulation in JavaScript, for example. Setting .innerHTML also makes assumptions: it assumes that the HTML being passed in originates from a trusted source. Setting .innerText instead is safer, but sometimes you need to set .innerHTML, for instance in order to allow formatting. So the recommendation should perhaps be read as “use .innerText instead of .innerHTML, unless you know what you are doing”. The main goal is to prevent the programmer from setting innerHTML by default without considering the alternative and the consequences.
On the BEAM, the obligatory example is conversion of user input to an atom. But more about that later.
EEF Security WG
Secure coding guidelines exist for many languages, but not for BEAM languages. Until now…
The EEF Security Working Group has produced a Secure Coding and Deployment Hardening document for the BEAM. It is currently a public draft, and we welcome comments and suggestions through our GitHub repository.
Most recommendations apply equally to all BEAM languages, and code examples are given in Erlang and Elixir, as applicable. The document covers the standard libraries of Erlang and Elixir, but not 3rd party libraries or frameworks, at this time.
Video
That concludes the introduction that is missing from the video. You can watch the rest of the talk on YouTube, and don’t forget to check out the document itself!
Back