[nach Xinha-Hack] Nicht gebrauchte Plugins löschen - wie?

[maxfli55]

Hallo,

mich ärgert es enorm, dass ich auch Opfer des s9y-Xinha-Hacks geworden bin, obwohl ich Xinha gar nicht verwende. Das Plugin liegt nur als Ballast auf meinem Webspace. Um für die Zukunft Sicherheitslücken durch nicht verwendete Plugins zu vermeiden, stellt sich folgende Frage:

Wie kann ich nicht verwendete Plugins von meinem sicher Webspace entfernen, ohne die s9y-Installation zu beschädigen?

Gruß
maxfli55


PS:
Bei mir wurde neben dem Upload der üblichen Dateien (http://blog.s9y.org/archives/224-Import ... eased.html) auch eine neue Datenbank angelegt, die ich wegen fehlender Rechte bislang nicht löschen kann!

[yellowled]

Wie kann ich nicht verwendete Plugins von meinem sicher Webspace entfernen, ohne die s9y-Installation zu beschädigen?

Im Prinzip, indem Du einfach das Pluginverzeichnis mittels FTP entfernst. Etwas schwieriger ist das bei den sogenannten „internen Plugins“, die zum Kern gehören, oder eben Xinha, der noch nicht einmal im Plugin-Verzeichnis liegt.

Zudem würde in dem Fall die Integritätsprüfung bei Updates meckern, da Dateien, die zum Kern gehören, fehlen. Und natürlich müsstest Du Sachen, die zum Kern gehören, bei einem Update auslassen.

Generell würde ich sagen, der Aufwand lohnt nicht. So ärgerlich es ist, dass Du zu den Opfern dieser Lücke gehörst -- grundsätzlich ist S9y ziemlich sicher, insofern sollte man meines Erachtens jetzt nicht annehmen, bei jedem Update Gefahr zu laufen, gehackt zu werden. Die Xinha-Lücke war die erste ernstzunehmende solche seit Monaten, noch dazu auf 3rd-Party-Software zurückzuführen.

Bei mir wurde neben dem Upload der üblichen Dateien (http://blog.s9y.org/archives/224-Import ... eased.html) auch eine neue Datenbank angelegt, die ich wegen fehlender Rechte bislang nicht löschen kann!

Eigentlich jeder anständige Hoster bietet irgendeine Funktion, um die Rechte von Dateien zurückzusetzen, normalerweise auf den PHP-User/Webserver oder den FTP-Nutzer. Falls das nicht der Fall ist, setzt der Support des Hosters die Rechte in so einem Fall bestimmt gerne manuell zurück oder übernimmt das Löschen.

YL

[garvinhicking]

Hi!

Erstmal: Was YellowLED sagt.

Dann: Es ist schwer zu sagen was Du löschen kannst, ohne zu wissen was du einsetzt. Im s9y Kern sind zahlreiche Dateien enthalten die nicht von jedem genutzt werden.

Dazu zählen natürlich alle plugins in /plugins die du nach belieben löschen kannst. Wenn Du keines der Internen plugins nutzt (Kalender, Kategorien, Suche, Archive, Referrer, Exits, blog abonnieren, Login, HTML Klotz, Autoren) kannst du auch include/plugin_internal.inc.php löschen.

/htmlarea kannst du löschen wenn du den WYSIWYG editor nicht einseztt.

/deployment kannst du löschen wenn du keine shared installation nutzt.

Aus /templates kannst du die templates löschen die du nicht einsetzt, bis auf bulletproof und default.

Aus /lang und /lang/UTF-8 kannst du die Sprachen löschen die Du nicht nutzt.

Aus include/db kannst du die Datenbankklassen löschen die Du nicht nutzt.

Aus /include/admin kannst du die "Ansichten" vom Code löschen die Du nicht nutzt, z.b. Import und Export.

Aus /iunclude/admin/importers kannst Du die Importer löschen die Du nie einsetzen willst.

Aus bundled-libs/ kannst Du "Cache" löschen wenn Du nie ein Plugin einsetzt was PEAR::Caching verwenden will. HTTP/ kannst Du darin löschen wenn Du nie ein Plugin einsetzt dass Dateien per HTTP ziehen will. Onyx kannst du löschen wenn Du nie ein Plugin einsetzt, dass RSS-Feeds parsen will. tests/ kannst du löschen wenn du Dir die Unit-Tests nie ansehen willst.

Wie Du siehst: Wo fängt man an, wo hört man auf. Letztlich ist es für alle natürlich schöner ein Paket zu haben, dass gefahrlos publiziert werden kann und wo alle Bugs an uns gemeldet und von uns behoben werden. Darum kümmern wir uns immer mit Hochdruck. Es gab noch nie ein Sicherheitsleck, wo nicht innerhalb von 24 Stunden nach Bekanntgabe an uns direkt auch ein Fix zur Verfügung stand. Uns, und vor allem mir persönlich, liegt die Sicherheit des Systems genauso wie der größtmöglichen Kompatibilität und Einsatzvielfalt am Herzen. Sehr!

LG,
Garvin

[yellowled]

Und außerdem, um Altkanzler Helmut Schmidt zu zitieren: „Ein jeder Mensch muss sich bewusst sein, dass es eine absolute Sicherheit nicht geben kann.“ -- zwar in anderem Zusammenhang, stimmt aber auch für Software.

Ich bin jetzt nicht der Ober-Sicherheitsexperte, aber ein Großteil der Lücken in S9y oder vergleichbaren Systemen ist nicht mal auf das System selbst zurückzuführen, sondern auf 3rd-Party-Software wie extern betreute WYSIWYG-Editoren oder gar auf Lücken in PHP selbst. Für diese Lücken sind die Entwickler des Systems nicht verantwortlich, sie können sie aber auch nicht vermeiden.

YL

[maxfli55]

Danke für die Info.

Dass es nicht die absolute Sicherheit geben kann, ist mir schon klar. Es ärgert mich nur gewaltig, dass der für mich unnötige Xinha zu diesem Stress geführt hat. Deswegen wollte ich einen vorgezogenen Frühjahrsputz in meiner Installation machen.

Nun geht's an fröhliche Löschen. Muss ich bei den nächsten s9y-Updates wieder von vorn anfangen, oder gibt es eine s9y-light-Variante?

Gruß
maxfli55

[garvinhicking]

Hi!

Der aufwand für eine "megalight"-Variante ist viel zu hoch, und die dürfte auch kaum ein User nutzen können.

Du musst die Dateien dann nach dem update immer neu löschen. Das ist der Preis für eine derart individualisierte Installation...

Grüße,
Garvin

[yellowled]

Der aufwand für eine "megalight"-Variante ist viel zu hoch, und die dürfte auch kaum ein User nutzen können.

Man könnte natürlich so einen „Tarball-Builder“, der einem über ein Formular nur das ins Download-Archiv packt, was man auch wirklich ... nicht? Zu aufwändig? Zu fehleranfällig? Für Laien nicht benutzbar?

YL

[garvinhicking]

Hi!

Ich muss immer jeden tarball einzeln hochladen, md5 checksumen berechnen, copy & pasten etc. Ein release dauert jetzt schon ungefähr 2,5 bis 3 Stunden Arbeit (mit blogartikel, SF.Net upload, SVN kram, packen, hochladen etc.). Da ist die Schmerzgrenze schon überschritten...

Und kaum jemand versteht schon den Unterschied "LITE" und "Normal". Da möchte ich ungerne noch mehr Verwirrung stiften. Das höchste der gefühle wäre nur im Gegenteil das erwähnte "s9y version mit noch mehr populären plugins als bundle".

Grüße,
Garvin

[yellowled]

Ich muss immer jeden tarball einzeln hochladen, md5 checksumen berechnen, copy & pasten etc. Ein release dauert jetzt schon ungefähr 2,5 bis 3 Stunden Arbeit (mit blogartikel, SF.Net upload, SVN kram, packen, hochladen etc.). Da ist die Schmerzgrenze schon überschritten...

Kann ich voll und ganz nachvollziehen. Gäbe es da Möglichkeiten, Dir einen Release zu vereinfachen? Würde es helfen, den ganzen Kram in ein Repository zu packen anstatt in zwei? Du erinnerst Dich sicher, dass ich schon mal vorgeschlagen hatte, alles auf GitHub umzuziehen ... Kann man Dir irgendwas abnehmen dabei?

Und kaum jemand versteht schon den Unterschied "LITE" und "Normal". Da möchte ich ungerne noch mehr Verwirrung stiften. Das höchste der gefühle wäre nur im Gegenteil das erwähnte "s9y version mit noch mehr populären plugins als bundle".

Die halte ich nun wieder für relativ sinnlos. Je nach konkreten Zugriffszahlen auf Lite/Normal könnte man Lite evtl. auch wieder fallen lassen, falls der Kern in Kuhzunft ohnehin entschlankt werden sollte ...

YL

[garvinhicking]

Hi!

Das ist lieb, danke für's Angebot. Aber grundsätzlich weiß ich was zu tun ist, mich in etwas neues einzuarbeiten sehe ich jetzt nicht so angenehm...irgendwann müsste ich mich mit github mal auseinandersetzen. Sonst macht mal ein Feature im s9y podcast drüber um's mir schmackhaftz u machen

Grüße,
Garvin

[yellowled]

irgendwann müsste ich mich mit github mal auseinandersetzen. Sonst macht mal ein Feature im s9y podcast drüber um's mir schmackhaftz u machen

Das passt jetzt thematisch nicht wirklich in den Podcast.

Ich benutze GitHub auf absolutem Laienlevel, um ein paar kleine Dinge versioniert zu verwalten. Von der grundsätzlichen Benutzung her ist es nicht viel anders als cvs/svn -- es ist ja auch so konstruiert, dass der Umstieg leicht fällt. Kann gut sein, dass es nochmal eine andere Hausnummer ist, wenn man ein großes Projekt mit branches etc. verwalten muss, aber gefühlt ist es zehnmal angenehmer, bequemer und flotter als cvs/svn ...

YL

[ju]

Noch eine Frage zu Sicherheits-updates: wie erfaehrt man am schnellsten/sichersten davon, dass es eines gibt? Hier ins Forum schaue ich ja nur, wenn ich ein Problem mit s9y habe, also nahezu nie

Dass ich gestern herschaute und dabei von dem dringenden Security-update von Dezember las, war purer Zufall.

Neue Versionen von Plugins sehe ich im Web-Interface. Werden neue Versionen von s9y auf der Mailing-Liste bekannt gegeben? Auf welcher von beiden?

[garvinhicking]

Hi!

RSS-Feed von blog.s9y.org abonnieren. Oder beim sf.net release tracker anmelden, da kriegt man bei neuen dateien ne email. Die Funktion zu finden ist aber etwas frickelig.

Innerhalb von s9y gehts mittels des Dashboard-Plugins.

Grüße,
Garvin

[ju]

Das Leben kann so einfach sein Danke! done.