Götzenbild Uptime
In der Welt der Unix-verwandten Betriebssysteme gibt es einen weit verbreiteten Kult um die Uptime von Servern, die als ein mystischer Indikator für die Stabilität und Zuverlässigkeit der Systeme gilt. Dabei bedeutet eine hohe Uptime eigentlich nichts anderes als dass das System schon lange kein Kernel-Update mehr gesehen hat.
Bei auf Stabilität ausgelegten Distributionen wie RHEL oder CentOS bringen Kernel-Updates in erster Linie Bugfixes und wenn überhaupt nur selten neue Features. Gerade die Bugfixes haben es aber oft in sich, deswegen verfolgen wir z.B. die CentOS-annouce Mailingliste auf der Updates angekündigt werden sobald sie für die Mirror bereit stehen, zusammen mit einer Übersicht über die Veränderungen die mit den Updates kommen. Was den Kernel angeht sind das häufig:
- Updates die Sicherheitslücken schließen
- etwa Lücken über die Systemuser ihre Rechte auf dem System ausweiten können
- oder Lücken über die das System zum Absturz gebracht werden kann
- oder Lücken die sich für Denial-of-Service-Attacken nutzen lassen
- Updates die Fehler fixen
- durch die Software abstürzen kann
- durch die Software Fehler machen kann
- oder durch die Software schlicht nicht oder nur unzuverlässig funktioniert
Sicherheitslücken über die sich jemand von Außen Zugang zum System verschaffen kann sind im Kernel selten geworden.
Dabei werden durchaus nicht alle Fehler auch dauerhaft und zufriedenstellend geschlossen, bei CentOS 6 plagt uns zum Beispiel seit Jahren ein wiederkehrender Bug im Zusammenspiel von ASPM mit Netzwerkkarten, der dazu führen kann dass der Kernel beim Booten die Netzwerkhardware nicht findet und nicht aktiviert. Da wir es irgendwann leid waren das immer wieder auszutesten, booten wir nicht virtualisierte CentOS 6 Systeme inzwischen routinemäßig mit pcie_aspm=off als Kernel-Parameter.
Gleichzeitig gibt es eine Menge Updates die Lücken schließen, die uns sehr wahrscheinlich nicht betreffen. In letzter Zeit gab es zum Beispiel häufiger Lücken im SCTP-Stack des Kernels, den wir aber auf unseren Servern nicht nutzen. (SCTP ist vereinfacht ausgedrückt eine Alternative zu TCP und UDP die im Vergleich zu beiden viele interessante Features bietet. Wir haben durchaus schonmal drüber nachgedacht das bei einigen Diensten auszuprobieren, da die meisten Heimrouter SCTP jedoch nicht durchlassen, läuft diese Idee auf Sparflamme.) Diese Lücken werden vermutlich gerade gefunden, weil SCTP im Zusammenhang mit SS7 benutzt wird und es seit ein paar Jahren mehrere Projekte im Linux-Umfeld gibt, die mit Telephonie und Mobilfunk zu tun haben. Und spätestens seit den Snowden Veröffentlichungen scheinen jetzt auch mehr Leute mit Sorge auf den SCTP-Code zu schauen.
Aber betreffen uns solche Lücken wirklich nicht? Die Codepfade zu den fehlerhaften Routinen sind ja trotzdem vorhanden, auch wenn sich weder die Entdecker der Lücke noch diejenigen die den Patch geschrieben haben vorstellen können, wie auf einem System ohne eine bestimmte Konfiguration dieser Codepfad eingeschlagen werden könnte. – Wer aber mal ein kniffligeren Bug suchen musste und sich eines Debuggers bemüht hat weiß, dass es mitunter vorkommt, dass Software die seltsamsten Codepfade einschlägt. Also können wir wirklich davon ausgehen, dass uns Fehler und Sicherheitslücken nicht betreffen, wenn die mit dem Update gelieferte Einschätzung des Bugs das sagt?