VyOS Networks Blog

Hello, Community!

There were quite a few security incidents lately that caught everyone's attention.

Thankfully, none had any real impact on VyOS security, but let's go through them and discuss them in more detail.

CVE-2024-3094: xz backdoor

As you likely know, the widely used compression library xz/liblzma was backdoored by a co-maintainer who inserted an M4 macro that would include malicious code into the release tarball. Thus, the backdoor code was not visible in the git repository. Still, all distributions that built packages from the release tarball would have it, and it would allow the attacker access to any machine that was running an OpenSSH server (if it was built with a specific patch that many Linux distros use).

The xz incident certainly raises many questions about how to improve maintenance and packaging practices to prevent anything like that from happening in the future.

However, a good thing is that the backdoored package didn't make it to any stable versions of any major distros — certainly not to Debian Bookworm that we currently use for rolling release and VyOS 1.4/Sagitta builds, much less into the much older Debian Buster that VyOS 1.3/Equuleus is based on. We also don't build our version of xz, so this issue safely went past us.

When we build packages from source, we usually build them directly from the git repositories rather than release tarballs. We may want to make a point to never use un-audited release tarballs as a matter of policy.

CVE-2024-1086 (Flipping Pages)

CVE-2024-1086 (nicknamed Flipping Pages) is a vulnerability in the Linux kernel that allows an unprivileged local user to gain root privileges. It affects kernel versions from v5.14.21 to v6.6.14.

VyOS 1.4/Sagitta and rolling release builds currently use Linux 6.6.23 (already not vulnerable), and VyOS 1.3/Equuleus uses kernel 5.4.268, which was never vulnerable.

Since the vulnerability was not remotely exploitable, it wouldn't pose much danger since all users on VyOS currently have full access to the system anyway.

For that reason, we may sometimes pospone security releases if a vulnerability requires the ability to run executables on the local system — if one can log in to a VyOS router, they, at the moment, can also just run sudo there. Once we reintroduce limited operator accounts, we will have to be much more careful about local privilege escalation vulnerabilities, of course!

VyOS rolling release signing key file leak

This is a rather old event that we just neglected to cover in our blog posts due to its low significance. The encrypted minisign private key file was leaked into the vyos-rolling-nightly-builds repository and remained publicly accessible for some time.

The root cause was the behavior of an auto-commit GitHub Action. The action that builds rolling release images automatically updates the file with the latest VyOS build version. However, due to its behavior quirk and the fact that the signing key was placed in a temporary directory to perform the signing, the action committed the contents of that temporary directory as well — together with the private key file.

This sounds pretty terrible, but the real impact was very limited:

• First, the private key file was encrypted, and its password was never leaked. Bruteforcing an AES password of that length is a non-trivial problem.
• Second, LTS releases are signed with a different key, and that key's file was never leaked, so the issue was limited to rolling releases.

We rotated the rolling release signing key, nonetheless, just in case. That means that updating older nightly builds  add system image will cause verification errors. Just make sure that you download it from the official location.

To prevent breaking the signing chain, we may also want to add a backup key to the rolling release builds. We already do that for LTS releases if we have to rotate the LTS signing key.

That's all for now, but stay tuned for updates!