Bug 230007 (CVE-2006-5214) - CVE-2006-5214 xdm race
Summary: CVE-2006-5214 xdm race
Status: CLOSED WONTFIX
Alias: CVE-2006-5214
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: reported=20061010,source=cve,public=2...
Keywords: Security
Depends On: 210312 212166 212167
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-25 19:44 UTC by Josh Bressers
Modified: 2010-12-22 18:39 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-22 18:39:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Josh Bressers 2007-02-25 19:44:08 UTC
Race condition in the Xsession script, as used by X Display Manager (xdm) in
NetBSD before 20060212, X.Org before 20060225, and Solaris 8 through 10 before
20061006, causes a user's Xsession errors file to have weak permissions before a
chmod is performed, which allows local users to read Xsession errors files of
other users.

Comment 1 Vincent Danen 2010-12-22 18:39:01 UTC
In xinitrc's Xsession (RHEL4) this problem does exist:

11 # redirect errors to a file in user's home directory if we can
12 if [ -z "$GDMSESSION" ]; then
13     # GDM redirect output itself in a smarter fashion
14     errfile="$HOME/.xsession-errors"
15     if cp /dev/null "$errfile" 2> /dev/null ; then
16         chmod 600 "$errfile"
17         exec > "$errfile" 2>&1
18     else
19         errfile=$(mktemp -q /tmp/xses-$USER.XXXXXX)                          
20         if [ $? -eq 0 ]; then
21             exec > "$errfile" 2>&1
22         fi
23     fi
24 fi

Xsession as provided in kdebase for RHEL4 is a symlink to the xinitrc-provided
Xsession script.

While the copy of /dev/null to ~/.xsession-errors does use the user's umask
(upstream changes the umask to 077 before the copy), this is only a problem if
the user's home directory is using non-default permissions (0700 is the
default).

So provided the user hasn't changed their home directory permissions to
something insecure (which allows for exposure to potentially more damning
things than ~/.xsession-errors), this shouldn't ever be exposed.  RHEL5 has the upstream umask change.


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