We have discovered a security vulnerability (“AltNames Vulnerability”) whereby a malicious attacker can impersonate the Puppet master using credentials from a Puppet agent node. This vulnerability cannot cross Puppet deployments, but it can allow an attacker with elevated privileges on one Puppet-managed node to gain control of any other Puppet-managed node within the same infrastructure.
All Puppet Enterprise deployments are vulnerable, and Puppet open source deployments may be, depending upon their site configuration.
We believe this to be a serious risk, and we have confirmed this with security experts outside of Puppet Labs.
You can immediately protect yourself from this vulnerability with the following steps:
- Prevent your Puppet CA from issuing any more dangerous certificates
- Create a new DNS entry for the Puppet master
- Issue a new Puppet master certificate with its new DNS name
- Configure all Puppet agent nodes to contact the Puppet master at its new name
After the threat has been mitigated, we recommend that users upgrade their version of Puppet open source or Puppet Enterprise and migrate to a new certificate authority for a more complete remediation.
Puppet Labs has released a toolkit to help users protect themselves immediately and to automate a complete remediation process. We’ve also written supporting documentation that includes a walk-through of the toolkit and describes other methods of remediation.
The toolkit and documentation are available for download here:
Given the risk, Puppet Labs recommends customers and users remediate as quickly as their change management processes permit. Regarding the time required to remediate, in internal tests a 20 node deployment required just over an hour to remediate from start-to-finish, with most of that time spent waiting between Puppet runs.
For users requiring additional help with remediation, our Customer Service Engineers are available via our #puppet IRC channel and Puppet Users Google Group:
Finally, Puppet Labs has prepared a detailed FAQ to answer any additional questions:
Going forward, Puppet Labs will increase the scrutiny of and investment in the security of its products, and we look forward to hearing feedback on these projects from the community.
- The Puppet Labs Team
We have discovered a security vulnerability which can cause Puppet’s certificate authority (CA) to issue Puppet agent certificates capable of impersonating the Puppet master. These certificates will remain dangerous even after reconfiguring the Puppet master, but can be made safe by reconfiguring all Puppet agent nodes. This issue affects all Puppet Enterprise versions and every version of Puppet open source since 0.24.0.
If the Puppet master’s “certdnsnames” setting contains anything when an agent certificate is signed, those “certdnsnames” values will be added to the certificate’s Subject Alternative Name field. (The expected behavior prior to discovery of this bug was that these Subject Alternative Name values would only be added to Puppet master certificates.)
How the bug creates a vulnerability
When Puppet agent connects to a server purporting to be its Puppet master, it checks its legitimacy by comparing the certificate’s Subject: CN and Subject Alternative Name fields to the value of its own “server” setting. Thus, to an agent that uses one of the master’s alternate DNS names in its “server” setting, any agent certificate issued by a CA with “certdnsnames” will appear to belong to the Puppet master.
How the vulnerability can be exploited
An attacker who has obtained an agent private key and a certificate created with an improper Subject Alternative Name field can combine them with a man-in-the-middle attack of their choice to impersonate a site’s Puppet master, and can serve arbitrary catalogs to any agent node that trusts those DNS alt names. As Puppet agent typically runs as root, this effectively allows the attacker to gain full control of nodes managed by Puppet.
Limitations on exploits
- Attacks on this vulnerability are not possible unless the “certdnsnames” setting has been activated on the Puppet master at some point during the lifetime of the current CA certificate. Note that all installations of Puppet Enterprise have used the “certdnsnames” setting for at least part of their lifecycle.
- Attacks on this vulnerability require a private key and a signed certificate with the Puppet master’s DNS alt names. The likelihood of an attacker obtaining a certificate and a private key varies depending on certificate signing policies and the types of machines managed by Puppet. An attacker is least likely to obtain them at sites where all certificates must be signed manually and are only issued to servers with no root access; an attacker is most likely to obtain them at sites where certificates are autosigned and user laptops are managed by Puppet.
- This vulnerability is not relevant if Puppet is being used in a masterless configuration where each node compiles its own catalog.
- Normal limitations on man-in-the-middle attacks apply.
Puppet Enterprise Users
Distribution maintainers have been sent patches for all the versions of Puppet that are currently maintained in Fedora, EPEL, Debian, Ubuntu and Gentoo.
RubyGems has also been updated as part of our normal release process.