When you are in a fight, sometimes you take one on the chin.
In the case of CVE-2020-14386, we may not have taken one on the chin, but it was a hard body shot.
One of the goals of Talos OS is to help everyone run secure Kubernetes. The kernel of Talos was vulnerable, but our defense in depth posture mitigated the impact somewhat.
In short, we have a new release (v0.6.2) that addresses this CVE.
All Talos users should upgrade to this release as soon as possible.
We know that, as much as we want to be, components of Talos Systems’ platform will not be immune to all future attacks.
This is why we have adopted a defense-in-depth approach.
While this is a serious CVE, Talos has a great many novel and interesting features which have mitigated the severity.
KSPP
The kernel within Talos adheres to the Kernel Self-Protection Project guidelines.
Here is how the maintainers of this project describe it:
Kernel self-protection is the design and implementation of systems and structures within the Linux kernel to protect against security flaws in the kernel itself.
This set of configurations helps to:
- reduce the attack surface
- protect memory integrity
- provide probabilistic defenses
- and prevent information exposures
For more on what these mean, checkout the the documentation.
A critically important but relatively rare kernel configuration Talos utilises is CONFIG_MODULES.
This is a key piece of adhering to the KSPP guidelines which few linux distributions can meet, and Talos does.
We worked very hard to solve all of the difficulties in disabling module loading entirely.
While this may have little direct relevance to CVE-2020-14386, I point this out because disabling kernel modules is really a dramatic step once you consider how extensively this feature is used.
By disabling module loading, we eliminate an entire class of attacks and significantly reduce the attack surface of the kernel.
This is just one example, and I encourage you to take a look at the recommended settings outline in the KSPP documentation.
No Console, No SSH
Over the years, bash and ssh have had their share of CVEs.
(I don’t mean to single out bash, but I use it as an example of a shell.)
In Talos, we have removed anything and everything that isn’t absolutely required for Kubernetes and the Talos services.
One way that has manifested itself is the removal of all shells and SSH.
Instead, Talos has an API.
By design, the API offers no ability to write to the filesystem.
I point this feature out, and it really is a feature, in order to provide another example of how Talos removes an entire class of attacks.
Immutable
A read only filesystem can be a powerful tool in making it more difficult for an attacker to move about an exploited system.
In Talos, the rootfs is a read-only in the form of a squashfs.
A major benefit of squashfs, compared to a read-only mounted ext4 filesystem for example, is that even a root user can’t remount the squashfs as read-write.
This reinforces the immutability of the system, which is a fundamental design pattern with Talos.
Ephemeral
When an attacker sinks their claws into a system, they usually want to do so in a way which allows them to siphon data from the system for as long as possible, with as little effort as possible.
With an ephemeral filesystem for runtime-specific needs, Talos makes the amount of effort required for an attacker to “set up shop” and keep it running a poor value.
Takeaway
By now, I hope you see an emerging design pattern in Talos.
We take a defense-in-depth approach to security.
Because of the lack of shell, KSPP compliant kernel, an immutable filesystem, etc. – while this particular vulnerability existed in Talos, it is likely that Talos is immune to attempts to exploit it to do “evil things”, like install a backdoor or rootkit.
I hope I have illustrated how the design of Talos significantly reduces the probability that a CVE will affect your systems.