Bug 219281 - CVE-2006-6698 GConfd uses non-unique directory name in /tmp leading to local DoS
CVE-2006-6698 GConfd uses non-unique directory name in /tmp leading to local DoS
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: GConf2 (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
David Lawrence
source=redhat,reported=20061212,impac...
: Security
Depends On: 219279
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-12 08:19 EST by Lubomir Kundrak
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-20 16:51:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 Desktop 141138 None None None Never
GNOME Desktop 167030 None None None Never

  None (edit)
Description Lubomir Kundrak 2006-12-12 08:19:53 EST
+++ 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
around.

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 Matthias Clasen 2006-12-15 10:46:30 EST
After discussion with Mark Cox, this is a low impact issue, doesn't have to
block GA.
Comment 2 RHEL Product and Program Management 2006-12-15 11:00:25 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Ray Strode [halfline] 2006-12-15 15:41:09 EST
as per comment 1, clearing GA flag
Comment 4 Ray Strode [halfline] 2007-06-20 16:41:17 EDT
Hi,

There are a few ways we could address this problem:

1) use the kernel user or session keyring to store the information we're
currently storing in /tmp
2) make gconf get on the session bus, and export methods to get the information
that's currently stored in /tmp
3) look up the session guid and name the directory based on the guid

Of the available options, 3 is the least invasive, because it only involves
looking at an environment variable.  It's also not fool proof, it just makes the
directory name harder to figure out.

Long term, gconf is going to lose its orbit dependency entirely and use dbus for
ipc between the client lib and session daemon.  When that happens, this problem
will solve itself.  

I talked this over a bit with Havoc today, and the consensus is that this issue
isn't important enough to fix without sufficient customer interest.  Any change
carries a potential risk of breaking things associated with it, so we want to be
careful what changes go in.

Anyway, dev nacking for now.
Comment 5 RHEL Product and Program Management 2007-06-20 16:51:13 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 6 Josh Bressers 2007-06-21 07:04:30 EDT
Why has a security flaw been automatically closed WONTFIX?  In no way is this
acceptable or responsible behavior.
Comment 7 Ray Strode [halfline] 2007-06-21 14:00:33 EDT
Hi,

So I talked to Josh about this a little bit today and the conclusion of the
discussion is that I should give a little more explanation on why this bug is
WONTFIXed and point out that WONTFIXing the bug is an explicit decision and not
something that's just a side effect of flag churn.

While fixing this problem wouldn't be technically difficult to do, it does come
with an associated risk of regression.  gconf plays a fairly integral part in
presenting the user with a functional desktop, so changes made to it shouldn't
be made lightly.

While the issue pointed out in this bug is valid, fixing the issue probably
doesn't outweigh the risk of the changing GConf.  This holds even more true,
because there is no customer interest.  The standard response to these types of
denial of service issues is the "don't do that" response.  That is to say, it's
not unreasonable to expect a sysadmin to resort to social discipline if an
unruly user tries to do this type of thing.

This also applies for things like fork() bombs, and using up all the disk space
in /tmp for instance.

This is something that should get addressed, but not for RHEL 5.  If there was
customer interest, we could provide a fix that is off by default and on with an
environment variable or some such thing.

Anyway, for now, the answer is WONTFIX.

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