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!
End of Life von CentOS Linux 7 – Was bedeutet das für mich?
Der ein oder andere Admin wird sich vermutlich schon lange den 30. Juni 2024 im Kalender vorgemerkt haben, denn dann ist für CentOS Linux 7 das "End of Life" erreicht. Aber auch Benutzer von Red Hat Enterprise Linux 7 sollten sich Gedanken machen, denn auch dieses...
0 Kommentare
Trackbacks/Pingbacks