Wieder WordPress-Blogs in Gefahr
von caschy | 20 Kommentare
Ihr seid Betreiber einer WordPress-Seite? Es gibt offenbar wieder etwas zu tun, denn schon wieder macht eine Lücke auf sich aufmerksam. Hierbei handelt es sich wiederholt um eine Cross-Site Scripting (XSS)-Anfälligkeit, die über das Standard-Theme TwentyFifteen oder über das Jetpack-Plugin ausgeführt werden kann. Speziell präparierte Seiten könnten die Lücke nutzen, um den Account eines WordPress-Administrators zu übernehmen. Viele US-Hoster haben bereits Vorkehrungen ergreifen können – ihr könnt jetzt mal wacker in euer WordPress-Backend huschen, denn das Jetpack-Update ist seit ca. 19:30 Uhr deutscher Zeit zu haben. Wer mehr technische Details benötigt, der bekommt diese hier. (danke metai!)
Wird geladen ...
Für das Theme TwentyFifteen habe ich eben auch ein Update gehabt.
Danke für den Hinweis.
Ist doch schön jede Woche wieder eine wichtige Sicherheitslücke stopfen zu müssen. Nein, WordPress hat kein grundlegendendes Problem…
Wer weiß wie viel Software – CMS inbegriffen! – es da draußen gibt, die unentdeckte Sicherheitslücken aufweisen. Nichts ist perfekt.
Bei WordPress kann man sich darauf verlassen das lücken schnell geschlossen werden. Macht weiter so!
Anm., die Securi-Seite erwähnt es leider nicht: Die Sicherheitslücke ist in JetPack und TwentyFifteen nutzbar, selbst wenn das Plugin bzw. das Theme nicht aktiviert ist. Man sollte sie updaten — oder noch besser, wie bei allen Plugins und Themes, wenn man sie nicht nutzt aus der Installation entfernen.
Vielen Dank für den Hinweis!
Ja klar, aber gerade hat WordPress grundlegende Probleme, die seit Jahren bekannt sind und anscheinend auch nicht mit dem nächsten Major Release angegangen werden sollen.
Doofe Frage, evtl weiss das einer, ich benutze keines der Standard Themes. Kann ich die Dinger problemlos löschen, oder kann da was wegen irgend ner Fallback Funktion in die Hose gehen? Weiss das jemand?
Ja? Dann erzähl bitte mal von den „grundlegenden Problemen“.
WordPress hat einige Nachteile in der Struktur der Datenhaltung, die hauptsächlich auf die weitere Unterstützung der zu beginn definierten Strukturen für ein Blog zurückzuführen sind. Das ärgert mich als Entwickler gelegentlich, ist aber nicht sicherheitsrelevant.
Aber was die Sicherheit betrifft, ist WordPress wohl eines der am genauesten beäugten und praktisch immer unmittelbar gebugfixten Projekte, die es gibt. Die Sicherheitslücken stecken fast immer in Plugins und Themes, das kann man dem Basisystem aber nicht anlasten.
Dass in der Berichterstattung darüber desöfteren WordPress mit seinen Erweiterungen in einen Topf geworfen wird, ist der Zielsetzung, dass die Benutzer aufmerksam werden, ja nicht umbedingt abträglich.
Ja, bedenkenlos.
(Gesetzt den Fall, dass dein aktuelles Theme ein sogenanntes „Child Theme“ ist und eines dieser Basisthemes als Vorlage/Elternteil benutzt, bekommst du im „Theme-Details“-Dialog für dieses Theme erst gar keine Löschfunktion angeboten.)
Schafft der „ich richte mir zum Verfassen von Beiträgen einen Redakteuraccount ein und nutze den admin Acc nur für wichtige Änderungen“ Trick hier Abhilfe?
Will sagen, kann nichts passieren, solange ich nicht bzw. nicht als Administrator eingeloggt bin?
Datenbankanbindung, Update-System, fehlende Überprüfung des Plugin Directory.
Probleme, ja, wobei ich einiges eher in Richtung „Unannehmlichkeiten“ einsortieren würde. Und bei vielem, speziell was UI und UX betrifft, würde ich mir wünschen, dass WordPress einen anderen Weg gehen würde, mir liegt im Moment da der Fokus deutlich zu sehr auf dem Polieren von Dingen, die eher dem unbedarften Gelegenheitsbenutzer zugute kommen.
Aber das sind alles keine sicherheitsrelevanten Probleme. Und man meint, dass du davon sprichst, wenn du einen Kommentar wie „WordPress hat seit Jahren grundlegende Probleme“ unter diesem Artikel schreibst, meint man, dass du von sicherheitsrelvanten Problemen sprichst.
In diesem Fall: Jein, es ist vielleicht nicht ganz so wild, aber es reichen ja schon Redakteursrechte, um diversen schädlichen Unfug in einem Blog zu treiben.
Ergänzend: Diese Sicherheitslücke ist auf diverseste Arten ausnutzbar, das Erlangen von Rechten in einer WordPress-Installation ist nur eine davon.
Datenbankanbindung: Die WordPress-Devs sind so schlau ein eigenes System für die SQL-Zugriffe zu nehmen, was zum einen die Kompatibilität mit Nicht-MySQL (oder MariaDB) stark einschränkt und zum anderen bedeutet, dass WordPress nicht die in PHP inzwischen eingebackenen Prepared Statements benutzt. Und da kannst du dir sicher sein, dass die wesentlich besser getestet wurden als das WordPress-Eigenbausystem.
Update-System: Auch hier habe ich nichts von UI/X gesagt, da kann man sich ja kaum beschweren. Das Problem ist, dass das System so designt ist, dass das PHP-Skript alle Dateien überschreiben können muss, um sich automatisch zu updaten. Natürlich kann man die Rechte selbst anpassen und dann im Admin-Panel über FTP gehen, bei den meisten Installationen wird aber dem Nutzer aber erstmal ein inherent unsicheres System installiert. Das ist ungefähr vergleichbar mit jedem Nutzer auf einem Linux-System dauerthaft root / super user Rechte zu geben. Genauso wie man als Benutzer im CMS getrennte Admin- und Redakteur-Accounts haben sollte auch das Update-System getrennt werden (ist ja nicht so, dass Unix-Server genau dafür ein Benutzer- und Rechtesystem haben).
Plugin Directory: Kannst natürlich sagen „Ist nicht core, warum sollte das die WordPress-Entwickler kümmern.“, klar. Dann kannst aber auch sagen warum sollte Google den Play Market kontrollieren, sind ja nicht ihre Apps, die da angeboten werden… Im WordPress Plugin Directory kann jeder Hobby-„Hacker“ in wenigen Minuten sein Plugin hochladen und einige hundert Installationen infizieren bevor es bemerkt wird. Es werden weder ordentliche Eingangsprüfungen gemacht, noch werden Plugins mit bekannten Sicherheitslücken aus dem Directory entfernt. (Bis auf es gibt einen Haufen Meldungen von betroffenen Nutzern.) Aber immer schön sagen wie viele Plugins es gibt und was man alles mit WordPress machen könne.
Das möchte ich nicht bestreiten und das ist großartig. Die große Nutzerzahl macht WP zwar zu einem beliebten Ziel, gleichzeitig bleiben hier 0day attacks auch wirklich 0day, und nicht 42day… Aber nur weil man in dem Feld so gut und genau arbeitet kann das keine Entschuldigung sein schlechtes Software-Design fortzuführen.
Über die Datenbankanbindung und dessen Vor- und Nachteile kann ich mich nicht weiter auslassen, da gibt es schlauere als mich. Allerdings kann ich mich im letzten halben Jahrzehnt an keinen einzigen Exploit erinnern, dessen Ursache die Datenbankanbindung selbst ist. Auch wenn sie hier ihr eigenes Süppchen kochen, scheint es ein gutes zu sein, auch wenn ich mir die Performance (zumindest des Basissystems) ansehe, scheinen da sehr fähige Leute dran zu sitzen. YMMV.
Ich glaube, dass allerdings grade DAS der UX geschuldet ist, um den Millionen von unbedarften Benutzern ein leichtes Installieren/Updaten zu ermöglichen. Und dass die Serveradministratoren da eben eher auf Benutzerwünsche gucken anstatt (zu Recht) auf Sicherheit zu pochen. Ich selbst hab‘ kein Problem mit einer WordPress-Installation, die nirgends hin schreiben darf außer in das Medienverzeichnis, ich bin allerdings kaum der Standardfall.
Ach, das Plugin-Verzeichnis ist mir schon lange ein Dorn im Auge, nicht nur was Sicherheits-, sondern auch Qualitätsaspekte angeht. Meiner Meinung nach könnte man 95% des Verzeichnisses ungesehen und ohne große Verluste in die Tonne treten. Das Problem ist hier allerdings: Wer soll eine Qualitätsprüfung vornehmen? Ich meine, dass hier einfach die Manpower fehlt. Oder ein Plan (wie z.B. bei Firefox‘ Add-On-Verzeichnis), wie man überhaupt vorgehen soll, Plugins zu kennzeichnen.
Was man der „WordPress-Community“ und WordPress/Automattic selbst auch anlasten muss, ist, dass der Open-Source-Charakter wahnsinnig schlecht ausgeprägt ist und auch kaum kommuniziert bzw. gefördert wird: Zusammenarbeit an Plugins passiert fast ausschließlich im Rahmen von Unternehmen, die dann auch gerne eine „Pro“-Version verkaufen, die schließen durch dieses Vorgehen Kollaboration fast aus. Außerhalb dieses Rahmens scheint Ich kann mich nicht erinnern, jemals ein von einer Gruppe von Freiwilligen geführtes größeres Plugin-Projekt gesehen zu haben. Jeder macht dort was er will, nicht nur, weil man kann, sondern weil es nicht anders etabliert ist.
Ich meine, man muss aber auch ganz klar differenzieren zwischen WordPress-Installationen von unbedarften bzw. für unbedarfte Benutzer unterscheiden und denen, die professionell eingerichtet, konfiguriert, betreut und verwaltet werden, sowohl auf Server- als auch auf Software-, Plugin- und Theme-Ebene. Dass hier ein Unterschied besteht, muss ich meinen Kunden auch immer erst erklären.
Ja, leider :/
Tnx mentai, hab die Dinger direkt mal rausgeworfen.