27

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!

Improve this question
3
  • 3
    Bottom line: It's attack surface. Let one user write to the files, and you have to worry about whether the software any other user uses to read those files has vulnerabilities. Don't let anyone write to the files, and you've locked off that route and have less need to worry about bugs in the rendering/viewing tools; in individual terminal emulators; etc. – Charles Duffy Jun 1 at 21:53
  • 4
    Waiting until you know of an individual attack that leverages potential surface before you close off said surface is a good way to always be finding out about attacks only after they've been successfully exploited on your system / against your users. – Charles Duffy Jun 1 at 21:55
  • 2
    With some (soft- or hard)linking you can also trick the man commands to overwrite the files of the executing user. – peterh Jun 3 at 12:41
51

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.

Improve this answer
6

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.

Improve this answer
11
  • 8
    I don't think "the files might be served by a web server" is an in-scope security consideration for the man tool, whose job is to output man pages to the terminal. Even for perfectly legitimate man pages, I'm not aware of any guarantee that they don't contain html special characters - so clearly the hypothetical setup that grabs a man page and serves it with content type text/html without any escaping should be "at fault" here. – ManfP Jun 2 at 22:37
  • 2
    @ManfP Unescaped content ends up in web pages all the time — even in 2021. The new/naive web developers and admins that allow it to happen are (obviously) at fault. The scenario itself is not hypothetical, as I've personally seen it happen more than a few times times over the last few decades. Regurgitated man pages were quite common in the late 90s when Linux was the fresh new hotness. Anyway, the OP was looking for exploits, and this is one. You can still set up a server where this exploit works, if you have any doubts. – Tim Jun 3 at 1:18
  • 1
    I'm familiar with XSS-like attacks and don't doubt that what you describe is possible. But just being a potential security concern doesn't mean being a security concern for the software man. Sure - being misuse-resistant is a valid part of security; but setting up a web server goes far beyond being a simple "user" of man and comes with a huge set of its own security considerations. The web server being misconfigured like you describe would be no more the fault of manthan, say, a command injection in the script fetching the pages. – ManfP Jun 3 at 14:10
  • 1
    @Bodo Thiesen The fundamental error is still outputting non-html data with a content type that makes the browser interpret it as html. If you willingly allow this misinterpretation, then making sure that this is absolutely safe (including any potential caching or write-permissions-issues) is 100% your responsibility and 0% the one of man. – ManfP Jun 3 at 17:03
  • 1
    In fact, on my system both man pages python-websockets and pandoc have non-trivial javascript tags, Pod::Simple::HTML from perl even some with an external domain as src! (And most other man pages contain some <arguments> that would be parsed as invalid html tags, making it more unlikely that anyone would really do this) – ManfP Jun 3 at 19:20
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

Improve this answer
7
  • I don't think I've seen any major distro which does this? – user1686 Jun 2 at 12:00
  • 4
    The man command would be installed setuid-man (with the man user having write access to the cache area), not setuid-root. And man would relinquish that privilege elevation for everything but opening the cache file for writing, it wouldn't run the formatters or pagers as man. – Stéphane Chazelas Jun 2 at 12:17
  • 1
    @user1686 You must be young :p Debian used to have setuid man a long time ago. <check changelog> July 2001: “The .deb doesn't contain setuid binaries any more”. Even today this is supported, but only if the administrator explicitly enables it. – Gilles 'SO- stop being evil' Jun 3 at 22:18
  • @Gilles: Yes, totally my fault for being born late. Don't see what this has to do with "all major distros now". Debian doesn't do it now, does it? – user1686 Jun 4 at 5:55
  • There are more than two ways to do this. The cache could simply be per-user. When Bob runs man, the cached file is created in Bob's file area like /home/bob/man. When Alice runs it, the cache is in /home/alice/man. There could be a cron job which de-duplicates these files system-wide, replacing them with hard links to root-owned files. But man never has to run as root; the cron job doesn't ever have to run man; it just finds identical files, de-dupes them with hard links, chowns them to root and makes them read-only. – Kaz Jun 4 at 6:22
5

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.
Improve this answer
2
  • 5
    "Files could be hidden in this directory, outside of expected locations. " I know at least one Unix worm that hide itself as ... (yes, three dots) in directories where manual pages are stored. Without adequate tools you can loose A LOT of time before finding it... – Patrick Mevzek Jun 2 at 16:09
  • 1
    or my favorite filename ".. " – user10489 Jun 2 at 16:16
5

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.

Improve this answer
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.