Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 403963 (CVE-2012-1053) - <app-admin/puppet-2.7.11: Group Privileges Security Issue and K5login Privilege Escalation Vulnerability (CVE-2012-{1053,1054})
Summary: <app-admin/puppet-2.7.11: Group Privileges Security Issue and K5login Privile...
Status: RESOLVED FIXED
Alias: CVE-2012-1053
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Security
URL: https://secunia.com/advisories/48166/
Whiteboard: B1 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-15 21:52 UTC by Matthew Marlowe
Modified: 2012-06-15 18:49 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
2.6.x patch (0001-2.6.x-Fixes-for-CVE-2012-1053-and-CVE-2012-1054.patch,41.72 KB, patch)
2012-02-15 21:52 UTC, Matthew Marlowe
no flags Details | Diff
2.7.x patch (0001-2.7.x-fixes-for-CVE-2012-1053-and-CVE-2012-1054.patch,44.68 KB, patch)
2012-02-15 21:54 UTC, Matthew Marlowe
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Marlowe gentoo-dev 2012-02-15 21:52:59 UTC
Created attachment 302077 [details, diff]
2.6.x patch

High and medium severity vulnerabilities found in Puppet (CVE-2012-1053 and CVE-2012-1054) [not yet public]
gentoo
	x
Matthaus Litteken matthaus@puppetlabs.com
	
9:28 AM (4 hours ago)
		
to security, tmz, micah, apollock, ssm, marc.cluet, secalert, security, mattm, Vitezslav, Mark, Kevin, vcizek
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).

(#12460) Klogin type will write to untrusted locations (write through symlinks)


# 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


CVE-2012-1054 Klogin write through symlink [ High ]

#12460 - Klogin File Handling Issue (Write through symlink)

High risk for users of this type. Users can symlink to arbitrary files, causing
them to be overwritten, such as other klogin files (including root).


# Commits in Fixes #
 2.7.x
 =========
 * 5846da1 Disable replace_file on Windows
 * abb3f4b Remove unnecessary fallbacks in change_{user,group}
 * aedace0 Document uid/gid-related methods in Puppet::Util
 * 52a0c7e Copy owner/group in replace_file
 * d2bfa1f (#12463) eliminate `secure_open` in favour of `replace_file`
 * 2cf4f55 (#12460) use `replace_file` for the .k5login file
 * 101d845 (#12462) user_role_add: use `replace_file` for /etc/shadow
 * 247c35c (#12463) add secure `replace_file` to Puppet::Util
 * 617cbb2 (#12459) drop supplementary groups when permanently dropping UID
 * c06fe4d (#12458) default to users primary group, not root, in `asuser`
 * bfb7b8d (#12457) add users primary group, not Process.gid, in initgroups

 2.6.x
 =========
 * ade5965 Remove unnecessary fallbacks in change_{user,group}
 * 0a09a64 Document uid/gid-related methods in Puppet::Util
 * 2599d56 Copy owner/group in replace_file
 * ead36ff (#12463) eliminate `secure_open` in favour of `replace_file`
 * 1469538 (#12460) use `replace_file` for the .k5login file
 * 8461203 (#12462) user_role_add: use `replace_file` for /etc/shadow
 * 0ad532a (#12463) add secure `replace_file` to Puppet::Util
 * 76d0749 (#12459) drop supplementary groups when permanently dropping UID
 * 50909b9 (#12458) default to users primary group, not root, in `asuser`
 * d00c5cc (#12457) add users primary group, not Process.gid, in initgroups


# Plan #

Puppet Labs is currently rebuilding tarballs and packages of Puppet.
This will result in the following new source packages:
 * Puppet 2.6.14
 * Puppet 2.7.11 ( this will be going into an RC series tomorrow,
  and will go final with the attached patch merged in)
 * 2.6.14 and  2.7.11 will be available on downloads.puppetlabs.com/puppet as
  soon as possible. We will send an update next week when we have a
more concrete timeline for this.
 * Puppet Labs will also push to rubygems.org for those using gems.
 * Hotfixes will be released for Puppet Enterprise 1.0, 1.1, and 1.2.4.
 * Updated packages will be released with Puppet Enterprise 2.0.3.


# Action #

We (Puppet Labs) obviously would like everybody to be as protected from attacks
as possible. We have not disclosed this issue publicly yet.  We will send an
update next week with a more concrete timeline for disclosure.

If you have any questions or need additional clarification on
anything, please respond to security@puppetlabs.com.


Thanks, Matthaus Litteken
Release Engineer -- Puppet Labs
2 attachments — Download all attachments  
0001-2.6.x-Fixes-for-CVE-2012-1053-and-CVE-2012-1054.patch	0001-2.6.x-Fixes-for-CVE-2012-1053-and-CVE-2012-1054.patch
42K   Download  
0001-2.7.x-fixes-for-CVE-2012-1053-and-CVE-2012-1054.patch	0001-2.7.x-fixes-for-CVE-2012-1053-and-CVE-2012-1054.patch
45K   Download
Comment 1 Matthew Marlowe gentoo-dev 2012-02-15 21:54:00 UTC
Created attachment 302079 [details, diff]
2.7.x patch
Comment 2 Tim Sammut (RETIRED) gentoo-dev 2012-02-16 19:13:47 UTC
Matthew, thanks for the bug. Please let us know when there is a timeline for disclosure. If you're able to attach an ebuild to this bug we can ask folks to test it before the issues become public.
Comment 3 Matthew Marlowe gentoo-dev 2012-02-20 14:00:37 UTC
Three new notes:
-  when vulnerability is released, puppet labs plans to also label 2.7.10 a bad release due to other QA issues (I note that 2.7.10 isn't in tree now, so I guess that's good).
-  Security vulnerability will likely become public on either Tuesday or Wednesday so within the next 48hrs or so
-  While I'm an active user of puppet on gentoo and helping with communication between puppet labs and gentoo, matsuu has been maintaining the ebuilds and I cc'd him on this bug to ensure he had heads up.  Of course, if he isn't available - I or most any devs can handle putting out a bump/patch.  I'm happy to help wherever I can.
- At same time as making announcement, puppet labs will be releasing early 2.7.11 and 2.6.14 ...so it may be more like a normal bump than creating an r1/etc
Comment 4 Tim Sammut (RETIRED) gentoo-dev 2012-02-23 14:34:16 UTC
These issues are now public.

http://puppetlabs.com/security/cve/cve-2012-1053/
http://puppetlabs.com/security/cve/cve-2012-1054/
Comment 5 MATSUU Takuto (RETIRED) gentoo-dev 2012-02-27 14:57:16 UTC
sorry for delay. 2.7.11 in cvs.
please mark stable 2.7.11
Comment 6 Tim Sammut (RETIRED) gentoo-dev 2012-02-27 15:02:23 UTC
Arches, please test and mark stable:
=app-admin/puppet-2.7.11
Target keywords : "amd64 hppa ppc sparc x86"
Comment 7 Jeroen Roovers gentoo-dev 2012-02-28 17:58:19 UTC
Stable for HPPA.
Comment 8 Brent Baude (RETIRED) gentoo-dev 2012-02-28 20:16:50 UTC
ppc done
Comment 9 Agostino Sarubbo gentoo-dev 2012-02-29 14:34:44 UTC
amd64 stable
Comment 10 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2012-03-03 12:54:35 UTC
x86 stable
Comment 11 Raúl Porcel (RETIRED) gentoo-dev 2012-03-03 20:29:35 UTC
sparc stable
Comment 12 Tim Sammut (RETIRED) gentoo-dev 2012-03-03 20:34:28 UTC
thanks folks. already part of an existing GLSA request.
Comment 13 GLSAMaker/CVETool Bot gentoo-dev 2012-03-06 01:32:18 UTC
This issue was resolved and addressed in
 GLSA 201203-03 at http://security.gentoo.org/glsa/glsa-201203-03.xml
by GLSA coordinator Sean Amoss (ackle).
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2012-06-15 18:49:17 UTC
CVE-2012-1054 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1054):
  Puppet 2.6.x before 2.6.14 and 2.7.x before 2.7.11, and Puppet Enterprise
  (PE) Users 1.0, 1.1, 1.2.x, 2.0.x before 2.0.3, when managing a user login
  file with the k5login resource type, allows local users to gain privileges
  via a symlink attack on .k5login.

CVE-2012-1053 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1053):
  The change_user method in the SUIDManager (lib/puppet/util/suidmanager.rb)
  in Puppet 2.6.x before 2.6.14 and 2.7.x before 2.7.11, and Puppet Enterprise
  (PE) Users 1.0, 1.1, 1.2.x, 2.0.x before 2.0.3 does not properly manage
  group privileges, which allows local users to gain privileges via vectors
  relate to (1) the change_user not dropping supplementary groups in certain
  conditions, (2) changes to the eguid without associated changes to the egid,
  or (3) the addition of the real gid to supplementary groups.