Bug 791001 - (CVE-2012-1053) CVE-2012-1053 Puppet 2.6.13 group ID handling issues
CVE-2012-1053 Puppet 2.6.13 group ID handling issues
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20120222,repor...
: Security
Depends On: 790898 790917 801972 801974 809594
Blocks: 742180 767031
  Show dependency treegraph
 
Reported: 2012-02-15 17:07 EST by Kurt Seifried
Modified: 2016-11-08 11:27 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-17 17:51:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for CVE-2012-1053 and CVE-2012-1054 (41.72 KB, patch)
2012-02-15 17:28 EST, Kurt Seifried
no flags Details | Diff

  None (edit)
Description Kurt Seifried 2012-02-15 17:07:07 EST
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
Comment 3 Kurt Seifried 2012-02-15 17:22:00 EST
This is embargoed, no release date has been set yet, I have contacted PuppetLabs and requested more information.
Comment 4 Kurt Seifried 2012-02-15 17:28:21 EST
Created attachment 562348 [details]
Patch for CVE-2012-1053 and CVE-2012-1054
Comment 5 Tomas Hoger 2012-02-16 03:15:34 EST
(In reply to comment #3)
> This is embargoed, no release date has been set yet, I have contacted
> PuppetLabs and requested more information.

Dominic researched these problems, adding to CC.
Comment 7 Todd Zullinger 2012-02-22 00:46:02 EST
Per conversation with Michael Stahnke at Puppet Labs, the release that was planned for tonight has been pushed to tomorrow.  I noticed a minor regression in the 2.6.14 packages we'll be using, so they're going to fix that up before release.
Comment 8 Vincent Danen 2012-02-23 12:05:45 EST
External Reference:

http://puppetlabs.com/security/cve/cve-2012-1053/
Comment 9 Kurt Seifried 2012-03-09 19:50:08 EST
Created puppet tracking bugs for this issue

Affects: fedora-all [bug 801972]
Comment 10 Kurt Seifried 2012-03-09 19:51:33 EST
Created puppet tracking bugs for this issue

Affects: epel-all [bug 801974]
Comment 11 Fedora Update System 2012-03-10 16:52:43 EST
puppet-2.6.14-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2012-03-10 16:53:04 EST
puppet-2.6.14-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2012-03-11 13:01:58 EDT
puppet-2.6.14-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2012-03-11 14:53:16 EDT
puppet-2.6.14-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2012-03-11 14:53:35 EDT
puppet-2.6.14-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

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