Puppet Labs just sent an advisory out -- copying text:
There has been a vulnerability discovered in Puppet (CVE-2011-3848).
# Recommended Action #
Puppet Labs has an updated version of Puppet available at the
The fixed versions are 2.6.10 in the 2.6.x branch and 2.7.4 in the
The hotfixes page also contains updated Puppet packages for Puppet
Enterprise versions 1.0, 1.1 and 1.2.x.
Puppet Labs has been coordinating with Debian, Ubuntu, EPEL and
OpenSuSE maintainers. We expect new packages (with a patch backported
in many cases) to be released as soon as possible.
Separate release announcements for Puppet 2.6.10 and 2.7.4 are pending.
# Explanation #
Kristian Erik Hermansen <firstname.lastname@example.org> reported that
an unauthenticated directory traversal could drop any valid X.509
Certificate Signing Request at any location on disk, with the
privileges of the Puppet Master application. This was found in the
2.7 series of Puppet, but the underlying vulnerability existed in
earlier releases and could be accessed with different hostile inputs.
There are also some additional quirks of input handling that make it
easier to obfuscate the input.
This exploits an input quirk where the "key" in the URI is
double-decoded; this would also work for a single URI-encoded input
On 2.6 this is ignored, but the CN in the Subject of the CSR is used
in the same way, and could be exploited to drop the CSR content at an
arbitrary location on disk. The suffix ".pem" is always appended
to the location.
In the 0.25 series the same CN-based injection can occur, as the
underlying flaw still exists.
In all cases this requires that the input data can be loaded through
OpenSSL as a CSR, and will fail before touching disk if that is not
Be aware that both double-encoded and single-encoded URI patterns will
work, equivalently, in Puppet 2.7. No URI decoding is done on the CN
of the CSR Subject.
# Commit message for fix #
I have included patches for the 0.25.x, 2.6.x, and 2.7.x branches.
Author: Daniel Pittman <email@example.com> Date: Sat Sep
24 12:44:20 2011 -0700
Resist directory traversal attacks through indirections.
In various versions of Puppet it was possible to cause a directory
traversal attack through the SSLFile indirection base class.
This was variously triggered through the user-supplied key, or
the Subject of the certificate, in the code.
Now, we detect bad patterns down in the base class for our
indirections, and fail hard on them. This reduces the attack
surface with as little disruption to the overall codebase as
possible, making it suitable to deploy as part of older, stable
versions of Puppet.
In the long term we will also address this higher up the stack,
to prevent these problems from reoccurring, but for now this
Huge thanks to Kristian Erik Hermansen <firstname.lastname@example.org>
for the responsible disclosure, and useful analysis, around
Signed-off-by: Daniel Pittman <email@example.com>
# Note for 0.25 users #
If you're still shipping/using 0.25, we have supplied a patch to
several distro maintainers that
applies cleanly to our git tree, but will not be releasing any
upstream source of it.
If you have any questions or need additional clarification on
anything, please respond to firstname.lastname@example.org.
Thanks, Michael Stahnke
Release Manager -- Puppet Labs
2.6.10 and 2.7.4 in cvs.
please mark stable =app-admin/puppet-2.6.10.
(In reply to comment #1)
> 2.6.10 and 2.7.4 in cvs.
> please mark stable =app-admin/puppet-2.6.10.
Great, thank you.
Arches, please test and mark stable:
Target keywords : "amd64 hppa ppc sparc x86"
Please continue in bug 385149.
=app-admin/puppet-2.6.11 stabilization completed in bug 385149. GLSA Vote: yes.
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.
On existing GLSA draft.
This issue was resolved and addressed in
GLSA 201203-03 at http://security.gentoo.org/glsa/glsa-201203-03.xml
by GLSA coordinator Sean Amoss (ackle).