Ubuntu 'command-not-found' tool can be abused to spread malware

A logic flaw between Ubuntu's 'command-not-found' package suggestion system and the snap package repository could enable attackers to promote malicious Linux packages to unsuspecting users.

The problem arises from the utility's ability to suggest snap packages for installation when they are missing without a validation mechanism to ensure that packages are authentic and safe.

The loophole was discovered by Aqua Nautilus researchers who have found that approximately 26% of Advanced Package Tool (APT) package commands are at risk of impersonation by malicious snap packages, presenting a significant supply chain risk for Linux and Windows Subsystem for Linux (WSL) users.

It should be noted that while Aqua Nautilus' report focuses on Ubuntu, the problem has broader implications that extend beyond just the popular Linux distribution.

For example, any Ubuntu forks or Linux distributions that use the 'command-not-found' utility by default, along with the Snap package system, are also vulnerable.

Lack of checks in all steps

The 'command-not-found' utility is a Python script that suggests packages to install to allow you to run a specific program that is currently not installed.

For example, if you wanted to run the mojo, but the program is not installed, the command-not-found script will recommend packages to install so you can use the command.

However, its safety presupposes that due diligence has been performed in the lower levels of the supply chain to ensure that the packages the utility suggests are safe to install.

The utility's suggestion mechanism relies on an internal database for APT packages and a regularly updated database from the Snap Store for snap packages, allowing commands to be correlated with packages.

As Aqua Nautilus explains, it is relatively easy for attackers to publish malicious snaps to the Snap Store, given the lack of stringent review processes compared to APT packages.

Snap packages can be published as "strict" or "classic," with the former limiting the software to a sandboxed environment and the latter providing unrestricted access, just like APT packages.

Attackers can take the risk of publishing their bad apps as "classics." However, these require manual review before they're approved, and the chances of getting past those reviews if the malicious functionality is appropriately concealed are high.

The researchers say that even "strict" snaps are extremely risky as they can abuse the option of using "interfaces" for extensive interaction with external resources or the host system's display server, especially when X11 is used, potentially allowing eavesdropping other apps and performing keylogging.

In addition, Aqua's analysts highlight the risk of abusing the auto-update feature of snap packages to deliver "fresh" exploits on a compromised system that targets newly discovered flaws.

One pertinent example of this risk concerns Linux kernel flaws. Since snap packages share the same system kernel as all software that runs on the system, they can potentially exploit a flaw to escape the sandbox.

Typo-squatting and impersonation risks

All the above lays the ground for a risky situation as long as attackers find a way to promote their packages through the 'command-not-found' utility, but as the analysts explain, there's a comfortable margin for that, too.

The first and most simple trick is to associate commands containing typing errors (e.g., 'ifconfigg' instead of 'ifconfig') with malicious snap packages, leading the 'command-not-found' utility to suggest the installation of malware to the user, who is unlikely to realize their typo at that point.

The second method involves attackers identifying and registering unclaimed snap names that users might expect to exist, often because they correspond to known commands or aliases.

"Should a developer wish for their snap to execute a command that deviates from the <snap name>.<application name> format and is not simply <snap name>, they must request an alias," explains the researchers.

"Such a request initiates a manual review process in which the requested alias is voted on to ensure it aligns with the application."

However, if the developers do not register an actual snap under this alias, a threat actor can upload their own packages under that name, which will then be suggested by the command-not-found tool.

This approach exploits a loophole in the naming and aliasing system of snaps, allowing the impersonation of legitimate software without the need for alias requests, taking advantage of unreserved yet predictable names.

The third attack method involves registering malicious snap packages for legitimate APT packages so that the 'command-not-found' utility suggests both.

Aqua Nautilus says 26% of commands can be exploited this way, as many legitimate software publishers have not claimed the corresponding snap package alias for their project, allowing attackers the margin for exploitation.

The security analysts say the volume of exploitation of the above issues is currently unknown, but at least two cases have come to light (1, 2).

Some steps that can be taken to mitigate the risks include users verifying the authenticity of the packages they're about to install, Snap developers holding an Alias registering names that are similar to their apps, and APT package maintainers registering the associated Snap name for their commands.