Elixir Is (Still) Safe

In March 2021 Nathan Long revealed Elixir is Safe, a put up in regards to the safety advantages of utilizing Elixir, which targeted on reminiscence and thread security. It is a superb article for programmers and executives in regards to the safety advantages of Elixir. In July 2023 I googled “Elixir is Safe”, and the primary outcome was a snippet from the paper, “Vision for a Secure Elixir Ecosystem: An Empirical Study of Vulnerabilities in Elixir Programs”, which was revealed by the ACM in April 2022.

Several of the paper’s authors are college students, and this put up just isn’t meant to criticize them as researchers. The paper is written as a response to Nathan’s article, which precisely describes the safety advantages of Elixir. The paper’s claims are deceptive, and the truth that it at the moment ranks above the unique article on Google, and was revealed in a good journal, warrants a response.

“Practitioners perceive Elixir to be a ‘safe’ language, as the language allows practitioners to write fast software programs without introducing vulnerabilities, unlike other languages, such as C[16]. Positive perception of practitioners about the safety and security Elixir programs is subject to empirical validation. Practitioner perceptions are formed through personal experience, and not based on empirical evidence [9]. A systematic empirical investigation that quantifies reported security vulnerabilities can shed light on the state of security of Elixir programs. Such empirical investigation can also yield recommendations for practitioners and researchers on how to securely develop Elixir programs.”

[16] Nathan Long. 2021. Elixir is Safe. https://dockyard.com/blog/2021/03/30/elixir-is-safe

Nobody thinks Elixir “allows practitioners to write fast software programs without introducing vulnerabilities”. The article “Elixir is Safe” by no means makes that declare, somewhat it mentions that Elixir is a reminiscence protected language, which C just isn’t, and discusses the thread security advantages of Elixir. These are each essential matters, for instance Elixir fully eliminates safety points attributable to knowledge races, a extreme vulnerability that may result in customers being logged into the flawed account, a catastrophe for banking and medical portals.

An empirical research exhibiting that Elixir applications comprise vulnerabilities is no surprise, as a result of software program written in each language has them. Imagine Elixir as a kind of asphalt which reduces the speed of potholes in roads, and Nathan’s article is explaining this profit. Then a paper is revealed saying, “roads paved with Elixir still have potholes”, ignoring that it ends in fewer potholes. The paper doesn’t point out reminiscence or thread security in any respect, that are the precise safety advantages Nathan discusses. Rather, it surveys common open-source Elixir initiatives for vulnerability associated commits.

Which repos had been chosen for the dataset? The paper doesn’t point out them, under is a listing pulled from the dataset. The unix command awk -F "," '{print $1}' ELIXIR_FINAL_SECURITY_BUG_DATASET.csv | kind | uniq was used to get this listing.

1. 30-days-of-elixir
2. absinthe
3. analytics
4. awesome-elixir
5. credo
6. curlconverter
7. distillery
8. edeliver
9. elixir
10. elixir-koans
11. guardian
12. httpoison
13. papercups
14. phoenix
15. phoenix-trello
16. poison
17. quantum-core
18. realtime
19. rustler

It is stunning to solely see 19 repos, when the paper says 25. The inclusion of 30-days-of-elixir, awesome-elixir, and elixir-koans is debatable, contemplating these repos don’t retailer initiatives supposed to be run in manufacturing. The counts for “Elixir Files” and “Elixir-related Commits” within the dataset do match the paper.

These numbers do match the dataset, however the definition of “program” is deceptive. For instance, commit 2d68e9c maps to 2 recordsdata within the dataset:

absinthe/take a look at/absinthe/section/doc/complexity_test.exs
absinthe/lib/absinthe/section/doc/complexity/outcome.ex

View this commit on Github. Both of those recordsdata are thought-about a “program” within the paper. It is deceptive to say the dataset has “319 programs with vulnerability related commits”, the paper got here to that quantity by counting recordsdata per commit labeled as weak.

In the paper’s dataset, the repo for Plausible Analytics is included, with commit f7b37fe. You can view this commit on Github, however it’s for a PR with 32 modified recordsdata, so the commit alone just isn’t sufficient data to find out what vulnerability the dataset is referring to. The paper mentions that commits had been discovered by way of a key phrase seek for phrases typically used to explain vulnerabilities, certainly one of which is “sql”.

lib/plausible_web/controllers/api/external_controller.ex

postgres_health=caseEcto.Adapters.SQL.question(Plausible.Repo,"SELECT 1",[])do{:okay,_}->"ok"e->"error: #{inspect(e)}"finish

Sobelow will flag this code as weak, though it isn’t, as a result of no consumer enter is being handed to the SQL question.

lib/plausible_release.ex

defpdo_create_ch_db()dodb_to_create=Keyword.get(Application.get_env(:believable,:clickhouse),:database)IO.places("create #{inspect(db_to_create)} clickhouse database/tables if it doesn't exist")Clickhousex.question(:clickhouse,"CREATE DATABASE IF NOT EXISTS #{db_to_create}",[])finish

The string interpolation in a Clickhouse DB question seems suspicious, however the db_to_create worth just isn’t set by consumer enter, so there isn’t any vulnerability. The key phrases “security” and “vulnerability” additionally seem within the PR. Link to sub-commits:

b3f783e – Adds a container safety software, not associated to Elixir.

57171f8 – The textual content of this remark says, “fixing some vulnerabilities identified by the scanning tools”, nevertheless it concerned a Debian improve, not associated to Elixir.

The paper counts f7b37fe as “28 programs with vulnerability related commits”, as a result of it entails 28 Elixir supply code recordsdata, which isn’t right. The lack of readability across the weak code within the dataset is regarding, making it not possible to really replicate the paper’s findings, as a result of it’s a must to guess which particular strains the dataset is referring to as weak. The dataset accommodates no labels for the kind of safety problem discovered (DoS, XSS, CSRF, and so forth), no data on the severity of every problem, and no dialogue on how an attacker would use every vulnerability. This limits its utility in discussing the safety of Elixir purposes.

It is extremely unlikely that the dataset from this paper consists of vulnerabilities associated to string or reminiscence security, which is the principle level Nathan accurately makes in his article Elixir is Safe.

Paraxial.io secures Elixir and Phoenix purposes. Professional providers, together with Elixir developer safety coaching and penetration testing, are additionally out there. Schedule a name in the present day.