Bug 791001 (CVE-2012-1053)

There have been two vulnerabilities discovered in Puppet
(CVE-2012-1053 and CVE-2012-1054).  Puppet Labs is currently working
with distribution
maintainers, as well as key customers to ensure we are able to patch
this vulnerability before it is exploited.

The CVEs and issues have not been made public yet. We appreciate your
discretion at this time. We have included patches for 2.6.x and 2.7.x.
If you need help with patches for other series or versions of Puppet,
please let us know.


# Summary #

(#12457, #12459) Execs, when run with a user specified but with no
group specified will get root group, so the exec then gets unintended
privileges. This is a permanent change for the forked process. Exploit
requires access to either the command the exec will run or to the
manifests calling execs.

(#12458) Similarly unexpected privileges are given to providers and
types (egid remains as root).

# Details #

CVE-2012-1053 GID Issues (#12457, #12458, #12459) [ Medium ]

#12457 - Real gid always present in supplementary groups

  Overview
  ===================================================
  In Puppet::Util::SUIDManager, Puppet tries to re-init the supplementary
  groups in the "initgroups" method.  At
  lib/puppet/util/suidmanager.rb:148, it reads:

   Process.initgroups(Etc.getpwuid(user).name, Process.gid)

  Since the real gid is probably root, this always adds the gid "0" to
  the list of supplementary groups for the process as per this strace for
  a change to my user account (with 7 supplementary groups):

   setgroups(8, [0, 10, 14, 18, 54, 1002, 1004, 474]) = 0

  This method is called by SUIDManager's change_user method, which is
  called in critical places such as lib/puppet/util.rb:308 in
  execute_posix (as used by lots of things including Exec resources).


#12458 - Only euid changed, not egid

  Overview
  ===============================
  The second problem occurs when only a target user is given to the
  SUIDManager asuser method as opposed to a target user and group, as is
  the case in the following places:
   lib/puppet/provider/ssh_authorized_key/parsed.rb:59
   lib/puppet/type/file/target.rb:46

  In this case, the SUIDManager asuser method at
  lib/puppet/util/suidmanager.rb:78 doesn't change the egid, only the
  euid, so the egid remains as root.

  It seems to me that the gid should be set sensibly if only the user is
  specified, rather than the default of root.

  Demo
  ========
  I've used the following contrived manifest to demonstrate these two
  issues leave us with group privs, but I haven't thought of a reasonable
  way to exploit this under normal conditions.

   ssh_authorized_key { "test":
     ensure => present,
     key    => "AAAA",
     type   => "ssh-rsa",
     user   => "nobody",
     target => "/tmp/suidbug/file",
   }

  Then:
  # mkdir /tmp/suidbug
  # touch /tmp/suidbug/file
  # chmod -R g+w /tmp/suidbug
  # ll /tmp/suidbug/file
  -rw-rw-r--. 1 root root 0 Feb  4 20:17 /tmp/suidbug/file
  # puppet apply sshauthkeys.pp
  notice: /Stage[main]//Ssh_authorized_key[test]/ensure: created
  err: /Stage[main]//Ssh_authorized_key[test]: Could not evaluate:
  Puppet::Util::FileType::FileTypeFlat could not write /tmp/suidbug/file:
  Permission denied - /tmp/suidbug/file
  notice: Finished catalog run in 0.03 seconds
  # ll /tmp/suidbug/file
  -rw-rw-r--. 1 root root 196 Feb  4 20:19 /tmp/suidbug/file
  # cat /tmp/suidbug/file
  # HEADER: This file was autogenerated at Sat Feb 04 20:19:04 +0100 2012
  # HEADER: by puppet.  While it can still be managed manually, it
  # HEADER: is definitely not recommended.
  ssh-rsa AAAA test


#12459 - Permanent uid change doesn't drop supplementary groups

  Overview
  ========
  When execute_posix or similar forks and calls SUIDManager's change_user
  method, it sets permanent=true to change the real uid instead of the
  euid (lib/puppet/util.rb:307).

  In change_user, a different code path is taken when a permanent change
  is made, and so the supplementary groups aren't dropped
  (lib/puppet/util/suidmanager.rb:121), even if the primary group is set.

  Demo
  ========
  This is really easy:

  # cat setgid.pp
  exec { "/usr/bin/id":
   user      => "nobody",
   group     => "nobody",
   logoutput => true,
  }

  # puppet apply setgid.pp
  notice: /Stage[main]//Exec[/usr/bin/id]/returns: uid=99(nobody)
  gid=99(nobody)
  groups=99(nobody),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),1004(sshusers)
  context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023