Bug 188302 - CVE-2006-1057 GDM file permissions race condition
Summary: CVE-2006-1057 GDM file permissions race condition
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gdm
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Ray Strode [halfline]
QA Contact: Mike McLean
Whiteboard: impact=low,reported=20060407,embargoe...
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-07 19:04 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2007-05-01 17:06:55 UTC

Attachments (Terms of Use)
Proposed upstream patch (1.21 KB, patch)
2006-04-08 01:32 UTC, Josh Bressers
no flags Details | Diff
latest upstream patch (2.92 KB, text/x-patch)
2006-04-11 15:06 UTC, Ray Strode [halfline]
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0286 normal SHIPPED_LIVE Low: gdm security and bug fix update 2007-05-01 17:06:38 UTC

Description Josh Bressers 2006-04-07 19:04:50 UTC
GDM file permissions race condition

Marcus Meissner discovered a race condition issue in gdm which affects
the way it modifies the permissions on the .ICEauthority file.

The problem is that there is a race condition between the time stat()
is run on the file and the time chown() and chmod() are run.

The patch that caused this error is here:

We don't have a fix yet.

Comment 1 Josh Bressers 2006-04-08 01:32:51 UTC
Created attachment 127492 [details]
Proposed upstream patch

Comment 2 Ray Strode [halfline] 2006-04-11 14:57:16 UTC
So there has been a bit of discussion about how exploitable this problem really is.

One thing Marcus didn't originally notice is that a bug in the problem code
prevents it from easily being exploited.

Namely, the code only runs if 

stat (".ICEauthority", &s) && S_ISREG (s.st_mode)

evaluates to true.  The first clause was probably supposed to read

stat (".ICEauthority", &s) == 0

but the "== 0" part was forgotton.  This means those two clauses can only
evaluate to true if the stat() call fails AND the S_ISREG() macro succeeds when
fed the uninitialized s.st_mode value.

This means the exploitable code will only run if the stack happens to have the
right bytes in it.  I don't believe there is currently a known method of
manipulating the stack such that the exploitable code can be run.

Also, the upstream maintainer has already fixed this code in public CVS and done
a release, with the messages:

2006-04-07  Brian Cameron  <brian.cameron@sun.com>

        * daemon/slave.c: Now logic unlinks .ICEauthority file if it
          looks fishy rather than trying to chown/chmod it.  This
          is to resolve CVE-2006-1057.


2006-04-10  Brian Cameron  <brian.cameron@sun.com>

        * daemon/slave.c:  Better fix for resolving CVE-2006-1057
          provided by Hans Petter Jansson <hpj@novell.com>

so I don't know how relevant the embargo is.

Comment 3 Ray Strode [halfline] 2006-04-11 15:06:20 UTC
Created attachment 127619 [details]
latest upstream patch

This is the second patch that got committed upstream.

Comment 4 Josh Bressers 2006-05-11 18:56:02 UTC
A flaw was found with this patch.  This upstream bug cotains a followup patch
that properly sets the GID.


Comment 9 Red Hat Bugzilla 2007-05-01 17:06:56 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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