Announce: New Puppet releases due to four security issues [critical security updates]

Skip to first unread message

Michael Stahnke

Sep 30, 2011, 6:02:44 PM9/30/11
Announce: New Puppet releases due to four security issues

Following the security vulnerability announced yesterday (CVE-2011-3848),
Ricky Zhou (<>) alerted us to an unrelated
vulnerability. Our subsequent code audit uncovered three more vulnerabilities,
and we have now fixed all four of these new issues. (It's been a busy week.)

We have released the following updated versions of Puppet to fix these

* 2.7.5
* 2.6.11

system resulted in information about these issues leaking to a public list prior to this disclosure. Official announcements of these releases are forthcoming momentarily, and the new versions can be downloaded at: * * PUPPET ENTERPRISE USERS can download hotfix packages for PE versions 1.0, 1.1, and 1.2.x at: * 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 very soon, and downstream packagers may also release Puppet 0.25.x packages that include these fixes. Thank you for your patience, and as always, please report security vulnerabilities to Vulnerability Details --------------------- The following vulnerabilities have been discovered and fixed: * CVE-2011-3870, a symlink attack via a user's SSH authorized_keys file * CVE-2011-3869, a symlink attack via a user's .k5login file * CVE-2011-3871, a privilege escalation attack via the temp file used by the puppet resource application * A low-risk file indirector injection attack SSH Authorized Keys Symlink -- CVE-2011-3870 (Critical) ---------------------- Type: Local Privilege Escalation Credit to Ricky Zhou <> for the discovery and fix. A TOCTOU (time-of-check-to-time-of-use) race vulnerability was present in the ssh_authorized_key type (and theoretically in the Solaris and AIX providers). When the target file and directory did not exist, each of them would be created as root and later chowned to the user. This made it possible to replace either one with a symlink to an arbitrary file, which would then become owned by that user. This would allow local privilege escalation to root through standard TOCTOU attack techniques. Unlike most Puppet types, this risk was exacerbated by the nature of the ssh_authorized_key type, which almost always manages data in directories controlled by unprivileged (and likely untrusted) users. This issue has been fixed by making all file operations happen with the privileges of the target user, ensuring that a user can cause no harm beyond their normal capabilities on the system. k5login attach -- CVE-2011-3869 (Critical) ---------------------- Type: Local Privilege Escalation The k5login type is typically used to manage a file in the home directory of a user; the explicit purpose of this file is to allow access to other users. This type previously wrote to the target file directly, as root, without doing anything to secure the file. If the .k5login file was replaced with a symlink, this would allow the owner of the home directory to replace any file on the system, including the .k5login file of a more privileged user, with the “correct” content of their own file. This issue was discovered during a code audit following the report of the ssh_authorized_key vulnerability, and the fix was very similar. Predictable temp file using RAL -- CVE-2011-3871 (Critical) ---------------------- Type: Local Privilege Escalation Previously, puppet resource in --edit mode used an extremely predictable file name, which would persist on human timescales, could be known well ahead of creation, and would be run as the invoking user upon completion of the operation. This could be exploited to trick the invoking user into editing an arbitrary target file, or running arbitrary Puppet code. As puppet resource is not very effective when not run as root, the potential effect of an attack was quite high. File indirector injection (Low risk) ---------------------- The indirector/file.rb terminus base class trusted the request key and used it as part of the pathname, like the YAML and SslFile terminus base classes did. The mitigating factor in this vulnerability was that this code was unused except in one unit test, which has been rewritten.

If you have any questions or need additional clarification on anything, please respond to

Michael Stahnke
Release Manager - Puppet Labs

Reply all
Reply to author
0 new messages