Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 87341 - [openmotif,lesstif ebuilds] Insecure `/tmp' file handling
Summary: [openmotif,lesstif ebuilds] Insecure `/tmp' file handling
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo Security
Whiteboard: ~3 [ebuild+ masked] koon
Depends on:
Reported: 2005-03-30 14:48 UTC by bartron
Modified: 2005-04-29 11:36 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description bartron 2005-03-30 14:48:22 UTC

Comment 1 bartron 2005-03-30 14:48:22 UTC
  All ebuilds listed below touch files in `/tmp' with constant names... 
allows creation of arbritary previously non-existant files by ordinary 
users and changing of time stamps of previously existing files.

Affected ebuilds:
- lesstif-0.93.94-r3
- lesstif-0.94.0-r6
- openmotif-2.1.30-r12
- openmotif-2.2.3-r6

Sample exploit:

(as unprevileged user)
$ ln -s /etc/nologin /tmp/lesstif-2.1

(as root)
# emerge \=lesstif-0.94.0-r6
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-03-31 00:23:47 UTC
Ebuilds should be fixed.

No need for a GLSA as upgrading to the fixed version won't solve anything, but removing affected versions will be a good idea.
Comment 3 Toni DiBoulda 2005-04-03 15:46:24 UTC
oh great, another minimum severity symlink bug. takes me back to bug #41253 and #41708.
Comment 4 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-13 11:00:49 UTC
i'll fix it as fast as possible, note all affected packages are only ~arch 
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-04-13 11:17:23 UTC
Affected packages being ~, no GLSA will be issued when this is fixed.
Comment 6 Toni DiBoulda 2005-04-15 16:32:43 UTC
Well, proper course of action seems to me remove vulnerable ebuilds and warn
users about dangers until problem is fixed. But since nothing like that happened
in two weeks could you at least confirm again whether or not there will be GLSA
issued once problem is fixed??
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2005-04-16 03:37:06 UTC

GLSAs are useful only if the user needs to take action to go from "vulnerable" to "non vulnerable" state. AFAIK here the problem lies in the ebuild that creates temporary files with predictable names at install time. So people that have the package already installed are not "vulnerable" to anything, only people that consider installing this ~ package are vulnerable. Issuing a GLSA about it won't solve anything. Only removing the vulnerable ebuilds will.

So we are waiting for the package maintainer to fix the affected ebuilds... If he doesn't soon, we'll security.mask those ebuilds... and no GLSA will be issued about it. If the issue was a *run-time* creation of temporary files with predictable names, it would of course be different.
Comment 8 Thierry Carrez (RETIRED) gentoo-dev 2005-04-16 03:38:28 UTC
Furthermore, by policy, we don't issue GLSAs on issues that only affect ~ packages. Please see for details:
Comment 9 Toni DiBoulda 2005-04-16 17:38:55 UTC
Yes, everybody knows that.

And other policy says ~ is for testing, not for objecting users to things known
to be dangerous!

So, proper course of action seems to me delete dangerous ebuilds if no reaction
from package maintainer after maybe ONE or TWO DAYS, but not TWO WEEKS.

Yet, only reaction is "there will be no GLSA".
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2005-04-17 10:25:47 UTC
I agree it's been way too long, we'll package.mask those ebuilds now. Lanius: unmask them when you'll have fixed them.
Comment 11 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-26 06:57:50 UTC
fixed and unmasked
Comment 12 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-29 11:31:28 UTC
can be closed now
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2005-04-29 11:36:52 UTC
Sure, thanks Heinrich :)