|Summary:||[openmotif,lesstif ebuilds] Insecure `/tmp' file handling|
|Product:||Gentoo Security||Reporter:||bartron <bartron>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Whiteboard:||~3 [ebuild+ masked] koon|
|Package list:||Runtime testing required:||---|
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) 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) 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) 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) 2005-04-16 03:37:06 UTC
Toni, 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) 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: http://www.gentoo.org/security/en/vulnerability-policy.xml
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) 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) 2005-04-26 06:57:50 UTC
fixed and unmasked
Comment 12 Heinrich Wendel (RETIRED) 2005-04-29 11:31:28 UTC
can be closed now
Comment 13 Thierry Carrez (RETIRED) 2005-04-29 11:36:52 UTC
Sure, thanks Heinrich :)