CVE-2011-3872 FAQ

What is the security vulnerability?

A bug in a configuration file setting causes the release of SSL certificates able to impersonate a Puppet master. Specifically, if the Puppet master setting "certdnsnames" is explicitly set in puppet.conf, then any agent certificate issued by the Puppet CA will contain the master's DNS names. Thus, anyone in possession of a certificate signed by the CA could impersonate the Puppet master and control any agent node that trusts one of the leaked DNS names. Under normal conditions, local root privileges are required to access such a certificate.

Can I tell if I’m not vulnerable at all?

If you have never ever set the "certdnsnames" setting in your puppet.conf file, then you are not vulnerable, so long as you don’t turn it on before upgrading your Puppet master.

What risk does this create? How would an attacker exploit this vulnerability?

A malicious attacker with root access to a Puppet agent can impersonate a Puppet master, and could "snoop" Puppet traffic and mount a "man–in–the–middle" attack to attain root access on all Puppet–managed nodes within that environment.

How serious is it? To what type of attack is my infrastructure exposed?

A malicious attacker fully exploiting this vulnerability could take control of all systems which are managed by Puppet in the user’s environment.

How quickly do I need to address this vulnerability?

Puppet Labs recommends customers and users take action as soon as possible to remediate this vulnerability. Download the remediation toolkit here.

What versions of Puppet open source and Puppet Enterprise are affected?

  • Puppet open source 0.24.x and later. (The puppet.conf configuration setting "certdnsnames" is not explicitly set in any version of Puppet open source.)
  • For Puppet Enterprise, all versions (1.0, 1.1, 1.2) are affected. (The puppet.conf configuration setting "certdnsnames" is explicitly set in all versions of Puppet Enterprise.)

Will upgrading Puppet fix the vulnerability?

No. If any certificates with the master's DNS names have been released to agent nodes, they will remain dangerous until your agent nodes have been reconfigured.

What do I need to do?

Download the remediation toolkit here. It contains documentation and tools to fully remediate the vulnerability.

What versions of Puppet will the remediation toolkit work with?

It works with all versions of Puppet Enterprise, and a solution for a webrick Puppet master, versions 2.6.x or 2.7.x, has been provided.

Is the remediation toolkit proprietary?

No, it is licensed under the Apache 2.0 license, and source can be found here. We encourage users to fork it and adapt it for other deployment architectures.

What does the Puppet Labs remediation toolkit do?

At a high level, the remediation toolkit will help you:

  • Remove the "certdnsnames" entry
  • Create a new DNS entry for the Puppet master
  • Issue a new Puppet master certificate with its new DNS name
  • Migrate all Puppet agent nodes to contact the Puppet master at its new name
  • Optionally, and at your convenience, replace the Puppet CA so you can resume use of your preferred DNS name.

How long does remediation take?

In internal tests, the vulnerability was remediated from 20 Puppet–managed nodes and 1 Puppet Master server in just over an hour, with most of that time waiting for nodes to perform their regular Puppet run.

Has Puppet Labs tested this solution?

Yes. This remediation solution has been tested on all supported OS platforms for Puppet Enterprise masters and agents.

How can I get additional help if I need it?

Our Customer Service Engineers are available to help via our #puppet IRC channel and our Puppet Users Google Groups.

I did not purchase a support contract with Puppet Labs, can I still get help?

Yes. Our Customer Service Engineers are available to help via our #puppet IRC channel and our Puppet Users Google Groups.

I did not purchase Puppet Enterprise, can I still get help?

Yes. Our Customer Service Engineers are available to help via our #puppet IRC channel and our Puppet Users Google Groups.

I signed up to receive the Puppet Enterprise 2.0 release, does it have this vulnerability?

No. We delayed work on Puppet Enterprise 2.0 to focus on remediating this vulnerability. In the process, we fixed this vulnerability in Puppet Enterprise 2.0.

I signed up to receive the Puppet Enterprise 2.0 release, but didn’t receive the email with links to the software on 10/21—when will it be available?

As a result of our focus on addressing this vulnerability, Puppet Enterprise 2.0 availability has been delayed until Monday, November 14. If you signed up for Puppet Enterprise 2.0, you will receive an email on that day with links to the software.

I see Puppet Enterprise 1.2 is still available for download; does it have this vulnerability?

Puppet Enterprise 1.2 has been remediated and, as of 05:00 PDT Monday, October 24, no longer has this vulnerability. Specifically, Puppet Enterprise releases from version 1.2.4 onward are protected.

When did Puppet Labs discover this vulnerability?

Monday, October 10.

How did Puppet Labs discover this vulnerability?

One of our engineers was working with and reviewing the SSL certificate handling code.

Has Puppet Labs submitted this to the CVE list?

Yes. It is listed as CVE-2011-3872.

Why didn’t Puppet Labs announce this earlier?

Puppet Labs subscribes to the principle of Responsible Disclosure (definition here), which allows time for the software developer to provide a remedy to the vulnerability prior to disclosure.

Has any attacker exploited this vulnerability?

Not that we are aware.

What steps is Puppet Labs taking to mitigate security vulnerabilities like this in future releases?

Puppet Labs will retain a third party security consultancy to review our products for vulnerabilities for every major release.