The UNIX and Linux SysAdm Handbook: Why are cached man pages a "security risk"?

Question

The UNIX and Linux System Administration Handbook says:

man maintains a cache of formatted pages in /var/cache/man or /usr/share/man if the appropriate directories are writable; however, this is a security risk. Most systems preformat the man pages once at installation time (see catman) or not at all.

What is the "security risk(s)" here?

There is the obvious security risk that someone can alter the man pages to trick a (novice) user into running something undesirable, as pointed out by Ulrich Schwartz in their answer, but I am looking for other ways this could be exploited. Thanks!

Answer 1

It's not safe to let users manipulate the content of man pages (or any data really) that will also be used by other users, because there is a danger of cache poisoning. As the old BOFH joke goes:

To learn everything about your system, from the root up, use the "read manual" command with the "read faster" switch like this: rm -rf /

(To be clear, do not run this command.) But if I control the man page cache, you might type man rm to see a cached fake man page that tells you rm is indeed "rm - read manual" and not "rm - remove files or directories". Or even output terminal escape sequences that inject code into your shell.

Answer 2

Let's say that the system in question is a web server. Let's also say that the admin of the server makes available some software installed on the system to the general public (or a corporate intranet) via a web page. It could be as simple as an image resizer, a calculator or a dictionary.

If the software had man pages associated with it when it was installed, then the admin — being the kind and considerate person that they are — might decide that making those man pages available to the users of the web service would also be a good idea.

So, the 'Help' icon on the web page launches a script that grabs one or more — cached — man pages and sends them to the user's browser.

Any person or code with write access to the cache directory can modify those files to:

• inject arbitrary Javascript that will be executed by visiting user's browsers
• harvest telemetry data from all visiting users and forward it to some repository for later processing/profiling
• harvest authentication credentials — possibly even the credentials of a privileged user of the system (like the admin)

Each of the above can be abused in many, many different ways by anyone with imagination and loose morals/ethics.

Answer 3

Any time a directory is made globally writable, a security flaw is created. Ignoring what the intended purpose of the directory is and how that can be subverted, just having it writable is a problem.

Here are a few possible issues not related to the function of the directory:

• If there are no other directories on the filesystem writable to the user, this would provide any user a way to use space on that filesystem they could not otherwise use
• Any user could save files in the directory, filling up the filesystem to cause a denial of service attack. If this is the same filesystem as /var/log, it could prevent logs from being written
• Files could be hidden in this directory, outside of expected locations. These could persist after account deletion, and if the filesystem is mysteriously filled up, might be difficult to find
• If files or directories are created with the same name as future cached files, it could prevent correct functioning of the intended use for the directory (even if the contents of those files is not itself malicious). Adjusting permissions on those files might make it more difficult to be automatically fixed.

Answer 4

The relevant concept here is attack surface.

Attack surface is the range of places where an attacker can look for, and potentially find, a vulnerability.

A directory that a compromised account can write to is attack surface that can be used to try to compromise other accounts, taking advantage of bugs in software those other accounts run and how that software parses the content of that directory.

Using shared cache directories requires that one trust the other users with write access to that directory to write content to that directory only in the expected form. If tools involved in rendering man pages have vulnerabilities, providing that trust can be foolish.

(Another form of attack on shared directories is creating symlinks there that point to a file whose contents an attacker would like to overwrite but doesn't have permissions to do so; when a different user account tries to update the cache entry associated with the file the symlink is at, a tool that wasn't carefully written can overwrite the target file instead of the symlink).

---

Note that attack surface mitigation should be done even when no open vulnerabilities in a piece of software are currently known, because the process reduces the chances of a future attack being successfully used against your system.

Answer 5

Most modern distributions pre-cache man pages (by processing with troff) when the appropriate package is installed. This is not a problem.

The problem occurs when the original man files are present but the cache is empty (i.e. the cache files are not pre-generated).

There are two ways to deal with this:

1. Run the man page through troff every single time as the user
2. Run the man page through troff once as root and save to the cache directory

To run as root man would need to be setuid. If there were any security flaws in anything e.g. command line parsing, the attacker could get elevated privileges

Here is the relevant source: https://git.savannah.gnu.org/cgit/man-db.git/tree/src/man.c

Fortunately all major distros now pre-cache man pages, so it is not really anything to worry about

Answer 6

Another risk: Buffer overruns. What if a fake manpage contains a ridiculously long line that overruns your pager's line buffer, and somehow triggers the execution of a shell escape? Problems like this are still being discovered right and left; it seems like no sooner is one bug fixed than another is discovered.

Or it might not be a buffer overrun, but some other attack based on invalid input. Opening "man pages" created by untrusted users is like opening all the attachments that came with suspicious emails: It allows an attacker to deploy any known vulnerability of the program reading the file (in this case, your pager.) Can it handle any conceivable input safely? There is no way to know for sure.