Thomas Nyman, Ericsson
C and C++ are consistently the preferred languages for systems programming, embedded systems, and various performance-critical applications. While C and C++ offer the outstanding performance and flexibility, they also introduce a unique set of security challenges; they are particularly susceptible to memory-safety issues, a class of software defects strongly associated with security vulnerabilities such as buffer overflows, format string vulnerabilities, and memory corruption. Recently, there has been an increased focus on such memory-safety issues from leading cybersecurity organization such as the US Cybersecurity & Infrastructure Security Agency (CISA) , the National Security Agency (NSA), and other national cybersecurity agencies, culminating in a US White House Office of the National Cyber Director (ONCD) report urging software manufacturers to adopt memory-safe system programming languages, such as Rust, in favor or C and C++ as part of embracing a secure by design approach to software development.
However, addressing the memory-safety hardening challenge on a large scale presents several significant challenges: Firstly, it is unaffordable to rewrite all existing C and C++ code into another language; creating replacements to key pieces of software will take significant resources to become effective, with no clear overall benefit, but a significant opportunity cost. Virtually all modern operating systems today based on system components, such as kernels, are written in C or C++. Similarly, the language runtimes for high-level languages are often themselves written in C or C++. Secondly, the economics of programming language choices are more intricate than the rhetoric cybersecurity organizations have adopted make it appear.
Security is not the only non-functional consideration, and while there are many memory-safe alternatives for developing enterprise and cloud-native software, the reason C and C++ retain their popularity for systems and performance-critical programming is the difficulty in replicating their flexibility and performance while removing or restricting unsafe programming constructs. Finally, even if organizations manage to widely phase out C and C++ in favor of safer languages, it will not eliminate all security vulnerabilities. Even promising alternatives, such as Rust, currently rely on dependencies built on C, C++, or code that requires ‘unsafe’ language extensions. With the ubiquitous use of C and C++ in the embedded device, industrial control, and IoT space, the chances of removing and replacing C and C++ are virtually nil.
To improve software to be more memory-safe, a series of techniques will need to be undertaken to gradually evolve the quality and security of the code:
- · migration to memory-safe alternatives where feasible, especially for critical software
- · easier to use tooling for debugging, diagnostics and application security testing
- · pro-active vulnerability mitigation and prevention in software though the use of compiler-based binary hardening mechanisms
OpenSSF Compiler Options Hardening Guide for C and C++
In November 2023, the Open Source Security Foundation (OpenSSF) published the Compiler Options Hardening Guide for C and C++ that is focused on helping developers make informed choices regarding compiler options to harden their software against prevalent software defects. Compiler flags are powerful tools that can significantly enhance the security of C and C++ code without requiring expensive refactoring or rewriting in newer, more memory-safe languages. Many such compiler features are also useful for discovering memory safety issues during debugging and testing.
In this talk, Thomas will give an introduction to the OpenSSF Compiler Options Hardening Guide for C and C++. He will talk about how the guide came into existence in the OpenSSF, its current structure and future extensions. This talk particularly intends to actively invite feedback and call for collaboration.
nyman-compiler-options-hardening-guideExplore the conference agenda
Sponsors
