Linux-Magazin Clean Linux (Vorschau)

Titelthema
www.linux-magazin.de Kernelupdates 09/2013
44
Abbildung 2: Paradoxes auf einem per Ksplice gepatchten System: Die effektive Kernelversion ist höher als
die des eigentlich installierten Pakets.
messliche treiben und fallen daher ebenfalls
flach. Auf der Habenseite bleibt das
größere Zeitfenster bis zum unausweichlichen
Reboot, während aktuelle Sicherheitslücken
dennoch geschlossen sind.
Beispiel Sicherheitslücke
Die in CVE-2013-2094 [8] dokumentierte
Sicherheitslücke eignet sich hervorragend
zum Durchspielen der verschiedenen Ansätze
beim Kernelupdate. Der Einfachheit
halber beschränken sich die weiteren
Ausführungen auf Red Hat und Suse.
Das genügt für diesen Artikel, heißt aber
nicht, dass die anderen Distributionen
von dem Sicherheitsproblem verschont
geblieben sind.
Ausgangspunkt ist ein Fehler in der Funktion
»perf_swevent_init()«, durch den ein
lokaler Anwender Rootrechte erlangen
kann. Als im Mai 2013 ein passender
Exploit veröffentlicht wurde, waren 3.x-
Kernel betroffen, wenn sie älter als Version
3.8.9 waren. SLES 11 SP1 basierte
auf 2.6.32 und blieb damit außen vor.
RHEL 6, ebenfalls mit einem Kernel auf
2.6.32-Basis ausgestattet, hatte diesen
Bug allerdings rückportiert und stand
Listing 2: Patch für CVE-2013
-2094
01 $ diff ‐Nur linux‐2.6.32‐358.6.1.el6/
linux‐2.6.32‐358.6.2.el6/
02 ‐‐‐ linux‐2.6.32‐358.6.1.el6/kernel/events/core.c
2013‐03‐29 17:57:44.000000000 +0100
03 +++ linux‐2.6.32‐358.6.2.el6/kernel/events/core.c
2013‐05‐14 21:09:32.000000000 +0200
04 @@ ‐5198,7 +5198,7 @@
05
06 static int perf_swevent_init(struct perf_event
*event)
07 {
08 ‐ int event_id = event‐>attr.config;
09 + u64 event_id = event‐>attr.config;
10
11 if (event‐>attr.type != PERF_TYPE_SOFTWARE)
12 return ‐ENOENT;
dadurch unter Zugzwang. Analoges
galt für die RHEL-Klone oder den auf
3.0 beruhenden SLES 11 SP2. Eine recht
vollständige Liste der betroffenen Linuxe
findet sich unter [8].
Kurz nach Bekanntwerden der Sicherheitslücke
stellten die Distributoren aktualisierte
Pakete bereit, die einen neuen
Betriebssystemkern enthielten ([9],
[10]). Dank Open Source kann der kundige,
aber misstrauische Admin prüfen,
ob der Fehler auch tatsächlich behoben
ist (Listing 2). Im vorliegenden Fall gab
es keinen Grund zur Beanstandung, der
Fix war identisch mit der entsprechenden
Änderung im Vanilla-Kernel.
Damit war der Weg frei zum Offline-
Patchen der Systeme. Was sollten aber
Admins tun, wenn ein Reboot nicht so
schnell möglich war? Die Versorgung der
Ksplice-Benutzer erfolgte zügig [11]. Daneben
gibt es aber Systeme, für die weder
Ksplice noch Reboot in Frage kommen.
Nichtstun ist nur eine Option, wenn die
Sicherheit und Integrität der Systeme
absolut keine Rolle spielt. Selbst eine
Post-mortem-Analyse wäre bei dieser
Lücke nicht trivial, da das Ausnutzen
der betroffenen Kernelfunktion keinen
Eintrag im normalen Systemprotokoll erzeugt.
Selbst für diese Nachforschungen
braucht der Admin daher die Software
Systemtap [12] und muss Vorbereitungen
treffen [13].
Eine genaue Analyse des Problems zeigt,
dass sich das Sicherheitsrisiko auch ohne
Reboot und Ksplice minimieren lässt:
Das Setzen der Sysctl-Variablen »kernel.
perf_event_paranoid« auf den Wert »2«
schließt zwar nicht das Loch an sich,
macht aber den bekannten Exploit wirkungslos
(Abbildung 3). Damit sind die
entsprechenden Server wenigstens vor
Sikript-Kiddies und Attacken von Anfängern
sicher. Ein Reboot ist damit nicht
unmittelbar notwendig – aber nur aufgeschoben:
Im hier dargestellten Beispiel
empfiehlt es sich, die Syscontrol-Änderung
nach Aktivieren eines aktualisierten
Kernels rückgängig zu machen.
Das Ausliefern und Aktivieren neuer
Kernel auf laufenden Systemen ist nur
ein Teil der notwendigen Arbeit. Daneben
gibt es Systeme, die zu einem späteren
Zeitpunkt ein Linux bekommen oder
auf anderem Wege im Rechnerverbund
auftauchen. Es steht außer Frage, dass
solche Rechner ebenfalls den als aktuell
eingestuften Betriebssystemkern verwenden
sollten. Voraussetzung dafür ist, Kernelupgrades
in die Installationsprozesse
und ‐routinen zu integrieren.
Im einfachsten Fall genügt eine Patch-
Prozedur als Teil der Postinstallation. In
sicherheitskritischen Umgebungen kann
dies heißen, dass die Ausstattung des Servers
mit Linux in einem speziellen und
abgesicherten Netzwerk abläuft und die
Integration in die Produktion erst nach
vollständigem Patchen erfolgt.
Alternativ ist es möglich, ein bereits
angepasstes Image zur Installation zu
verwenden. Je nach Distribution und
Deployment-Methode sind dem aber
Grenzen gesetzt: Die von Suses Autoyast
verwendeten Images beispielsweise sind
per Prüfsumme und Signatur gesichert.
Eine – wenn auch gut gemeinte – Manipulation
ist ohne Herstellersupport nicht
möglich.
C-Library zum Schluss
Vorsichtige Admins dehnen die Kernelupgrade-Problematik
in Richtung C-Bibliothek
aus. Neben dem Betriebssystemkern
ist diese Library eine der tragenden
Säulen eines Linux-Systems. Technisch
gesehen zeigt sich die Situation hier aber
entspannter. Ein Austausch ist während
des Betriebs möglich. Sobald sich die Bibliothek
auf dem System befindet, steht
sie neu gestarteten Applikationen zur
Verfügung. Bereits laufende Anwendungen
verwenden allerdings bis zu einem
Neustart den alten Code.
Obwohl diese Inkonsistenz selbst beim
Co-Hosting von komplexen Anwendungen
keine Probleme machen sollte,
bleibt ein mulmiges Gefühl. Kommt
noch »nscd« als Caching-Software zum
Einsatz, ist dessen Neustart beim Glibc-
Update ebenfalls erforderlich. Die Erfahrung
zeigt außerdem, dass Kernelupdates