Vorankündigung für ein hochkritisches Sicherheitsupdate am 28. März für Drupal 6, 7 und 8 [PSA-2018-001]
Neben anderen Sicherheits-Updates – die gestern erschienen – gab es auf drupal.org eine Ankündigung zu einem bevorstehenden hochkritischen Sicherheits-Update, das für Drupal in den Versionen 7.x, 8.3.x, 8.4.x, and 8.5.x am 28. März zwischen 18:00 - 19:30 UTC (d.h. 20:00 und 21:30 Uhr mitteleuropäischer Zeit) erscheinen wird.
Edit: Zeit angepasst von UTC+1 auf UTC+2 (wegen Sommerzeit. Die wurde nicht vergessen, man sollte sich aber für den Tag der Umstellung nicht auf Wikipedia verlassen).
Update: Drupal 6 ist auch betroffen. Die Drupal 6 LTS-Version bekommt ca. eine Stunde nach D7/D8 ebenfalls das Update: https://www.drupal.org/project/d6lts/issues/2955130
Auszug aus der offiziellen Ankündigung (deutsche Übersetzung) auf der Node-Page (in Teaser-Asicht auf Titel oder "Weiterlesen" klicken).
Es wird ein Sicherheitsupdate von Drupal 7.x, 8.3.x, 8.4.x und 8.5.x am 28. März 2018 zwischen 18:00 und 19:30 UTC geben, genau eine Woche nach der Veröffentlichung dieses Dokuments, in der eine sehr kritische Sicherheitslücke behoben wird. Das Drupal Security Team fordert Sie dringend auf, zu diesem Zeitpunkt Zeit für die wichtigsten Updates zu reservieren, da Exploits innerhalb von Stunden oder Tagen entwickelt werden könnten. Ankündigungen zu Sicherheitsupdates werden auf der Drupal.org Sicherheitshinweisseite angezeigt.
Obwohl Drupal 8.3.x und 8.4.x nicht mehr unterstützt werden und wir normalerweise keine Sicherheitsupdates für nicht mehr unterstützte Versionen bereitstellen, bieten wir angesichts des möglichen Schweregrads dieses Problems auch gefixte Versionen für 8.3.x und 8.4.x für Websites, die noch nicht auf Version 8.5.0 aktualisiert werden konnten. Das Drupal Sicherheitsteam empfiehlt dringend Folgendes:
- Sites unter 8.3.x sollten sofort auf die Version 8.3.x aktualisieren, die in der Advisory bereitgestellt wird, und dann im nächsten Monat auf die neueste 8.5.x-Sicherheitsversion aktualisieren.
- Sites auf 8.4.x sollten sofort auf die Version 8.4.x aktualisieren, die in der Advisory bereitgestellt wird, und dann planen, im nächsten Monat auf die neueste 8.5.x-Sicherheitsversion zu aktualisieren.
- Sites auf 7.x oder 8.5.x können sofort aktualisiert werden, wenn das Advisory mit dem normalen Verfahren veröffentlicht wird.
Der Sicherheitshinweis listet die entsprechenden Versionsnummern für alle drei Drupal 8 Zweige auf. Auf der Aktualisierungsberichtsseite Ihrer Website wird die Version 8.5.x empfohlen, auch wenn Sie 8.3.x oder 8.4.x verwenden. Wenn Sie jedoch vorübergehend auf den bereitgestellten Backport für die aktuelle Version Ihrer Site aktualisieren, stellen Sie sicher, dass Sie schnell und ohne die möglichen Nebenwirkungen ein Minor update durchführen können.
Das Sicherheitsteam oder eine andere Partei ist nicht in der Lage, weitere Informationen zu dieser Sicherheitslücke zu veröffentlichen, bis die Ankündigung erfolgt ist. Die Ankündigung wird unter https://www.drupal.org/security, über Twitter und in E-Mails für diejenigen veröffentlicht, die unsere Mailinglist abonniert haben. (...)
- Anmelden oder Registrieren um Kommentare zu schreiben
Bitte nicht auf die leichte Schulter nehmen
am 22.03.2018 - 12:05 Uhr
Ich hoffe, es können sich noch alle an das so genannte "Drupalgeddon" 2014 erinnern. Seinerzeit gab es leider keine so intensive Warnung – vor allem nicht so früh.
Mein Tipp:
Im Zweifel nehmt Websites, die Ihr nicht sofort updaten/patchen könnt, am Mittwoch Abend vom Netz. Damit meine ich nicht den Maintenance-Mode, sondern eine Methode, bei das PHP der Drupal-Systeme nicht mehr ausgeführt werden kann.
Beim Drupalgeddon gab es ab 3 Stunden nach Veröffentlichung des Sicherheitsupdates automatisierte Angriffe. Das könnte diesmal auch schneller gehen!
Es geht wie bei den meisten Viren und Trojanern für Desktop-Rechner nicht unbedingt darum, daß sich ein Hacker für Eure Website interessiert. Beim Drupalgeddon wurden Drupal-Websites in großem Stil z.B. in Spam-Bots verwandelt usw. Die individualisierten Angriffe gibt es dann aber natürlich auch, siehe Panama-Papers als berühmtes Beispiel.
# DrupalCenter-Moderator # https://www.drupal.org/u/c-logemann
# CTO der Nodegard GmbH: CMS Security & Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen, Freiberufler:innen
Vorankündigung....
am 26.03.2018 - 07:22 Uhr
Bitte, was wäre denn eine Methode bei man das PHP der Seite nicht mehr ausführen kann?
Geht ganz einfach, bis das
am 26.03.2018 - 11:04 Uhr
Geht ganz einfach, bis das Update erscheint
systemctl stop apache2.service.
oder
systemctl stop php-fpm.service
Das ist natürlich nicht gangbar, da deine Kunden sonst denken du bist Offline gegangen. Aber im Vergleich dazu in eine Spamschleuder verwandelt zu werden ist das ein kleiner Preis. Ich würde auf jeden Fall ein Backup meiner Mysql-Datenbank und meiner Webseite machen. Damit für den Fall der Fälle zumindest möglichst schnell Fremdcode aus der Webseite entfernt und der Ursprungszustand wieder hergestellt werden kann.
https://drupal-tv.de
Drupal sehen und lernen
Es gibt mehrere Wege zu einer PHP freien Maintenance-Seite
am 26.03.2018 - 11:41 Uhr
Gleich den ganzen Server abzuschalten ist vllt. übertrieben und funktioniert ja auch nicht im Shared Hosting. Der einfachste Weg ist es im Webroot Ordner (dort wo die Domain "drauf zeigt") keine PHP Dateien vorrätig zu halten, die ausgeführt werden können. Dort kann man dann z.B. eine "index.html" erstellen mit einer speziellen Matainenance-Message, auf die man z.B. per .htaccess alle Anfragen temporär drauf lenkt. Man kann entweder die Domain dafür auf ein alternative Verzeichnis lenken oder den Webroot umbenennen und einen neuen benutzen. Aber das sollte man alles vorsichtig ausprobieren, da es je nach Servr-Setup auch dabei zu Problemen kommen kann. Im Zweifel muss man die Dateien aus dem Webroot raus "schieben". Bei Apache Systemen kann man mittels .htaccess auch die Ausführung von PHP unterbinden, siehe Default .htaccess im Files-Verzeichnis. Wenn der Server mit Aliase/Symlinks klarkommt, kann man dann einfach den Webroot-Symlink ändern.
Was den Content betrifft ist es natürlich eleganter wenn es mehr HTML-Seiten mit Layout usw, gibt z.B. aus einem Drupal exportiert. Da habe ich beim Camp in Essen auch eine Session zu gehalten und biete mit meiner Firma das als Service für ohnehin einfache, statische Websites an. Aber das ist bis Mittwoch dann ohnehin zu knapp. Es ist hier wie mit Backups usw. Man sollte für solche Fälle am Mittwoch immer ein Fallback Plan vorbereiten, dann ist das mit wenigen Handgriffen, einem Knopfdruck oder ganz automatisch erledigt.
(Eine filigrane Steuerung darüber wann und wo unter welchen Umständen welche PHP-Dateien ausgeführt werden können je nach unterschiedlochen Server-Setzups ist natürlich auch gut. Z.B. lasse ich auf vielen Drupal-Systemen ohnehin nur noch die index.php ausführen. Aber das ist ein Thema, das ich mal anderer Stelle behandeln sollte.)
Ergänzung (weiterer Tipp):
Man kann und sollte vllt. auch mit einer "Hilfs-Domain" operieren, auf der man einen Web-Access konfiguriert, der die Hacker und Bots abhält. So kann man auf der Produktiv-Domain den besonderen Maintenance-Status zeigen und dann in Ruhe das Drupal-System über die Hilfs-Domain erreichen und updaten. Das habe ich bei unseren System zwar immer automatisch konfiguriert, aber das lässt sich dann im Standard-Shared Hosting auch manuell nachbauen mit der oben beschrieben Domain-Umlenkung der Produktiv-Domain auf das Maintenenace-HTML und einer weiteren Hilfsdomain für den Drupal-Webroot, bei dem man evtl. dann manuell in der .htaccess Datei dann den Passwort-Schutz konfiguriert. Wer Zugriff auf die Server-Konfig hat, kann diesen Passwortschutz wie wir dann auch direkt dort konfigurieren und somit die Hilfdomain immer aktiv halten und die oben beschriebene Maintenanace-Situation einfach per Symlink steuern.
# DrupalCenter-Moderator # https://www.drupal.org/u/c-logemann
# CTO der Nodegard GmbH: CMS Security & Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen, Freiberufler:innen
Danke für's Teilen. Im Großen
am 26.03.2018 - 16:25 Uhr
Danke für's Teilen. Im Großen und Ganzen hat das Drupal Team dieses Mal das Security Update wesentlich besser kommuniziert. Dies weiß man erst einmal zu schätzen, wenn man andere CMS Lösungen gemanaged hat und sich Infos aus Foren, IRC und Maillinglisten zusammen suchen muss. Die gute Dokumentation und ausführliche Release Notes fand ich schon immer super an Drupal. Ein Nachteil der Domain-Umlenkung auf eine externe Maintenenace-HTML Datei ist das Caching.
Hoffentlich wurden auch ausreichend Serverkapazitäten gebucht, sodass die Downloadserver nicht in die Knien gehen.
Grüße aus dem sonnigen Heidelberg.
Maker • Visual Designer • Site Builder https://binroth.com
Welcher Cache bringt hier einen Nachteil?
am 26.03.2018 - 16:51 Uhr
Ein Nachteil der Domain-Umlenkung auf eine externe Maintenenace-HTML Datei ist das Caching.
Wenn die Hosting-Plattform sind das Verzeichnis merken würden, wäre das ein Problem. Das denke ich aber nicht.
Ein evtl. vorhandener OPcode cache wird denke ich nicht verschwundene PHP Dateien aus dem Cache heraus ausführen.
Und sollte HTML irgendwo im Cache liegen, wäre das sogar hilfreich, um zu verschleiern, daß die Seite gerade "offline" ist.
# DrupalCenter-Moderator # https://www.drupal.org/u/c-logemann
# CTO der Nodegard GmbH: CMS Security & Availability Operations / Wir unterstützen IT-Abteilungen, Agenturen, Freiberufler:innen
Falls da draußen noch jemand
am 29.03.2018 - 10:32 Uhr
Falls da draußen noch jemand mit D6 arbeitet und sich absichern möchte, hier ist der entsprechende Patch:
https://cloud.nzoss.nz/s/cKkEwDqQMt4RBfX
Für Drupal 7 tuts drush up oder das alte Spiel:
auch!
https://drupal-tv.de
Drupal sehen und lernen