A flaw was found in Puppet, where changes in the application lead to node declarations having increased access. An attacker can use this flaw to modify run facts and to retrieve different nodes of information when the stricthostnamechecking is false, and the node's catalog falls back to the default node.
Puppet Agent 1.10.x prior to 1.10.13, Puppet Agent 5.3.x prior to 5.3.7, and Puppet Agent 5.5.x prior to 5.5.2 on Windows only, with a specially crafted configuration file an attacker could get pxp-agent to load arbitrary code with privilege escalation.
In Puppet Agent 1.10.x prior to 1.10.13, Puppet Agent 5.3.x prior to 5.3.7, Puppet Agent 5.5.x prior to 5.5.2, Facter on Windows is vulnerable to a DLL preloading attack, which could lead to a privilege escalation.
Puppet Enterprise 2016.4.x prior to 2016.4.12, Puppet Enterprise 2017.3.x prior to 2017.3.7, Puppet Enterprise 2018.1.x prior to 2018.1.1, Puppet Agent 1.10.x prior to 1.10.13, Puppet Agent 5.3.x prior to 5.3.7, and Puppet Agent 5.5.x prior to 5.5.2, were vulnerable to an attack where an unprivileged user on Windows agents could write custom facts that can escalate privileges on the next puppet run. This was possible through the loading of shared libraries from untrusted paths.
Description of problem: I noticed that puppet may create several predictable files in /tmp, e.g.
/tmp/daemonout /tmp/puppetdoc.txt /tmp/puppetdoc.tex
There are also a lot more in the tests, but they may not be run in Fedora's F10 spec, and even more in the puppet source, e.g. for the dmg installation provider.
Version-Release number of selected component (if applicable): puppet-0.24.8-1.fc10
How reproducible: always
Steps to Reproduce: 1. grep -nR /tmp/ /usr/lib/ruby/siteruby/1.8/puppet
Actual results: Contains ruby code like: /usr/lib/ruby/siteruby/1.8/puppet/daemon.rb:33: File.open("/tmp/daemonout", "w") { |f|
Expected results: Should only report findings that are not executed, e.g. in comments or help information
Additional info: Current git seems to contain even more issues, e.g. lib/puppet/network/server.rb:25: File.open("/tmp/daemonout", "w") { |f|
In previous versions of Puppet Agent it was possible to install a module with world writable permissions. Puppet Agent 5.3.4 and 1.10.10 included a fix to this vulnerability.
Latest version: 8.18.0
Last updated 24 July 2024
In previous versions of Puppet Agent it was possible for the agent to retrieve facts from an environment that it was not classified to retrieve from. This was resolved in Puppet Agent 5.3.4, included in Puppet Enterprise 2017.3.4
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.
The changeuser 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 related to (1) the changeuser 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.
From puppet labs: Puppet agents with certnames of IP addresses can be impersonated
This affects Puppet 2.6.16 and 2.7.17
If an authenticated host with a certname of an IP address changes IP addresses, and a second host assumes the first host's former IP address, the second host will be treated by the puppet master as the first one, giving the second host access to the first host's catalog. Note: This will not be fixed in Puppet versions prior to the forthcoming 3.x. Instead, with this announcement IP-based authentication in Puppet < 3.x is deprecated.
Resolved in Puppet 2.6.17, 2.7.18
End of life: 4/30/2025, Latest version: 7.35.0
End of life: 4/30/2025, Latest version: 7.35.0