| Summary: | [openmotif,lesstif ebuilds] Insecure `/tmp' file handling | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | bartron <bartron> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | lanius |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | ~3 [ebuild+ masked] koon | ||
| Package list: | Runtime testing required: | --- | |
|
Description
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 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. oh great, another minimum severity symlink bug. takes me back to bug #41253 and #41708. i'll fix it as fast as possible, note all affected packages are only ~arch Affected packages being ~, no GLSA will be issued when this is fixed. 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?? 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. 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 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". I agree it's been way too long, we'll package.mask those ebuilds now. Lanius: unmask them when you'll have fixed them. fixed and unmasked can be closed now Sure, thanks Heinrich :) |
