Vorausgeschickt für alle Ungeduldigen: einfach mal wieder upgraden. Mit 2.6.14 oder 2.7.11 schläft sich’s besser. PuppetLabs betreibt nämlich eine vorbildliche Responsible disclosure-Policy, Sicherheitslöcher werden also nach einer kurzen Schonfrist in der das Loch geschlossen werden muss, publik gemacht.
Mit der zunehmenden Verbreitung von Puppet machen sich auch immer mehr Leute Gedanken über dessen Sicherheit – was zwangsläufig zur Folge hat, dass auch mehr Probleme aufgedeckt werden. Neben der Frage, wie man Puppet-Master und -Agent generell vor Angriffen von “außen” schützen kann, sollte man sich immer auch fragen, wie man sich “intern” bestmöglich absichern kann. Ein böser Agent könnte z.B. versuchen, sich über einen Man-in-the-middle-Angriff als Puppet-Server auszugeben. Das geht zwar nicht mal eben einfach so, es gab aber bereits einen Bug in Puppet, der hierzu ausgenutzt werden konnte: CVE-2011-3872 – AltNames Vulnerability.
Eine weitere interessante Angriffsfläche sind von Puppet verwaltete File-Ressourcen, auf welche normale Benutzer Schreibzugriff haben. Entsprechende Sicherheitsprobleme z.B. in Bezug auf die erlauben SSH-Keys (CVE-2011-3870 – SSH Auth Key Local Privilege Escalation) oder Kerberos-Berechtigungen (CVE-2012-1054 – K5login Local User Privilege Escalation, CVE-2011-3869 – K5login Local Privilege Escalation).
Gefährlich kann auch das Aufrufen von Skripts oder Binaries sein, welche einem lokalen Benutzer gehören – er könnte damit root werden: CVE-2012-1053 – Local Group Privilege Escalation. Schwerwiegend war auch CVE-2011-3871 – Puppet Resource Local Privilege Escalation, damit konnte man als lokaler Benutzer unabhängig von den verwalteten Ressourcen einen vom Puppet-Agent verwalteten Rechner übernehmen.
Einige der Probleme hätten nicht passieren dürfen, aber wer macht schon keine Fehler. Andere hingegen sind kniffliger, zu Lernzwecken interessant anzusehen und auch (wie im Fall der TOCTOU-Probleme) nicht immer einfach zu lösen. PuppetLabs hat jedenfalls alle Bugs vorbildlich zeitnah beseitigt und mittlerweile ein paar Design-Probleme auch gleich an der Wurzel angepackt. Bravo, weiter so!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.