Description: Tenshi 0.15 creates a tenshi.pid file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for tenshi.pid modification before a root script executes a “kill `cat /pathname/tenshi.pid`” command.
Created attachment 489380 [details]
This also fixes bug 611082, but there's one annoying issue with some missing files in the tarball. I'll report it upstream in a second. Proxy maintainers please review.
Created attachment 489382 [details]
Ok, the missing files got fixed in about 30 seconds. Here's a new version with no caveats.
Thanks, please let us know when you are ready for stabilization or call it yourself.
Gentoo Security Padawan
Maintainers? I'm happy to fix this myself.
(In reply to Michael Orlitzky from comment #4)
> Maintainers? I'm happy to fix this myself.
It's been almost a month since the report and no answer from maintainers,
CCing proxy-maint to let them know the situation.
@Michael if no answer in the next 2 or 3 days, could you please ensure that is ready for stabilization?
Gentoo Security Padawan
I don't use tenshi myself -- I discovered the bug by accident -- so let's try this: I just committed v0.16 to the tree as ~arch. If no one files any bugs in the next few days and the maintainers don't speak up, just proceed with stabilization and I'll clean up afterwards.
I tested out 0.16 and noticed that it was starting tail as root instead of the tenshi user. It looks like the changes done to move the pidfile creation before dropping privs also made everything else occur before dropping privs. This has some unfortunate consequences, since the program tenshi calls for tail can be specified in the config and the ebuild installs the config as writable to the tenshi user.
I've made a pull request with a potential fix:
(In reply to Brian De Wolf from comment #7)
> the ebuild installs the config as writable to the tenshi user.
Hey, you found another root exploit =)
The "tenshi" user can not only write whatever he wants for the "tail" command, but he can put "set uid root" into tenshi.conf to gain root the next time the daemon starts (because it will run his "tail" command as root).
I made a tenshi-0.16-r1 that leaves tenshi.conf owned by root:root. Thanks!
The fix for this isn't quite complete in ::gentoo, Brian has another commit upstream that is needed. I've pinged the maintainer to see if we can't get a v0.17 tagged; otherwise, I can always do an -r2 with Brian's patch.
The bug has been referenced in the following commit(s):
Author: Michael Orlitzky <email@example.com>
AuthorDate: 2017-10-19 13:55:13 +0000
Commit: Michael Orlitzky <firstname.lastname@example.org>
CommitDate: 2017-10-19 13:55:13 +0000
app-admin/tenshi: new version 0.17.
This version completes the fix for the vulnerable PID file handling
reported in bug 626654. Thanks to the proxy maintainer Brian De Wolf
for making sure that this was fixed correctly upstream.
Package-Manager: Portage-2.3.8, Repoman-2.3.3
app-admin/tenshi/Manifest | 1 +
app-admin/tenshi/tenshi-0.17.ebuild | 47 +++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)}
So let's wait a few days until we restart stabilization.
(In reply to Michael Orlitzky from comment #8)
> (In reply to Brian De Wolf from comment #7)
> > the ebuild installs the config as writable to the tenshi user.
> Hey, you found another root exploit =)
> The "tenshi" user can not only write whatever he wants for the "tail"
> command, but he can put "set uid root" into tenshi.conf to gain root the
> next time the daemon starts (because it will run his "tail" command as root).
> I made a tenshi-0.16-r1 that leaves tenshi.conf owned by root:root. Thanks!
Was this a Gentoo-only vulnerability or was it an upstream bug so we should get a CVE?
(In reply to Thomas Deutschmann from comment #13)
> Was this a Gentoo-only vulnerability or was it an upstream bug so we should
> get a CVE?
Check the title bar of your web browser =)
@arches, please stabilize.
Cleanup done by treecleaners.
GLSA request filed
This issue was resolved and addressed in
GLSA 201804-18 at https://security.gentoo.org/glsa/201804-18
by GLSA coordinator Aaron Bauman (b-man).