Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <0880ca9f-a632-2da6-8ce6-8be03f332d7f@orlitzky.com>
Date: Thu, 17 Aug 2017 12:48:39 -0400
From: Michael Orlitzky <michael@...itzky.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2017-11746: tenshi privilege escalation via PID file manipulation

Product: Tenshi (log monitoring tool)
Vendor: Inverse Path (F-Secure)
Versions-affected: 0.15 and earlier
Fixed-in: commits 46b0148 and d0e7f28, version 0.16
Bug-report: https://github.com/inversepath/tenshi/issues/6
Author: Michael Orlitzky
Acknowledgments: Andrea Barisani who fixed several other issues and got
  a new release out to help fix this one.

== Summary ==

The tenshi daemon should create its PID file before dropping
privileges. This represents a minor security issue; additional factors
are needed to make it exploitable.

== 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 by init scripts that are run as root and
which blindly trust the contents of their PID files. Tenshi itself ships
a few such init scripts: tenshi.debian-init, tenshi.suse-init, etc.

== Exploitation ==

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

1. I run "/etc/init.d/tenshi start" to start the daemon.

2. tenshi drops to the "tenshi" user.

3. tenshi writes its PID file, now owned by the "tenshi" user.

4. Someone compromises the daemon, which processes untrusted input.

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/tenshi 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 avoided by creating the PID file as root, before dropping
privileges.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.