When making REST api calls, the puppet master takes YAML from an untrusted client, deserializes it, and then calls methods on the resulting object. A YAML payload can be crafted to cause the deserialization to construct an instance of any class available in the ruby process, which allows an attacker to execute code contained in the payload. I have fixes in tree in as 2.7.21-r1, 2.7.22, 3.2.1-r3 and 3.2.2. The only thing I see as remaining to be done is a fast stabilization of 2.7.21-r1 so we can remove the last vulnerable version from tree (2.7.21). Reproducible: Always
amd64 hppa ppc sparc x86 all arches, please stabilize puppet 2.7.21-r1 and 2.7.22.
Arch teams, please test and mark stable: =app-admin/puppet-2.7.21-r1 app-admin/puppet-2.7.22 Stable KEYWORDS : amd64 hppa ppc sparc x86 Also, who dropped SPARC from 3.*? I don't see a keyword request bug.
there's a dependency that needs to be worked out for sparc, bug 449184. I should update that stating I have 3.2.2 in tree now as well.
(In reply to Jeroen Roovers from comment #2) > Arch teams, please test and mark stable: > =app-admin/puppet-2.7.21-r1 > app-admin/puppet-2.7.22 > Stable KEYWORDS : amd64 hppa ppc sparc x86 > Only 2.7.22 is fine.
amd64 stable
ppc stable
Stable for HPPA.
x86 stable
how's sparc doing?
sparc stable
well, now that we are all stable we have another CVE :D I think we should close in favor of bug 481186
Thanks for you work Added to existing GLSA draft
This issue was resolved and addressed in GLSA 201308-04 at http://security.gentoo.org/glsa/glsa-201308-04.xml by GLSA coordinator Sergey Popov (pinkbyte).
CVE-2013-3567 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-3567): 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.
