andi.de » php

wordpress.org gehackt

Andi — Sat, 03 Mar 2007 10:50:27 +0000

Dem Download-Server von wordpress.org ist das passiert, was man wohl als GAU bezeichnen darf: ein unbekannter Cracker hatte sich Zugang verschafft und die dort abgelegte Version 2.1.1 mit Codeänderungen versehen, die potentielle Sicherheitslücken darstellen.
Wer in den letzten 3-4 Tagen die englischsprachige Version geladen hat ist somit angreifbar und muss dringend auf die neu verfügbare (und sichere) Version 2.1.2 updaten; die deutsche Lokalisation war nicht betroffen, da diese anderweitig gehostet wird, ebenso ist die alte Versionschiene 2.0 sauber.
Wer die Möglichkeit hat (sei es als Hoster oder als Selbstschrauber) sollte als Sofortmaßnahme bis zum Update Zugriffe auf theme.php und feed.php unterbinden und alle HTTP-Anfragen mit den Zeichenfolgen ix= oder iz= blocken.
Ein lokalisiertes Update-Paket der deutschen Version ist zum Download bereit, ebenso die englischsprachige Version.
Nähere Informationen zu den Vorgängen gibt es im deutschen WordPress-Blog.

WordPress: Cross-Site-Scripting-Lücke

Andi — Wed, 28 Feb 2007 13:38:08 +0000

Im 2.1-Versionspfad von WordPress sind erneut Sicherheitslöcher entdeckt worden, welche für Cross-Site-Scripting-Attacken genutzt werden können.
Eingaben an den Parameter ‘post’ in der Datei /wp-admin/post.php (falls “action” auf “delete” oder “deletecomment” gesetzt ist) werden nicht korrekt gefiltert, bevor sie an einen Benutzer zurückgegeben werden. Dies kann ausgenutzt werden, um im Kontext einer betroffenen Seite beliebigen HTML- und Scriptcode in der Browsersitzung eines Benutzers auszuführen und hierbei z.B. Cookie-Daten an fremde Server zu senden.
Für eine erfolgreiche Ausführung muss der betroffende Nutzer als Administrator angemeldet sein.
Ein weiterer Fehler betrifft die Suchfunktion. Sobald ein einzelnes Komma ohne zusätzliche Zeichen an die Suchmethode übermittelt wird, verabschiedet sich diese mit einem SQL-Fehler:

WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND ((post_status = 'publish' OR post_status = 'private')) ORDER BY post_dat' at line 1] SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts WHERE 1=1 AND () AND ((post_status = 'publish' OR post_status = 'private')) ORDER BY post_date DESC LIMIT 0, 10

Ein weiterer SQL-Inject durch dieses Problem ist bisher nicht bekannt.
Beide Fehler wurden im SVN-Trunk behoben, ein offizieller Bugfix oder Patch ist bislang nicht erhältlich. Bis zum Erscheinen eines solchen empfielt sich Vorsicht oder z.B. eine zusätzliche Absicherung durch mod_security o.ä.

Sicherheitslücke in WordPress 2.0.6

Andi — Thu, 11 Jan 2007 13:17:04 +0000

Schon kurz nach Erscheinen der letzten Version 2.0.6 von WordPress, die u.a. auch Sicherheitslücken schloss, taucht nun erneut eine kritische Lücke auf, die auch bei Version 2.0.6 noch funktioniert. Neben Nennung der für die Ausführung nötigen Voraussetzungen wurde auch sofort ein passender Exploit mitgeliefert.
Es wird eine Lücke in der Datei wp-trackback.php ausgenützt, um mittels SQL-Injection Passwörter auszulesen.
Als Voraussetzung für den Exploit ist (einmal mehr) die PHP-Option register_globals=on von Nöten (eine der schlimmsten Sicherheitsproblemstellen in PHP), ausserdem PHP-Version zwischen 4 und 4.4.3, bzw. kleiner 5.1.4.
Es empfiehlt sich, bis ein Patch die Lücke schließt, entweder dafür zu sorgen, dass register_globals nicht aktiviert ist (leider bei vielen shared hosting – Paketen immer noch aktiv), oder temporär die Datei wp-trackback.php umzubenennen (oder zu löschen) — als „Nebenwirkung“ werden dann temporär keine Trackbacks mehr empfangen.
Es gibt ferner Spekulationen, dass ebengenannter Exploit auch dazu benutzt worden sein könnte, um heute Nacht das Firmen-Weblog der Studentencommunity StudiVZ mit einem ‘Defacement‘ zu versehen und dort eine Gegendarstellung des CCC zu veröffentlichen (inzwischen ist das Blog komplett offline). Solange hierzu allerdings keine offizielle Verlautbarung des Betreibers vorliegt kann dies aber nur vermutet werden.

Update:
In einem Artikel bei heise online stellt der PHP-Experte Stefan Esser einige Details klarer dar:

Laut Esser liegt der Fehler, den der neue Exploit ausnutzt, nicht bei WordPress selbst, da es Sicherheitsabfragen gegen die eingesetzte Einbruchstechnik enthält. Laufe ein Server allerdings mit einer PHP-Version, die den Bug zend_hash_del_key_or_index aufweist, lasse sich der implementierte Schutz aushebeln, so Esser. (…) In aktuellen Linux-Distributionen ist die Lücke nicht enthalten. Auch in der unter Debian-Stable eingesetzten [PHP-]Version 4.3.10 ist die Schwachstelle bereits seit August behoben.

Ajaxified Webmail-Zugriff

Andi — Mon, 20 Nov 2006 22:58:33 +0000

Schon vor gut 1 1/2 Jahren startete das Projekt roundcube mit der Umsetzung eines Webmail-Clients, der die einfachen Zugriff über jeden Webbrowser mit dem Komfort & den Features einer Offline-eMail-Anwendung kombiniert.
Möglich macht dies der konsequente Einsatz von AJAX-Technologie, wodurch das bei älteren Vertretern (wie z.B. Horde) übliche andauernde Neuladen kompletter Seiten und den damit verzögerten Arbeitsablauf ausgleicht.
Obwohl die Versionsnummer mit 0.1-beta2 noch sehr niedrig angesiedelt ist, und sich das Team mit der Veröffentlichung neuer Meilensteine einige Zeit lässt, lohnt sich vor allem der Blick auf den aktuellen Entwicklersnapshot per SVN.
Hier finden sich zumeist wesentlich mehr implementierte Funktionen als in den mit ‘stable’ deklarierten Versionen – und trotz Dev-Status lassen sich die SVN-Versionen meist ohne Probleme einsetzen.
roundcube eignet sich für alle Server, die Zugriff über IMAP bieten und stellt dem Nutzer bisher u.a. Ordnermanipulationen, MIME-Unterstützung, Adressbuch, Drag’n'Drop, Suche, Rechtschreibprüfung etc. an.
Nach der Installation kann z.B. die Webmail-Funktion von Plesk von Horde auf roundcube „umgebogen“ werden. Der einfachste Weg besteht in einer Anpassung der Apache-Konfiguration von Plesk. Bei Debian befinden sich die Einträge in /etc/apache/conf.d/zz010_psa_httpd.conf
Dort finden sich sowohl für http- als auch für https-Zugriff auf webmail.domain.de Einträge, die auf Horde verweisen: DocumentRoot /usr/share/psa/horde, sowie die Freigaben des PHP-openBaseDir. Diese Verweise müssen einfach auf den Ordner von roundcube geändert werden (z.B. /usr/share/roundcube), und schon kann der übliche Webmail-Account von Plesk mit roundcube genutzt werden.

WordPress: Upload aufbohren

Andi — Sat, 18 Nov 2006 00:30:12 +0000

Die Administrationsoberfläche von WordPress bietet dem Autor die Möglichkeit, Bilder oder sonstige Dateien auf den betreibenden Server hochzuladen, um selbige anschließend in Beiträge einzubinden.
Der Datei-Upload basiert — wie WordPress insgesamt — auf PHP-Funktionen.
Die Uploadfunktion von PHP ist jedoch in gewissen Maßen beschränkt; sowohl die maximale Größe von Dateien, die über ein Skript auf den Server eingereicht werden dürfen, wie auch die maximal zulässige Ausführungszeit, die ein Skript dauern darf, ist (normalerweise) über die Konfiguration in der sog. php.ini eingeschränkt (normale Werte betragen einige Megabyte für den Upload und ca. 60-90 Sekunden für das Ausführen einer PHP-Datei).
Die genannten Beschränkungen sind völlig ausreichend, wenn lediglich Bilder oder kleinere sonstige Dateien hochzuladen sind. Sobald jedoch Audio- oder Video-Dateien ins Spiel kommen, ist das Limit schnell ausgereizt und der Upload über den Browser misslingt mit Fehlermeldungen.
Eine Möglichkeit bestünde, die Limits global in der php.ini hochzusetzen. Dies ist jedoch erstens bei Shared-Hosting-Angeboten nicht möglich, aber auch bei dedizierten Lösungen aus Sicherheits- und Performancegründen nicht ratsam.
Die Lösung liegt darin, nur für den wp-admin-Bereich die Grenzwerte anzupassen. Zusätzlich sollte bei Video-Uploads das Plugin mime-config einzusetzen, um den Upload von z.B. flv-Dateien freigeben zu können.
Zum Anheben der Maximalwerte ist wie folgt vorzugehen (Einschränkung: es muss möglich sein, PHP-Einstellungen mittels .htaccess zu ändern – dies könnte bei einigen Providern verboten sein)

Öffnen oder Anlegen einer Datei .htaccess im Verzeichnis /wp-admin/ innerhalb der WordPress-Installation.

Dort folgende Werte einfügen:

php_value upload_max_filesize "90M"
php_value post_max_size "95M"
php_value max_execution_time 3200
php_value max_input_time 3200
php_value memory_limit 35M

Damit wird das Upload-Limit auf 90 Megabyte und die Ausführungszeit auf über 50 Minuten angehoben.
Dadurch sollte auch der Upload von großen Video-Dateien möglich sein.

Hinweis: Normalerweise sollte es durch diese Anpassungen zu keinen Problemen kommen – sollte jedoch doch etwas schiefgehen: ich bin nicht schuld