Chainguard Unveils Memory-Safe Linux Distribution
Chainguard this week made available a memory-safe distribution of Linux, dubbed Wolfi, that promises to eliminate the root cause of the bulk of known software vulnerabilities.
In addition, Chainguard has partnered with the Internet Security Research Group (ISRG) to create a Rustls TLS library for Wolfi available as the default backend in libcurl. All curl images, or anything else that depends on curl, is able to take advantage of the memory safety properties of Wolfi.
Chainguard CEO Dan Lorenc said Wolfi was created using a combination of new libraries written in memory-safe languages and libraries written in unsafe languages that Chainguard implemented in a much more memory-safe way. Core elements include fortify source level 3, position independent executables (PIE), stack-smashing protection (SSP), immediate symbol binding at runtime, read-only relocations and control flow enforcement (CET).
The goal is to provide a safer platform for securing software supply chains that depend heavily on Linux to deploy applications, noted Lorenc. Building applications today on non-memory-safe platforms is simply irresponsible, he added.
The vast majority of security vulnerabilities can be traced back to an issue involving how memory is accessed by an application. Cybercriminals then exploit those vulnerabilities to launch an attack, for example, that takes advantage of a buffer overflow to access data.
Developers are transitioning to memory-safe languages such as Rust, Go, C#, Java, Swift, Python and JavaScript to eliminate many of these vulnerabilities. At the same time, the maintainers of Linux are starting to embrace Rust as an alternative to C to eliminate these types of vulnerabilities from the Linux kernel.
It’s not clear whether developers are abandoning older programming languages in favor of memory-safe languages, but replacing trillions of lines of already-built code that use a variety of legacy languages is a gargantuan task. As new applications are built using memory-safe programming languages, however, the overall state of application security should steadily improve.
Cybersecurity teams clearly have a vested interest in encouraging developers to transition to memory-safe tools and platforms as quickly as possible. The amount of security debt that organizations are being asked to remediate is, at present, unachievable; in some cases, the path to least resistance is going to involve replacing the entire application with a more modern secure alternative.
In theory, at least, cybersecurity teams are collaborating more closely with application developers as DevSecOps best practices continue to mature. As a part of that process, there’s a natural opportunity to encourage developers to use memory-safe languages and platforms. In some cases, organizations are already mandating the use of such tools and platforms.
In the meantime, organizations would be well advised to focus on the cure to cybersecurity issues rather than continuing to treat the symptoms. As long as unsafe platforms and programming languages are allowed, they will only lead to additional cybersecurity chaos.
