The Many Perils of /tmp

You may not know this, but creating and using files in /tmp is dangerous1.“ Why?” you ask. Well, /tmp is world readable and world writable, meaning that any user on the system may read or write to it. Therefore, when an application creates files in /tmp, it must take special care to create those files with safe, restrictive permissions and unpredictable names.

Vulnerabilities resulting from the insecure use of /tmp are surprisingly common. In this post, I’ll discuss three security vulnerabilities that I discovered with the help of TmpWatcher. These vulnerabilities exemplify some of the ways that files in /tmp can be abused.

DoS in Zim (CVE-2020-10870)

Zim is a graphical editor for wiki pages. When Zim starts, it creates a directory at /tmp/zim-<USERNAME> with 0700 permissions if the directory does not already exist. While the directory’s permissions are sufficiently restrictive, the predictability of the directory’s name can allow a malicious user to cause a denial of service. If Zim is unable to create or access the temporary directory when it starts, it will crash.

If a user’s /tmp/zim-<USERNAME> directory does not already exist (files in /tmp are often cleaned up upon reboot), a malicious user can anticipate the names of Zim’s temporary directories and create them with 0700 permissions before other users start Zim. When Zim attempts to start, it will be unable to read or write to the preexisting temporary directory, as this directory is owned by the malicious user. In other words, any user on the system can prevent all other users from using Zim. 

The simplest solution to this vulnerability is that Zim should create its temporary directories with random, unpredictable names. In this way, a malicious user cannot predict the directories’ names and cannot create the directories in advance. A better solution, however, is for Zim to not use /tmp at all. Instead, it could use a directory that is not world writable, such as $XDG_RUNTIME_DIR.

Information Disclosure in Audacity 2 (CVE-2020-11867)

Audacity is an open source, multitrack audio editor and recorder. On the surface, it might appear that Audacity has the same issue as Zim. Audacity creates a directory with a predictable name at /var/tmp/audacity-<USERNAME>. Unlike Zim, however, if Audacity is unable to write to this temporary directory, it prompts the user to select a new location for its temporary files. In this way, Audacity mitigates the risk of a DoS. Audacity uses these temporary files for recovery in the event of a crash. Therefore, this temporary directory must have a predictable name so that Audacity can find it.

When Audacity is used to record audio, it stores *.au files in its temporary directory. Unfortunately, the permissions on this directory are not adequately restricted. /var/tmp/audacity-<USERNAME> is created with 0777 permissions. On most Linux distributions, the default umask is 002, meaning that the directory actually gets created with 0775 permissions. This allows any user with access to the system to read from Audacity’s temporary directory and, therefore, listen to the audio that it’s recording.

The simplest solution is for Audacity to create its temporary directories with 0700 permissions. However, like Zim, a better solution might be for Audacity to save its recovery files in a location that is not world readable.

Malicious Code Injection in Apache Ant (CVE-2020-1945, CVE-2020-11979)

Apache Ant is a tool for automating software build processes. It provides a wide array of actions (called “tasks” in Ant parlance) that can be configured to run as part of the software build process. Unlike Audacity and Zim, Ant uses random names for the files it creates in /tmp, and an attacker cannot predict them in advance. However, Ant does not make any attempt to create files with secure permissions. The permissions of Ant’s temporary files are, therefore, only as secure as the user’s umask.

For most Ant tasks that create temporary files, this results in an information disclosure, as unauthorized users may be allowed to read the temporary files that Ant creates in /tmp. For the FixCRLF task, however, it could lead to arbitrary code execution. This task adjusts text files so that they conform to a set of conventions. For example, FixCRLF can automatically fix end-of-line characters during build. In order to do this, it:

  1. Makes a copy of the text file in /tmp/fixcrlfXXXXXXX, where Xs represent random numbers.
  2. Modifies the temporary file to conform to a predefined set of conventions.
  3. Checks to see whether the modified file in /tmp differs from the original.
    1. If the temporary file differs from the original, then the original file is overwritten by the temporary file.
  4. Deletes the temporary file.

Because these files are created in /tmp, an unauthorized user may be able to read their contents at any time before step 4 completes, resulting in an information disclosure vulnerability. If the user’s umask is sufficiently loose, an unauthorized user may have write permissions on these temporary files. This means that, between steps 2 and 3, an attacker could modify the contents of the temporary file. 

If the attacker is able to modify the temporary file’s contents, the attacker could execute arbitrary code as another user. For example, if the file contains source code, any user could potentially inject malicious source code into the temporary file after FixCRLF completes its modifications but before it performs its check in step 3. Then, when step 3 runs, the temporary file would be guaranteed to differ from the original. FixCRLF would then overwrite the original file with the new, malicious file. The malicious source file would then be built into the project. When the project is run, it would run the malicious code that was originally injected into the temporary file.

To remedy this issue, the maintainers of Apache Ant have implemented two safeguards:

  1. By default, files are created with more secure permissions that do not allow anyone but the owner to read or write to them.
  2. A new option, ant.tmpfile, has been added so that Ant can be instructed to store its temporary files in a location that is not world read/writable.

Conclusion

In practice, vulnerabilities involving /tmp often have minimal impact3. Furthermore, they are easy to work around or mitigate (by setting a more restrictive umask, like 027 or 077). Exploitation of these vulnerabilities requires the attacker to have local access, and this is only the case in multiuser environments or if a system has already been compromised.

Even low-severity vulnerabilities can be used to cause irreparable damage in specific cases. Generally, the use of /tmp should be avoided. If /tmp must be used, extra care should be taken to ensure that temporary files are created and handled safely.

  1. It’s not just /tmp you need to be concerned about. Improper usage of other directories, such as /var/tmp, /dev/shm, and /var/run, can lead to security vulnerabilities.
  2. The Audacity development team was notified of this vulnerability privately on March 10, 2020. As of November 28, 2020, they’ve not notified me of any plans to resolve the issue.
  3. Though, in some cases, such as this one, the impact can be severe.