Arxiv++ AI-Generated Summary

Arxiv link for Unsafe Impedance: Safe Languages and Safe by Design Software, by Lee Barney and Adolfo Neto

Problem Statement

This paper addresses the insufficiency of merely declaring programming languages as "memory safe" for achieving secure software. The paper argues that while such declarations are necessary, they fail to address the ease with which unsafe code can be written and integrated, leading to vulnerabilities.

Main Claims

• The concept of "unsafe impedance" is introduced as a novel perspective for evaluating language safety in the context of software security. Unsafe impedance refers to the difficulty programmers experience when complying with language restrictions on writing unsafe code.
• A "Secure by Default" language is defined as one that protects against the production of all Common Vulnerability and Exposures (CVEs), particularly memory-related CVEs.
• While languages like C#, Go, Java, Python, Rust, and Swift are declared memory safe, they all allow unsafe code to be written or loaded from libraries, making them "unsecure by default."
• Erlang and Elixir, two BEAM languages, are considered "secure by default" due to their functional nature, immutability, and lack of pointer manipulation capabilities. However, they also allow the integration of "Native Implemented Functions" (NIFs) that can introduce unsafe code.
• The paper proposes an "Unsafe Acceptance Process" (UAP) as a business process to enhance software security. UAPs impose a significant barrier to the loading and use of potentially unsafe code, aiming to increase unsafe impedance.

Methodology

The paper analyzes nine commonly used programming languages (C#, Go, Java, Python, Rust, Swift, Erlang, Elixir, and C/C++) by providing examples of how unsafe code can be written or loaded in each language. The authors evaluate the level of unsafe impedance present in each language based on the syntactical and procedural hurdles required to write or use unsafe code.

Key Results

• The study finds that none of the languages declared memory safe in cybersecurity documents are truly "secure by default," as they allow unsafe code to be incorporated.
• Erlang and Elixir are categorized as "secure by default" languages due to their functional nature and lack of native unsafe code capabilities. However, the authors highlight the potential for introducing unsafe code through NIFs, emphasizing the need for strong security measures.
• The paper proposes an "Unsafe Acceptance Process" (UAP) as a strategy for organizations to mitigate risks associated with unsafe code, especially in languages like Erlang and Elixir, which are susceptible to vulnerabilities introduced by NIFs.