OS Packages

About

Linux distributions such as Debian, Ubuntu and Red Hat Enterprise Linux build thousands of packages and publish them in signed repositories. Servers install the operating system, the web server, the runtime and often the database from them, then keep them updated. A bad package here runs as part of the operating system itself.

Install scripts run as root when a package installs or updates, often through unattended upgrades, which install updates automatically. Its services then run at every boot.

If It Is Malicious

If an OS package is malicious, it runs as part of the operating system with root rights, on every server that installs or updates it.

Its code runs inside these technologies.

Apache HTTP ServernginxPHP-FPMPHP™PythonLinuxMySQLPostgreSQL

See It in the Stack

Examples

These are well-known names from OS Packages, written as you would meet them in an inventory, an alert or a lockfile, the file that records every version a build installed.

openssh-server

The SSH server, which the XZ Utils backdoor reached.

openssl

The encryption library under most network software.

xz-utils

Compression tools whose library carried a backdoor in 2024.

nginx

The web server, as packaged by the distribution.

sudo

Lets permitted users run commands as root.

How Bad Code Gets In

These are the ways bad code can reach your systems through OS Packages. None of them needs a flaw in your own code, so outside code needs checking as much as your own.

• An upstream project ships a backdoor and the distribution packages it, as with XZ Utils.
• A third-party repository added for one tool can replace any package on the server.
• A flaw in a core package such as OpenSSL reaches every service that uses it.

How to Check

These checks show what came from OS Packages, whether a known bad version is in use, and how to keep one out next time.

• Keep an inventory of installed packages and versions on every server and image.
• Follow your distribution's security notices, such as Debian advisories, Ubuntu security notices or Red Hat errata.
• Install only from signed repositories, and review any third-party repository before adding it.
• Check for a named bad version with the package manager, for example dpkg -l or rpm -q.

Well-Known Incidents

Each incident below is a real case, told at the level of its public advisory. The tag says how the bad code got in, and the link opens the primary source.

• Malicious UpdateCVE-2024-30942024

  XZ Utils Backdoor

  A contributor who had spent over two years earning maintainer trust hid a backdoor in the release files of xz versions 5.6.0 and 5.6.1.

  Reach On some Linux distributions it reached the SSH server, where it could have let the attacker into any machine running it. A developer caught it because SSH logins had become slightly slower, before it reached most stable releases.

  Affectedxz-utilsliblzma5

  Source: openwall.com (opens in a new tab)

In Common Stacks

These common stacks take code from OS Packages. Open one to see where that code sits among its layers and who runs each one.

• WordPress on Linux, Apache, MySQL and PHP
• WordPress on nginx and PHP-FPM
• A Node.js App Behind nginx
• Confluence, Java on Tomcat
• A Django App
• A Rails App on Puma
• A Containerised App on Kubernetes

Sources

• Debian security information (opens in a new tab)
• Ubuntu security notices (opens in a new tab)
• Red Hat Customer Portal: security (opens in a new tab)