[Pkg-puppet-devel] SECURITY: Authorization vulnerability in Puppet 2.6.x

Nigel Kersten nigel at explanatorygap.net
Wed Dec 1 21:06:16 UTC 2010


(Note the scope of this is not as bad on Debian as on some of our
other platforms)

I'm still dealing with the fallout upstream, but can get the merge done tonight.

Original email:

to:
puppet-announce at googlegroups.com,
puppet-users at googlegroups.com,
puppet-dev at googlegroups.com

cc:
security at debian.org,
secalert at redhat.com,
security at fedoraproject.org,
cert at cert.org,
soc at us-cert.gov


The Puppet Labs team has identified a security vulnerability in Puppet
version 2.6.0 and later.  The vulnerability allows, under certain
circumstances, authenticated Puppet nodes to be able to view or
manipulate resources on other Puppet 2.6.x nodes, including the Puppet
Master.

Versions prior to 2.6.0 are not vulnerable.

Puppet Labs is releasing Puppet 2.6.4 to address this issue.  Adding an
auth.conf configuration file if one is not present in your environment
will also provide protection from this issue.

$ cd /etc/puppet
$ wget --no-check-certificate
https://github.com/puppetlabs/puppet/raw/2.6.x/conf/auth.conf

The checksum of this file should be: c34e20b7904b66ea97328f1a3846a848

Detail
------

If a given node or server is missing an auth.conf file in /etc/puppet,
they may be vulnerable to information disclosure or resource
manipulation from authenticated Puppet nodes. In both cases the scope is
limited to the privileges of the remote Puppet process.

Minimum conditions for server

* Running 2.6.0, 2.6.1, 2.6.2, 2.6.3 or any other 2.6.x release missing
the auth.conf file
* Attacker has access to SSL credentials of another node.

Minimum conditions for client

* Running 2.6.0, 2.6.1, 2.6.2, 2.6.3 or any other 2.6.x release missing
auth.conf file
* Attacker has access to SSL credentials of another node.
* Puppet client is running as a daemon (not --onetime)
* Puppet configured in “listen” mode with --listen
* Attacker’s host is allowed to connect via namespaceauth.conf

Vulnerable Install Methods

* Install from gems
* Install from Mac packages
* Install from source
* Install from Solaris Blastwave packages

Not Vulnerable Install Methods

* Install from Debian debs
* Install from Red Hat RPMs

Note: If you remove auth.conf, you are vulnerable, regardless of install
method.

To determine if you are vulnerable you can execute the puppet resource
command, like so:

$ puppet resource -H attack.target.mydomain user puppet

Secured (auth.conf present):

(Attack against server requires puppetport specification, against client
does not, assuming default ports. )

$ puppet resource -H attack.target.mydomain user puppet --puppetport 8140
/usr/lib/ruby/1.8/puppet/indirector/rest.rb:57:in `deserialize': Error
403 on SERVER: Forbidden request: attack.host.mydomain (x.x.x.x) access
to /resource/user/ [search] authenticated  at line 93 (Net::HTTPError)

Insecure (auth.conf missing):

You get the user info:

$ puppet resource -H attack.target.mydomain user puppet
user { 'puppet':
   comment => 'Puppet configuration management daemon,,,',    uid => '104',
   gid => '107',
   home => '/var/lib/puppet',
   shell => '/bin/false',
   password => '*',
   ensure => 'present'
}

If you have any questions, comments or concerns about this issue please
email - security at puppetlabs.com.

Regards

James Turnbull

--
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571



More information about the Pkg-puppet-devel mailing list