Okay, hello, good morning here at the lightning talks at Fostum in Brussels.
I want to introduce you Thomas Neiman, senior security technology specialist from Ericsson,
and we will give us an introduction to compiler-optioning hiring guides for C and C++.
Give him a warm welcome.
Thank you very much.
Start.
Thank you very much.
I work for the network platform and telecommunications company Ericsson,
but today I'm here to talk about the compiler options hardening guide for C and C++.
I also am in the open-source security foundation as the sub-initiative lead for the compiler hardening
best practices initiative that has produced this guide, and we had an initial release in November last year.
I hope many of you might have heard about the open-source security foundation, but maybe for those who might have not.
This is a community of software developers and security specialists who are working towards improving the security of the open-source ecosystem.
This means both innovative open-source software as well as these efforts to develop best practices and collaboration around security in open-source software.
The background for the work I'm talking about today is the C and C++ hardening challenge.
We all know that the C and C++ languages are consistently the preferred languages for systems programming, embedded systems, and performance critical applications.
But C and C++ are also memory unsafe, and that means that they are susceptible to a certain classes of programming defects that affect the memory integrity of software written in C and C++.
In unfortunate cases, these defects can lead to software vulnerabilities that can be used by malicious actors to then exploit the software in different ways.
Addressing these types of vulnerabilities in C and C++ in a large scale presents several significant challenges.
There are many memory-safe alternatives for these languages, but there is also a lot of C and C++ code in the world today.
Rewriting all of these existing code, the memory-safe languages is both umber-ably expensive, both in monetary value, but also from this kind of opportunity-cost point of view.
The alternatives often have unsafe dependencies, and these unsafe dependencies will then slow down the migration to the memory-safe alternatives.
One example of this is Rust, which is a very promising language and provides memory-safe guarantees.
But if you look at the dependencies, there are some references here to recent surveys where the conclusion was that over 70% of Rust crates, the Rust packages in the official package repository,
have some form of dependencies to either C or C++.
This is not just a technological problem, but this is also something that is actually gathering regulatory attention.
In the US, something that has been very influential in shifting the attitudes towards surface security was the presidential executive order on improving the US cybersecurity in May 2021.
Also in the EU, we've had this cyber-resilience act that has also been heavily discussed among the open source communities as well,
and specifically relate to memory safety. We've in the past two years seen a lot of guidance from cyber security authorities, including the USA NSA and the US CISA,
who have issued these joint publications with other national cybersecurity authorities, the most recent being the December 2023 document on memory-safe road-waps,
where they urge organizations to explicit plans how to shift away from memory unsafe code.
So what we are doing in this initiative is that we are providing a guide for compiler options hardening, and currently this is specifically geared towards C and C++ code.
The idea with this is that we have a guide that will help developers and packages of software to configure programming tools during development to reduce the attack surface of produced software.
You can think about this as something that is quite close to what sometimes is called product hardening.
If you have a hardening document that usually provides guidance to the parties who are deploying this software in configuring the operational parameters that help you deploy a software security in its operating environment,
so we are focusing on these kind of parameters during development that helps everyone who is then later deploying the software.
And the modern C and C++ compilers provide many optional features that help improve the security of the produced software,
but this must be explicitly enabled when compiling software for the software to actually benefit from them.
And if you are consuming software from the major Linux distributions, then these are usually, the major Linux distributions are usually enabling these features by default,
but then if you are consuming open source software from source, then you are responsible for making sure that when the software is built, these kind of protections are enabled correctly.
And of course, these also come with various challenges, right? So I will not go into this in detail here, but these challenges can sometimes make it difficult to deploy these in a sort of a correct and correct manner,
and we hope that this guide will help practitioners in some of these challenges.
And the current situation we are seeing now is that according to some academic surveys, the situation for these are actually much better on the desktop side,
but especially embedded systems often ship without these protections enabled.
So here is a publication from the Network and Distributed Systems Security Symposium from 2022, which shows that there is kind of like a radical difference between the deployment of specific hardening mechanisms between desktop and embedded systems.
And of course, compiler options hardening is not a silver bullet, right? So this is something that is necessary in combination with the adoption of memory safe languages, secure coding standard, as well as security testing,
but we hope that this is like one way of addressing the C&C++ hardening challenge.
So if you look at the guide, you will find that this is sort of divided into sort of four main parts.
So we have a large section on the recommended compiler options that currently cover a wide range of different features in GCC and CLANG LLVM,
and this includes both flags that one developers about different software defects that are related to these security vulnerabilities,
but also flags that will add instrumentation to the binaries, that helps the binaries be resilient at runtime against attacks that are trying to exploit possibly residual defects in the software.
We also have a section on discouraged compiler options, so these are compiler options that have some specific purpose, but if you use them inappropriately, they may impact the security posture of the produced software in one way or another.
We also have a section on sanitizers, so these are compiler-based tools designed to be used during development and testing to basically pinpoint memory safety issues and other defects,
and these provide really a lot of valuable information for debugging and testing, but they often have sort of more runtime overhead or memory overhead which makes their deployment for production software more difficult,
but they are very valuable during the development and testing phases.
Then we have some information on managing debug data, so this is something that can help in making produced binaries more resistant to reverse engineering,
where you have threat actors actually analyzing binaries specifically for ways to exploit them, but of course in practice these decompiler tools that are used for this purpose, they can work with debugging information,
so the security of the system should not depend on omitting this information, but there is some sort of guidance with this respect.
As I mentioned, we had the initial release of the guide in November 2023, and we have a lot of activity on the OpenSSF best practices working group GitHub pages where the development happens,
and for this year we are planning on documenting new features that are in upcoming versions of GCC and CLAN, so this is actually an area where the compiler communities are very active in providing new valuable features that are security relevant,
and we hope that this guide will eventually cover all these new features as well, and then we also have some plans with partners to also introduce information on new compilers,
so we hope that this will also be possible during this year.
And then another effort is that we have a separate guide on using compiler annotations in GCC and CLAN, so there is some work in progress work up on the GitHub if you are interested in that.
And this is of course, everything is open source, and I hope that we also welcome contributions also from people who are not necessarily security experts,
so we've had very valuable contributions on improving the readability and presentation of the guide, so if you think that there is something that could be improved, I urge you to open an issue or open a pull request towards this material.
And other development happens on the OpenSSF best practices working group.
GitHub repository and we have calls every other week on Zoom to discuss any open PRs and short developments around the guide, so these are also public.
And this slide has some links, more links on how you can participate in the work that OpenSSF does if you're interested, so the slides are available on the talk page on the FOSTEM site if you want to access the links.
And lastly, I'll leave this slide open so if you want to access the guide itself, you can do so at the URL here or by scanning the QR code.
And that's it for my side, and I want to thank the FOSTEM organizers for giving me the opportunity to present this work here. Thank you very much.
Thank you.