Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 602594 - app-accessibility/eflite: root privilege escalation
Summary: app-accessibility/eflite: root privilege escalation
Status: IN_PROGRESS
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B1 [ebuild]
Keywords:
Depends on: 593274
Blocks:
  Show dependency tree
 
Reported: 2016-12-14 02:41 UTC by Michael Orlitzky
Modified: 2021-05-20 22:02 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2016-12-14 02:41:52 UTC
This package uses a socket located at /tmp/es.socket, both by default and as a fallback (if no socket is defined in the config file). Since /tmp is writeable by everyone, any member of the speech group can change /tmp/es.socket to a symlink, pointing to a file of his choice. The next time the eflite service is started, the init script performs,

  chown root:speech /tmp/es.socket
  chmod 660 /tmp/es.socket

That changes the ownership of the *target* of the symlink to root:speech and makes it group-writeable. Thus the speech group attains root.

A similar trick works with hard links.

Before the first time the service is started (i.e. before the socket owned by root:speech exists), any user can create the link -- not just a member of the speech group. To reproduce, install eflite, and make /tmp/es.socket a symlink pointing somewhere important. Start eflite, and watch the target's ownership change.
Comment 1 Thomas Deutschmann gentoo-dev Security 2017-01-08 23:27:37 UTC
@ Maintainer(s): Please tell us how you want to proceed here. Will you look into this or should security take actions?
Comment 2 Michael Orlitzky gentoo-dev 2017-08-18 16:47:28 UTC
I came up with a fix for this, but the package is currently unusable because of bug #593274.
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:16:19 UTC
Unrestricting and reassigning to security@ per bug #705894
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:18:03 UTC
unrestricting per bug 705894
Comment 5 William Hubbs gentoo-dev 2020-05-29 17:46:37 UTC
@mjo:

What was your fix for this?

Thanks,

William
Comment 6 Michael Orlitzky gentoo-dev 2020-05-29 21:04:22 UTC
I still wasn't able to build eflite to test:

  checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
  checking for connect in -lsocket... no
  checking for library containing pthread_create... -lpthread
  ./configure: 410: test: Illegal number: then
  ./configure: 2968: ./configure: Syntax error: Bad fd number

but I still have my temp directory from when I worked on this bug.

The first thing I would try is to see if eflite can be started as a non-root user/group. If it runs as a dedicated user, then you can create /run/eflite as eflite:eflite (755) in the service script with checkpath and the daemon can create the socket itself (660) with no chown/chmod or init script involvement.

If eflite has to run as root, then you should create /run/eflite as root:root with checkpath, and then be careful when you create and checkpath the socket to the proper group. So long as /run/eflite is root:root, its contents should be relatively safe.

Either way, you should never use a socket under /tmp. Just fix the path to /run/eflite/something. Even making it configurable is more trouble than it's worth. If it works out of the box, nobody will want to mess with it.
Comment 7 Miroslav Šulc gentoo-dev 2021-04-29 06:17:03 UTC
eflite might be better dropped, the last version is from 2006-01-18. i don't see any packages depending on it. any objections?
Comment 8 John Helmert III gentoo-dev Security 2021-05-20 22:02:50 UTC
(In reply to Miroslav Šulc from comment #7)
> eflite might be better dropped, the last version is from 2006-01-18. i don't
> see any packages depending on it. any objections?

Yep, I recall this being one of the first packages I recommended treecleaning (on irc). As I recall William meant to look into it but I guess never did or had no luck. CCing treecleaner.