Skip to content

Sicherheitslücke in Serendipity bis einschließlich 1.5.2

Es gibt eine nicht ganz unschwere Sicherheitslücke in Serendipity bis einschließlich 1.5.2: In der Xinha-Bibliothek von S9Y ist ein Bug, der remote code exploits erlaubt.

Allen Nutzern wird dringend geraten, auf 1.5.3 upzugraden oder - als Übergangslösung - die htmlarea/contrib/php-xinha.php zu löschen.

Hier der Auszug aus dem Original-Post von Garvin Hicking:
A security issue has been discovered by Stefan Esser during the course of the Month of PHP Security. This issue was found in the WYSIWYG-Library Xinha (that Serendipity uses), and affects certain plugins to Xinha (Linker, ImageManager, ExtendedFileManager, InsertSnippet) which can use a dynamic configuration loader. This loader allows to upload file with arbitrary PHP-Code and thus allows remote code execution, even when not logged in to the Xinha/Serendipity backend.

Due to the seriousness of this bug, we urge everyone to upgrade their installations. People who don't want the hassle of a full upgrade and are not using the mentioned Xinha-plugins actively, can simply delete the file htmlarea/contrib/php-xinha.php, which will render the mentioned plugins and exploits useless.
Wir haben alle unsere möglicherweise betroffenen Webhosting-Kunden (ausgewählt rein durch den Dateinamen) angeschrieben und auf das Problem hingewiesen.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Dirk

„Rein durch den Dateinamen“? Das heißt, ihr habt verdachtsunabhängig sämtliche Daten aller Kunden durchsucht, ohne, dass diese dem vorher zugestimmt haben?

Jens123

War auch mein erster Gedanke ...

Delphin64

Und was soll an einem 'find -n php-xinha.php' so schlimm sein?

Man kann's auch übertreiben... übrigens: die Manituaner sichern wahrscheinlich sogar die Daten auf jedem Kundenserver ohne vorher um Erlaubnis gefragt zu haben!

Urs

Gefällts dir denn besser wenn irgend eine Fremde Person über dieses Loch den Server nach interessanten Files durchsucht, oder in alle Webseiten irgendwelchen Schadcode einbaut?

Ich gehe davon aus dass das bei Manitu nicht möglich ist, ich habe aber schon einige shared hostings gesehen bei denen das geht.

Ich habe Verständnis dafür dass man in solchen Fällen die Shared Hostings durchsucht. Ich würde sogar noch weiter gehen und die Seite ausschalten wenn der Kunde nicht reagiert.

Manuel Schmitt (manitu)

Ich mache es aus Zeitmangel kurz: Ja, wir haben anhand des Dateinamens "gesucht" (und zwar nicht via find, sondern via locate, aber ich denke, das spielt hier keine Rolle).

Wir haben nicht mal in die Datei reingeschaut, sprich kein md5sum drüberlaufen lassen, sprich wir haben nicht selektiert, wer wirklich betroffen ist (was ja ginge, wenn wir nur die angeschrieben hätten, deren Datei eine andere Checksumme als die von Version 1.5.3 aufweist). Sprich nicht Inhalt, sondern nur "Headerdaten".

Rein formaljuristisch ist dies über "Geschäftsführung ohne Auftrag" zu sehen. Korrekt gesehen dürften wir dafür sogar Geld nehmen (ja, auch OHNE Auftrag).

Wir haben aber einen entsprechenden (gültigen, von Rechtswegen bestätigten) Passus in unseren AGB, der uns dazu ermächtigt, da es ja in beiderseitigem Interesse ist, wir die Daten sowieso haben (sprich wir machen uns damit ja nicht Daten zueigen oder erlangen Kenntnis davon, denn erledigt wird es ja automatisiert), und wir handeln im Interesse des Kunden - kostenfrei.

Andy

Ich wäre froh andere Hoster würden soetwas auch machen.

MD5 wäre sowieso fast komplett unnötig gewesen, die 1.5.3 ist erst wenige Tage alt.
Ich habe letzte Woche Montag noch nen neuen S9Y Blog installiert, war auch noch die 1.5.2.

Ansonten, euer Verhalten war vollkommen richtig.
Ähnliches haben übrigens auch andere Hoster in den AGB drinn stehen.
Ich wurde mal angeschrieben dass eine meiner index.html einen iFrame mit Schadcode hatte, diese wurde von denen durch ein sauberes Backup ersetzt.

Hatte ich auch kein Problem mit.
Das ganze war übrigens anscheinend durch einen Angriff auf den Server über eine Lücke von einem PHP Script das nichtmehr ganz aktuell war.
Da sieht man wie wichtig soetwas doch ist.

postal

und was ist mit einem
for url in alle_bei_uns_registrierten_urls
wenn wget url/bluba.php
mail "alarm alarm"

???
find ich jetzt nicht so schlimm...

Andy

Ach so ein doofer mist aber auch, ich hab doch erst die Tage auf 1.5.2 upgraded GNAH.

Dirk

Danke @Manuel für die erklärung:

@alle, die es „nicht so schlimm“ finden: Schon mal was von Privatsphäre und Datenschutz gehört? Nein? Euch sollte man die Computer Onlinedurchsuchen! Schließlich macht der Staat auch nur seine Arbeit, und sucht nach gefährlichen Sachen! Besser die als irgendein Cracker, oder?

Soviel Datenschutzunverständnis widert mich an!

Manuel Schmitt (manitu)

Findest Du das, was wir "getan" haben, in Verbindung mit der Erklärung weiterhin "schlimm"?

Dirk

Ein verstoß gegen den Datenschutz wird nicht plötzlich gut, weil er begründet wurde.

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen