Lücke, Status, Maßnahme.

Am 6. August wurde eine Sicherheitslücke im Linux-Kernel veröffentlicht, zusammen mit einer funktionierenden Anleitung zum Ausnutzen. Sie steckt in der Virtualisierungs-Technik, die in jedem modernen Linux mitläuft — auch auf Servern, die überhaupt keine virtuellen Maschinen betreiben. Wer auf einem betroffenen Server ein normales Benutzerkonto besitzt oder eine Website übernommen hat, hätte sich darüber volle Administrator-Rechte verschaffen können. Wir haben die betroffene Technik am 7. August auf allen Servern abgeschaltet.

Was ist passiert?

Die Lücke steckt in KVM Virtualisierungs-Unterbau des Linux-Kernels. Er erlaubt es, auf einem Server weitere virtuelle Maschinen zu betreiben. , einem festen Bestandteil des Linux-Kernels. Durch einen Fehler in der Speicherverwaltung lässt sich der Kernel gezielt aus dem Tritt bringen. Dorthin führen zwei Wege: Auf Servern, die virtuelle Maschinen betreiben, kann jemand aus seiner eigenen Maschine ausbrechen und den darunterliegenden Server übernehmen. Auf geteilten Servern ohne Virtualisierung genügt ein gewöhnliches Benutzerkonto — auf mehreren Linux-Varianten steht die zugehörige Schnittstelle allen Nutzern offen, sodass auch eine gehackte Website den Angriff starten kann.

Betroffen sind nur Server, bei denen mehrere Bedingungen zusammenkommen: aktive verschachtelte Virtualisierung und ein AMD-Prozessor oder ein neuerer Intel-Prozessor. Nach diesen Kriterien haben wir unsere gesamte Flotte durchsucht.

Was wir getan haben

Der Flotten-Scan brachte einen Befund, der die Entscheidung leicht gemacht hat: Auf unseren Hosting-Servern läuft keine einzige virtuelle Maschine. Die angegriffene Technik wird dort also gar nicht gebraucht.

Wir haben sie deshalb am 7. August vollständig entladen und dauerhaft gegen erneutes Laden gesperrt — auf allen Servern, ausdrücklich auch auf denen, die nach der Analyse ohnehin nicht angreifbar waren. Beide Angriffswege sind damit geschlossen. Das geschah im laufenden Betrieb, ohne Neustart und ohne Unterbrechung. Auch die Backups laufen unverändert weiter: Der Dienst, der sie auf dem Server auslöst, nutzt diese Technik nicht.

Die endgültigen Kernel-Updates der Hersteller liegen erst für einen Teil der Systeme fertig vor. Wir spielen sie im regulären Wartungszyklus nach — solange die Technik abgeschaltet ist, läuft ein Angriff ins Leere.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter, es gab keine Unterbrechung.

Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust, lohnt dort die Prüfung, ob die Virtualisierung überhaupt gebraucht wird. Falls nicht, steht die Abschaltung als Ein-Zeilen-Lösung im unten verlinkten CloudLinux-Beitrag. Wo tatsächlich virtuelle Maschinen laufen, hilft nur das Kernel-Update des jeweiligen Herstellers.

Wie die Lücke technisch funktioniert und welche Kernel-Versionen sie schließen, steht in der Quelle unter diesem Eintrag.

In der ConfigServer Firewall — der Firewall, die auf einem Teil unserer Server den Zugang von außen regelt — wurden mehrere Schwachstellen gefunden. Über sie hätte ein Angreifer die höchste Rechtestufe auf dem Server erlangen können. Betroffen sind alle Fassungen bis einschließlich 16.20-1; einen Behelf gibt es laut Hersteller nicht, nur das Update. Wir haben die betroffenen Server am 6. August auf die fehlerbereinigte Fassung gebracht.

Was ist passiert?

Die Firewall entscheidet, welche Verbindungen einen Server überhaupt erreichen, und läuft dafür mit weitreichenden Rechten. Genau das macht Fehler an dieser Stelle heikel: Wer sie ausnutzt, steht nicht vor der Tür, sondern hat den Schlüssel zum ganzen System. Der Hersteller hat die Einzelheiten bewusst nicht veröffentlicht und keine CVE-Nummern vergeben — die Meldung beschränkt sich auf die Aufforderung, umgehend zu aktualisieren.

Was wir getan haben

Wir haben zuerst erhoben, welche Fassung auf welchem Server tatsächlich installiert ist, statt uns auf die automatische Aktualisierung zu verlassen. Auf dieser Grundlage haben wir die Server am 6. August auf die fehlerbereinigte Fassung 16.30-1 gebracht und den Stand anschließend erneut ausgelesen.

Was du tun musst

Nichts. Deine Firewall-Freigaben, Ports und Sperrlisten bleiben unverändert; das Update tauscht nur die Software selbst aus.

Die Hersteller-Meldung mit den betroffenen Fassungen findest du in der Quelle unter diesem Eintrag.

Mailcow, die Software hinter unseren Mailservern, hat Ende Juli ein ausdrückliches Sicherheits-Release veröffentlicht. Es schließt eine Lücke im mitgelieferten Webserver und härtet mehrere Wege in die Web-Oberfläche ab. Mailserver stehen naturgemäß offen im Internet, deshalb behandeln wir Updates an dieser Stelle mit Vorrang. Alle unsere Mailserver-Instanzen sind seit dem 5. August aktualisiert.

Was ist passiert?

Der Hersteller nennt als wichtigsten Punkt eine Schwachstelle im Webserver, über den die Mailcow-Oberfläche und die Weboberfläche für dein Postfach ausgeliefert werden. Daneben wurde der Spam-Filter auf eine neue Fassung gehoben und die Prüfung abgesichert, welche fremden Websites Anfragen an die Oberfläche stellen dürfen.

Was wir getan haben

Wir haben alle Mailcow-Instanzen am 5. August auf die neue Fassung aktualisiert und anschließend jede einzelne durchgesehen, ob alle Dienste sauber hochgekommen sind. Der Versand und Empfang lief während des Updates weiter.

Was du tun musst

Nichts. Deine Postfächer, Weiterleitungen und Filter sind unverändert, und deine Mail-Programme müssen nicht neu eingerichtet werden.

Welche Bestandteile das Release im Einzelnen erneuert, steht in der Quelle unter diesem Eintrag.

Plesk hat Anfang August mehrere Sicherheitsupdates veröffentlicht: ein größeres Release, kurz darauf zwei nachgeschobene Kleinst-Updates und eine neue Fassung der Erweiterung für die Zwei-Faktor-Anmeldung. Konkret benannt ist davon nur eine Lücke — sie betrifft die Echtheitsprüfung von E-Mails und ermöglichte Phishing zwischen Kunden desselben Servers. Alle Plesk-Server sind seit dem 5. August auf dem neuen Stand.

Was ist passiert?

Der eine dokumentierte Fehler steckte in DKIM Verfahren, das ausgehende E-Mails digital signiert. Empfänger können damit prüfen, ob eine Mail wirklich von der angegebenen Domain stammt. , dem Signatur-Verfahren für ausgehende E-Mails. Wer auf demselben Server einen Zugang hatte, konnte eine fremde Absenderadresse eintragen und bekam darauf trotzdem eine gültige Signatur. Eine so verschickte Mail sah für den Empfänger echt aus, obwohl sie es nicht war.

Die übrigen Updates deklariert Plesk lediglich als „Security improvements”, ohne Details und ohne CVE-Nummern. Wir behandeln solche Updates grundsätzlich als dringend: Das Plesk-Panel ist über seinen eigenen Port direkt aus dem Internet erreichbar, und bei der Erweiterung für die Zwei-Faktor-Anmeldung geht es um die Anmeldung selbst. Warum wir uns auf Hersteller-Changelogs nicht mehr verlassen, haben wir im Beitrag Sicherheitsupdates ohne Changelog beschrieben.

Was wir getan haben

Wir haben die Plesk-Server am 4. und 5. August auf die aktuelle Fassung gebracht — je nach Server auf 18.0.80 mit dem nachgereichten Update oder auf den gepflegten Stand des Vorgänger-Zweigs. Die Erweiterung für die Zwei-Faktor-Anmeldung haben wir ebenfalls aktualisiert. Mit dem großen Release sind zusätzlich veraltete Verschlüsselungs-Verfahren für signierte DNS-Zonen entfernt sowie die Web-Application-Firewall und der FTP-Dienst erneuert worden.

Was du tun musst

Nichts. Bestehende signierte DNS-Zonen laufen unverändert weiter, deine E-Mail-Einstellungen bleiben wie sie sind.

Wenn du dich bisher ohne zweiten Faktor in Plesk anmeldest, ist das ein guter Zeitpunkt, das zu ändern. Sprich uns an, dann richten wir die Zwei-Faktor-Anmeldung für deinen Zugang ein: +49 (0)2102 305 84 30.

Die vollständigen Änderungslisten der einzelnen Versionen findest du in den Quellen unter diesem Eintrag.

Das PHP-Projekt hat Ende Juli vier Sicherheitslücken geschlossen und für alle aktuellen Versionen neue Ausgaben veröffentlicht. Zwei davon sind aus ganz normalem Anwendungs-Code heraus erreichbar — also aus dem Shop, dem Redaktionssystem oder dem Plugin, das auf deinem Webspace läuft. Auf geteilten Servern ist das unmittelbar relevant. Wir haben die neuen PHP-Versionen am 3. August auf allen Servern eingespielt.

Was ist passiert?

Die schwerwiegendste der vier Lücken steckt in einer Rechenfunktion für sehr große Zahlen: Bei einem ungünstigen Aufruf schreibt PHP über den vorgesehenen Speicherbereich hinaus. Die zweite betrifft die Anbindung an PostgreSQL-Datenbanken — über eine besondere Schreibweise für Textwerte ließ sich aus der Zeichenkette ausbrechen und damit eine SQL-Injection Angriff, bei dem eigene Datenbank-Befehle in eine Anfrage eingeschleust werden. unterbringen. Beide setzen keinen besonderen Zugang voraus, sondern nur Code, der die betroffene Funktion benutzt.

Was wir getan haben

Wir haben die PHP-Versionen 8.2 bis 8.5 am 3. August auf den jeweils aktuellen Stand gebracht und die laufenden Prozesse anschließend neu gestartet, damit die neuen Versionen auch tatsächlich greifen. Deine Websites waren davon nicht spürbar betroffen.

Was du tun musst

Nichts, solange deine Anwendung auf PHP 8.2 oder neuer läuft — das ist bei den allermeisten Installationen der Fall.

Anders sieht es aus, wenn du noch PHP 7.4, 8.0 oder 8.1 einsetzt: Diese Versionen bekommen vom PHP-Projekt keine Sicherheitsupdates mehr, die oben genannten Lücken bleiben dort also offen. Wir halten sie aus Kompatibilitätsgründen weiterhin bereit, empfehlen aber den Wechsel. Die PHP-Version lässt sich in Plesk pro Domain umstellen; wenn du dabei Unterstützung brauchst, melde dich unter +49 (0)2102 305 84 30.

Welche Funktionen im Einzelnen betroffen sind, steht in der Quelle unter diesem Eintrag.

Am 28. Juli wurde eine neue Sicherheitslücke im Linux-Kernel veröffentlicht, zusammen mit einer funktionierenden Anleitung zum Ausnutzen. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, könnte sich darüber volle Administrator-Rechte verschaffen. Die endgültigen Kernel-Updates der Hersteller sind noch in Arbeit. Unsere Server sind trotzdem bereits dagegen abgesichert.

Was ist passiert?

Die Lücke steckt in Open vSwitch Netzwerk-Modul im Linux-Kernel, das virtuelle Netzwerke zwischen Servern verbindet. Auf Webservern normalerweise ungenutzt. , einem Kernel-Modul, das in fast jedem aktuellen Linux enthalten ist. Das Tückische: Das Modul muss gar nicht in Benutzung sein, seine bloße Anwesenheit reicht für einen Angriff. Deshalb sind praktisch alle gängigen Linux-Systeme betroffen, von AlmaLinux über CloudLinux bis Ubuntu.

Was wir getan haben

Unsere Server brauchen dieses Modul nicht. Wir haben es deshalb noch am Tag der Veröffentlichung auf allen Systemen deaktiviert, ohne Neustart und ohne Unterbrechung. Damit läuft der Angriff ins Leere, bevor die Hersteller ihre endgültigen Kernel-Updates fertig haben.

Was du tun musst

Nichts. Deine Anwendungen laufen unverändert weiter, es gab keine Unterbrechung. Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust, solltest du dort handeln: Die Ein-Zeilen-Mitigation zum Deaktivieren des Moduls steht im unten verlinkten CloudLinux-Beitrag.

Die vollständige technische Analyse findest du in den Quellen unter diesem Eintrag.

Am 22. Juli wurde eine Sicherheitslücke im Linux-Kernel veröffentlicht, die dort seit neun Jahren unentdeckt geschlummert hat. Wer auf einem betroffenen Server ein normales Benutzerkonto hat, könnte darüber geschützte Systemdateien überschreiben und volle Administrator-Rechte übernehmen. Besonders unangenehm: Die Manipulation übersteht Neustarts und ist in den System-Protokollen praktisch unsichtbar. Unsere Server sind seit dem 24. Juli gepatcht.

Was ist passiert?

Die Lücke steckt im XFS-Dateisystem Dateisystem, das viele Linux-Server zum Ablegen und Verwalten von Dateien nutzen. und existiert seit 2017 in praktisch jedem Linux-Kernel. Über eine Race-Condition Fehler, bei dem zwei gleichzeitige Vorgänge sich in die Quere kommen und einen unerwarteten Zustand hinterlassen. beim gleichzeitigen Schreiben kann ein Angreifer mit normalem Benutzerkonto jede lesbare Datei im Dateisystem verändern, auch solche, die das System eigentlich schützt. Damit lassen sich Root-Rechte übernehmen, selbst wenn zusätzliche Sicherheits-Schichten wie SELinux aktiv sind.

Was wir getan haben

Wir haben die Kernel-Fixes am 24. Juli ausgerollt, zwei Tage nach der Veröffentlichung. Auf Servern mit aktivem Livepatching kam der Fix ohne Neustart und ohne Unterbrechung; die übrigen Systeme haben wir in einem koordinierten Wartungsfenster neu gestartet. Den Verlauf haben wir über die Status-Seite begleitet.

Was du tun musst

Nichts. Der Rollout ist abgeschlossen, deine Anwendungen laufen unverändert weiter. Wenn du eigene Linux-Maschinen außerhalb unserer Plattform betreust, gilt dort: nicht nur das Kernel-Update einspielen, sondern bei Verdacht auch prüfen, ob wichtige Systemdateien unverändert sind, denn die Manipulation übersteht Neustarts. Unabhängig davon sichern unsere täglichen Plattform-Backups den Stand vor dem Veröffentlichungs-Datum, falls eine Wiederherstellung nötig würde.

Die vollständige technische Analyse mit allen Kernel-Details findest du in den Quellen unter diesem Eintrag.

Mitte Juli wurden zwei schwerwiegende Lücken im Kern von WordPress bekannt. Über eine Schnittstelle, die jede WordPress-Installation von Haus aus mitbringt, lässt sich fremder Programmcode ausführen — ganz ohne Anmeldung, ohne Passwort, ohne Benutzerkonto. Die Lücke wurde von Angreifern sofort in großem Stil ausgenutzt. Wir haben den Angriffsweg am 20. Juli auf allen Servern blockiert.

Was ist passiert?

Betroffen ist die REST-Schnittstelle Schnittstelle, über die WordPress Daten an andere Programme ausliefert und entgegennimmt — etwa für Apps oder gekoppelte Systeme. von WordPress, genauer ein Bereich, der mehrere Anweisungen in einer einzigen Anfrage bündelt. Über ihn ließ sich einerseits die Datenbank auslesen und andererseits eigener Code auf dem Server ausführen. Weil dafür kein Zugang nötig war, genügte für einen Angriff das bloße Wissen um die Adresse der Website.

Genau das macht die Lücke für geteiltes Hosting so unangenehm: Auf einem Server liegen viele WordPress-Installationen, die von unterschiedlichen Agenturen und Betreibern gepflegt werden — und eben nicht alle gleich schnell.

Was wir getan haben

Wir haben am 20. Juli eine Sperre auf Serverebene aktiviert, die Anfragen an den betroffenen Bereich abfängt, bevor sie WordPress überhaupt erreichen. Sie wirkt unabhängig davon, ob die jeweilige Installation schon aktualisiert wurde, und schützt damit auch Websites, deren Betreuung gerade im Urlaub ist.

Diese Sperre ersetzt das Update aber nicht. Sie schließt den bekannten Angriffsweg, und sie schützt nur dort, wo unsere Server davorstehen.

Was du tun musst

Aktualisiere deine WordPress-Installation auf Version 7.0.2 oder neuer. Wenn du die automatischen Updates für den WordPress-Kern aktiviert hast, ist das mit hoher Wahrscheinlichkeit bereits geschehen — ein Blick ins Dashboard schafft Klarheit.

Wichtig ist das aus zwei Gründen: Das Update ist die eigentliche Behebung, und es wirkt auch dort, wo unsere Sperre nicht greift — auf deinem Testsystem, in der lokalen Entwicklungsumgebung oder auf Installationen, die woanders liegen. Bist du dir bei einer deiner Websites unsicher, ruf uns an: +49 (0)2102 305 84 30.

Welche Anfragen im Einzelnen betroffen sind, steht in der Quelle unter diesem Eintrag.

Im Juli sind kurz hintereinander vier Sicherheitslücken im Linux-Kernel bekannt geworden, die alle auf dasselbe hinauslaufen: Aus einem normalen Benutzerkonto lassen sich volle Administrator-Rechte machen. Für die bekannteste, „GhostLock”, kursierte schon zur Veröffentlichung eine fertige Angriffs-Anleitung. Ein einziges Kernel-Update schließt alle vier Lücken auf einmal. Unsere Server laufen seit dem 9. Juli mit dem abgesicherten Kernel, die Neustarts sind abgeschlossen.

Was ist passiert?

Die vier Lücken (GhostLock, Bad Epoll, pedit COW, DirtyClone) stecken in unterschiedlichen Teilen des Kernels, GhostLock zum Beispiel seit rund 15 Jahren. Für Multi-Tenant-Umgebungen Server, auf denen mehrere Kunden nebeneinander laufen, wie beim geteilten Webhosting. ist diese Art Lücke die kritischste Kategorie: Als Einstiegspunkt reicht ein gekapertes CMS-Plugin in einem einzelnen Kunden-Account, danach stünde der ganze Server offen.

Was wir getan haben

Wir haben das Kernel-Update am 9. Juli auf allen Servern eingespielt, wenige Stunden nach der Veröffentlichung. Weil die Fixes im Kernel sitzen, brauchte es Neustarts; die haben wir noch am selben Tag koordiniert durchgeführt. Ganz glatt lief es nicht: Auf einem Teil der Systeme wurde das Update zunächst unvollständig installiert, einige Webseiten zeigten vorübergehend Fehler. Zwei Nachkorrekturen später lief alles sauber, den Verlauf haben wir live auf der Status-Seite dokumentiert.

Was du tun musst

Nichts. Deine Anwendung läuft auf dem gepatchten Kernel weiter. Zwischen Veröffentlichung und Neustart lag ein kurzes Zeitfenster, in dem die Lücken theoretisch ausnutzbar waren; Hinweise auf eine Ausnutzung auf unseren Systemen haben wir nicht. Auf Managed Servern und Clustern haben ohnehin nur du und unser Team Shell-Zugriff. Eigene Linux-Maschinen außerhalb unserer Plattform: Kernel-Update einspielen und neu starten.

Die technischen Details stehen in den verlinkten CloudLinux-Beiträgen unter diesem Eintrag.