Bug 219281
Summary: | CVE-2006-6698 GConfd uses non-unique directory name in /tmp leading to local DoS | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Lubomir Kundrak <lkundrak> |
Component: | GConf2 | Assignee: | Ray Strode [halfline] <rstrode> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.0 | CC: | security-response-team |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | source=redhat,reported=20061212,impact=low | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-06-20 20:51:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 219279 | ||
Bug Blocks: |
Description
Lubomir Kundrak
2006-12-12 13:19:53 UTC
After discussion with Mark Cox, this is a low impact issue, doesn't have to block GA. 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. 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. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. Why has a security flaw been automatically closed WONTFIX? In no way is this acceptable or responsible behavior. 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. |