Bug 219280 (CVE-2006-6698) - CVE-2006-6698 GConfd uses non-unique directory name in /tmp leading to local DoS
Summary: CVE-2006-6698 GConfd uses non-unique directory name in /tmp leading to local DoS
Alias: CVE-2006-6698
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Whiteboard: source=redhat,reported=20061212,impac...
Keywords: Reopened, Security
Depends On: 219279
TreeView+ depends on / blocked
Reported: 2006-12-12 13:16 UTC by Red Hat Product Security
Modified: 2015-03-02 10:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-29 01:59:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 141138 None None None Never
GNOME Bugzilla 167030 None None None Never

Description Lubomir Kundrak 2006-12-12 13:16:30 UTC
+++ This bug was initially created as a clone of Bug #219279 +++

Description of problem:

GConf uses the directory /tmp/gconfd-$LOGNAME for storing a lock file (and
possibly some other stuff -- I do not know, I know nearly nothing about GConf)
even if GCONF_GLOBAL_LOCKS environment is not set. As the /tmp directory is
sticky, it is possible for any user to create the directory with this name prior
to first login of a new user, effectively preventing it from using GConf
clients. The impact of this is quite serious, as the user can't use most of
Gnome, Evolution, etc. and it's quite hard for a non-technican user to work it

Additionaly, I think any temporary directory and file should disappear when
application terminates. It is obvious that it is not a good practice not to do so.

Version-Release number of selected component (if applicable):

At least FC5 and FC6's GConf.

How reproducible:

Before user logs in/launches GConfd for the first time. Some systems erase /tmp
at each startup or use memory-based filesystem for it. In that case the problem
is reproducible after each startup.

Steps to Reproduce:

This migh be obvious enough
while (true); do touch /tmp/gconfd-$(tail -n1 /etc/passwd |awk -F: '{print
$1}'); done

Comment 1 Ray Strode [halfline] 2007-06-21 18:03:14 UTC
Closing this bug WONTFIX.

See the explanation in bug 219279 for more details.

Comment 2 Ray Strode [halfline] 2007-06-21 18:03:47 UTC
bug 219281 that is.

Comment 3 Lubomir Kundrak 2007-11-02 16:42:04 UTC
I thought this was left open for devel, but I can not find the bug ID, so
reopening this as it is still a valid problem, though of a very low severity.

Comment 5 Lubomir Kundrak 2008-04-04 08:12:11 UTC
This is still a valid flaw. Leaving open.

Comment 7 Ray Strode [halfline] 2008-05-29 01:59:03 UTC
I fixed this bug upstream, so will be fixed in F10.

Not going to fix in earlier releases.

Comment 8 Tomas Hoger 2008-05-29 07:09:10 UTC
Related upstream bug reports:


Comment 9 Tomas Hoger 2008-05-29 07:40:36 UTC
The Red Hat Security Response Team has rated this issue as having low security
impact. The risks associated with fixing this bug are greater than the low
severity security risk. We therefore currently have no plans to fix this flaw in
Red Hat Enterprise Linux 3, 4, or 5.

Comment 10 Red Hat Bugzilla 2009-10-23 19:05:21 UTC
Reporter changed to security-response-team@redhat.com by request of Jay Turner.

Note You need to log in before you can comment on or make changes to this bug.