michael orlitzky

CVE-2017-14102: MIMEDefang privilege escalation via PID file manipulation

posted 2017-09-01

Product
MIMEDefang
Vendor
Roaring Penguin Software, Inc. (now AppRiver)
Versions affected
2.80 and earlier
Published on
2017-09-01
Fixed in
Version 2.81
Bug report
https://lists.mimedefang.org/pipermail/mimedefang_lists.mimedefang.org/2017-August/088626.html
MITRE
CVE-2017-14102
OSS-security
https://www.openwall.com/lists/oss-security/2017/09/03/1
Acknowledgments
Dianne Skoll, who had an initial fix ready within minutes of my report.

Summary

MIMEDefang 2.80 and earlier creates a PID file after dropping privileges to a non-root account. This is exploitable by that non-root account to kill root processes, because the init script supplied by MIMEDefang (and many distributions) will send a SIGTERM to the contents of the PID file upon stopping the service.

Details

The purpose of the PID file is to hold the PID of the running daemon, so that later it can be stopped, restarted, or otherwise signalled (many daemons reload their configurations in response to a SIGHUP). To fulfil that purpose, the contents of the PID file need to be trustworthy. If the PID file is writable by a non-root user, then he can replace its contents with the PID of a root process. Afterwards, any attempt to signal the PID contained in the PID file will instead signal a root process chosen by the non-root user (a vulnerability).

This is commonly exploitable through init scripts that are run as root and which blindly trust the contents of their PID files. Examples of said init scripts can be found in the MIMEDefang source tree:

Exploitation

An example of a problematic scenario involving an init script would be,

  1. I run /etc/init.d/mimedefang start to start the daemon.
  2. mimedefang drops to the defang user.
  3. mimedefang writes its PID file, now owned by the defang user.
  4. Someone compromises the daemon.
  5. The attacker is generally limited in what he can do because the daemon doesn't run as root. However, he can write “1” into the PID file, and he does.
  6. I run /etc/init.d/mimedefang stop to stop the daemon while I investigate the weird behavior resulting from the hack.
  7. The machine reboots, because I killed PID 1 (this is normally restricted to root).

Resolution

The problem is resolved in MIMEDefang 2.81 by creating the PID files as root before dropping privileges. The role of the lock files—previously played by the PID files—is now played by a separate set of files (specified on the command-line with -o).

Init script authors should relocate their PID files to /run or a similar root-owned directory.