chmod race in doUidshiftIntoContainer()

Bug #1502270 reported by Seth Arnold
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lxd (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

doUidshiftIntoContainer() has an unsafe Chmod() call that races against
the stat in the Filepath.Walk() function. A symbolic link created in
that window could cause any file on the system to have any mode of the
attacker's choice.

func (set *IdmapSet) doUidshiftIntoContainer(dir string, testmode bool, how string) error {
        convert := func(path string, fi os.FileInfo, err error) (e error) {
                uid, gid, err := GetOwner(path)
                if err != nil {
                        return err
                }
                var newuid, newgid int
                switch how {
                case "in":
                        newuid, newgid = set.ShiftIntoNs(uid, gid)
                case "out":
                        newuid, newgid = set.ShiftFromNs(uid, gid)
                }
                if testmode {
                        fmt.Printf("I would shift %q to %d %d\n", path, newuid, newgid)
                } else {
                        err = os.Lchown(path, int(newuid), int(newgid))
                        if err == nil {
                                m := fi.Mode()
                                if m&os.ModeSymlink == 0 {
                                        err = os.Chmod(path, m)
                                        if err != nil {
                                                fmt.Printf("Error resetting mode on %q, continuing\n", path)
                                        }
                                }
                        }
                }
                return nil
        }

        if !PathExists(dir) {
                return fmt.Errorf("No such file or directory: %q", dir)
        }
        return filepath.Walk(dir, convert)
}

This function cannot be used if any processes from the uid ranges in
question could be executing on the system, or on any systems that may mount
the target filesystem via nfs, p9fs, or other networked filesystems.

The mode change needs to be done after dropping privileges to the target
user and group so that the chmod can only affect files owned by the uid
in question.

Thanks

Related branches

CVE References

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This is CVE-2015-1340

information type: Private Security → Public Security
Revision history for this message
Seth Arnold (seth-arnold) wrote :

The LXD team points out that they do not yet support any release with security updates; they are considering this a standard bugfix, https://github.com/lxc/lxd/pull/1188. Furthermore, LXD should own the uid ranges, and the storage for containers should not be on a clustered filesystem, so this is a low-priority issue.

Thanks

Changed in lxd (Ubuntu):
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lxd - 0.19-0ubuntu5

---------------
lxd (0.19-0ubuntu5) wily; urgency=medium

  * Cherry-pick a few more upstream bugfixes:
    - CVE-2015-1340: Fix race condition in uidshift (LP: #1502270)
    - Compare IPs more intelligently when changing core.https_address
    - Drop an unused container property
    - Make cached images and copied images private by default
  * Update debian/tests/control to depend on everything that we need

 -- Stéphane Graber <email address hidden> Tue, 06 Oct 2015 13:20:58 +0100

Changed in lxd (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.