An authenticated user may view private Puppet module metadata without repository read access.

A vulnerability in Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with agent SSL keys to (1) cause a denial of service (memory consumption) via a REST request to a stream that triggers a thread block, as demonstrated using CVE-2012-1986 and /dev/random; or (2) cause a denial of service (filesystem consumption) via crafted REST requests that use "a marshaled form of a Puppet::FileBucket::File object" to write to arbitrary file locations.

For certificates that utilize the auto-renew feature in Puppet Server, a flaw exists which prevents the certificates from being revoked.

Utilization of a module presented a security risk by allowing the deserialization of untrusted/user supplied data. This is resolved in the Puppet Agent 7.4.0 release.

Versions of Puppet Agent prior to 1.6.0 included a version of the Puppet Execution Protocol (PXP) agent that passed environment variables through to Puppet runs. This could allow unauthorized code to be loaded. This bug was first introduced in Puppet Agent 1.3.0.

Description of problem: I noticed that puppetmasterd does not initialize its supplementary groups, which may lead to allow puppetmasterd to access files, it should not. E.g. if it is started with "service puppetmaster start", it still has access to all files that allow read access for the supplementary groups of root, e.g. raw disk devices.

I filed an upstream bug report including patches (one needs still to be tested) here: http://projects.reductivelabs.com/issues/show/1806

Version-Release number of selected component (if applicable): puppet-0.24.6-1.fc10 puupet-0.24.6-1.el5

How reproducible: always

Steps to Reproduce: 1. # service puppetmaster start 2. # cat /proc/$(ps --User puppet -o pid | tail -n 1)/status | grep Group Actual results: The output matches "id -G root".

Expected results: The output should match "id -G puppet", i.e. the process should run with the supplementary groups of puppet.

The default supplementary groups of root include the group disk, which e.g. provides raw read access on disk devices.

Additional info: I am not sure, whether this really classifies as a security vulnerability, because https://fedoraproject.org/wiki/Security/Classifications only mentions code execution and denial of service, but imho unwanted access to restricted information is a security vulnerability, too.

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x allows local users to overwrite arbitrary files via a symlink attack on the .k5login file.

Puppet 2.6.x before 2.6.12 and 2.7.x before 2.7.6, and Puppet Enterprise (PE) Users 1.0, 1.1, and 1.2 before 1.2.4, when signing an agent certificate, adds the Puppet master's certdnsnames values to the X.509 Subject Alternative Name field of the certificate, which allows remote attackers to spoof a Puppet master via a man-in-the-middle (MITM) attack against an agent that uses an alternate DNS name for the master, aka "AltNames Vulnerability."

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x allows local users to modify the permissions of arbitrary files via a symlink attack on the SSH authorizedkeys file.

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x, when running in --edit mode, uses a predictable file name, which allows local users to run arbitrary Puppet code or trick a user into editing arbitrary files.

Directory traversal vulnerability in Puppet 2.6.x before 2.6.10 and 2.7.x before 2.7.4 allows remote attackers to write X.509 Certificate Signing Request (CSR) to arbitrary locations via (1) a double-encoded key parameter in the URI in 2.7.x, (2) the CN in the Subject of a CSR in 2.6 and 0.25.

Puppet 2.6.0 through 2.6.3 does not properly restrict access to node resources, which allows remote authenticated Puppet nodes to read or modify the resources of other nodes via unspecified vectors.

From puppet labs: CVE-2012-3864 (Arbitrary File Read)

A bug in Puppet 2.6.16 and 2.7.17 allows authenticated clients to read arbitrary files from the puppet master.

Given a valid certificate and private key, it is possible to construct an HTTP GET request that will return the contents of an arbitrary file on the Puppet master. These requests can retrieve any file that the puppet master has read-access to.

Resolved in Puppet 2.6.17, 2.7.18

From puppet labs: CVE-2012-3867 (Insufficient input validation)

A bug in Puppet 2.6.16 and 2.7.17 uses insufficient input validation for agent certificate names.

An attacker can trick the administrator into signing an attacker’s certificate rather than the intended one by constructing specially crafted certificate requests containing specific ANSI control sequences. It is possible to use the sequences to rewrite the order of text displayed to an administrator such that display of an invalid certificate and valid certificate are transposed. If the administrator signs the attacker’s certificate, the attacker can then man-in-the-middle the deployment’s agent nodes.

Resolved in Puppet 2.6.17, 2.7.18

Directory traversal vulnerability in lib/puppet/reports/store.rb in Puppet before 2.6.17 and 2.7.x before 2.7.18, and Puppet Enterprise before 2.5.2, when Delete is enabled in auth.conf, allows remote authenticated users to delete arbitrary files on the puppet master server via a .. (dot dot) in a node name.

lib/puppet/defaults.rb in Puppet 2.7.x before 2.7.18, and Puppet Enterprise before 2.5.2, uses 0644 permissions for lastrunreport.yaml, which allows local users to obtain sensitive configuration information by leveraging access to the puppet master server to read this file.

telnet.rb in Puppet 2.7.x before 2.7.13 and Puppet Enterprise (PE) 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows local users to overwrite arbitrary files via a symlink attack on the NET::Telnet connection log (/tmp/out.log).

Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 uses predictable file names when installing Mac OS X packages from a remote source, which allows local users to overwrite arbitrary files or install arbitrary packages via a symlink attack on a temporary file in /tmp.

Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with an authorized SSL key and certain permissions on the puppet master to read arbitrary files via a symlink attack in conjunction with a crafted REST request for a file in a filebucket.

Puppet 2.6.x before 2.6.15 and 2.7.x before 2.7.13, and Puppet Enterprise (PE) Users 1.0, 1.1, 1.2.x, 2.0.x, and 2.5.x before 2.5.1 allows remote authenticated users with agent SSL keys and file-creation permissions on the puppet master to execute arbitrary commands by creating a file whose full pathname contains shell metacharacters, then performing a filebucket request.

Puppet before 3.3.3 and 3.4 before 3.4.1 and Puppet Enterprise (PE) before 2.8.4 and 3.1 before 3.1.1 allows local users to overwrite arbitrary files via a symlink attack on unspecified files.

Puppet Module Tool (PMT), as used in Puppet 2.7.x before 2.7.23 and 3.2.x before 3.2.4, and Puppet Enterprise 2.8.x before 2.8.3 and 3.0.x before 3.0.1, installs modules with weak permissions if those permissions were used when the modules were originally built, which might allow local users to read or modify those modules depending on the original permissions.

Unspecified vulnerability in Puppet 2.7.x before 2.7.23 and 3.2.x before 3.2.4, and Puppet Enterprise 2.8.x before 2.8.3 and 3.0.x before 3.0.1, allows remote attackers to execute arbitrary Ruby programs from the master via the resourcetype service. NOTE: this vulnerability can only be exploited utilizing unspecified "local file system access" to the Puppet Master.

Puppet 2.7.x before 2.7.22 and 3.2.x before 3.2.2, and Puppet Enterprise before 2.8.2, deserializes untrusted YAML, which allows remote attackers to instantiate arbitrary Ruby classes and execute arbitrary code via a crafted REST API call.

Puppet Labs Puppet Enterprise before 2.8.0 does not use a "randomized secret" in the CAS client config file (casclientconfig.yml) when upgrading from older 1.2.x or 2.0.x versions, which allows remote attackers to obtain console access via a crafted cookie.

Puppet 2.6.x before 2.6.18 and Puppet Enterprise 1.2.x before 1.2.7 allows remote authenticated users to execute arbitrary code on the puppet master, or an agent with puppet kick enabled, via a crafted request for a report.

The default configuration for puppet masters 0.25.0 and later in Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2, allows remote authenticated nodes to submit reports for other nodes via unspecified vectors.

Puppet 2.7.x before 2.7.21 and 3.1.x before 3.1.1, and Puppet Enterprise 2.7.x before 2.7.2, does not properly negotiate the SSL protocol between client and master, which allows remote attackers to conduct SSLv2 downgrade attacks against SSLv3 sessions via unspecified vectors.

Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2, when listening for incoming connections is enabled and allowing access to the "run" REST endpoint is allowed, allows remote authenticated users to execute arbitrary code via a crafted HTTP request.

Puppet before 2.6.18, 2.7.x before 2.7.21, and 3.1.x before 3.1.1, and Puppet Enterprise before 1.2.7 and 2.7.x before 2.7.2 allows remote authenticated users with a valid certificate and private key to read arbitrary catalogs or poison the master's cache via unspecified vectors.