As Heise Online conveys today, a group named Neo Security TEAM has published an advisory stating several severe security vulnerabilities in Wordpress. The most important issue is an insufficient filtering of comments, which allows so-called cross site scripting attacks. On WP installations with unmoderated comments this may result in the effect that an attacker gains full administrative access to the blog.
Several files don’t check whether they are called directly, resulting in error messages being displayed that contain the full server path to the file. This information, again, can then be misused for further attacks against either the blog or even the complete webserver. Additionally, the wp-includes/ directory is open to a directory listing, if the directory privileges are set insufficiently (e.g. 755 on a unix machine, resulting in world read rights for the directory index).
All errors can be reproduced in all wordpress versions up to and including the latest version 2.0.1, and a fix is currently not yet available. So you are on your own if you want to take countermeasures against these issues:
- On a unix machine, apply CHMOD 711 to the wp-includes/ directory, or place and empty index.php into that folder (the latter is the only one applicable on a windows server).
- Moderate all your comments to prevent the XSS attacks, until an official patch is available
- Edit your wp-comments-post.php and replace the four trim() operations in that file with appropriate htmlentities(trim()) calls.
- Check which files don’t test direct calls and apply solutions like
if (eregi('Name-of-the-Script.php', $_SERVER['PHP_SELF'])) die('You are not allowed to call this page directly');to them. This measure should be taken only if you know what you are doing, as it may result in a broken blog installation.
I have put up a small wp-fix.zip for a quick download, it contains a fixed WP 2.0.1 wp-comments.post.php file and an empty index.php file to circumvent the two most important issues. Just download and extract the ZIP file to your wordpress installation.
Heiko meint
Gute Info. Danke!
Phogex meint
Ein interessanteres Problem ergibt sich in meinen Augen in der Verwendung von automatischen Redirects per XSS.
Mit etwas Glück lässt sich da sowohl die PHP-Session auslesen als auch ein komplettes Blog “übernehmen”. Denn selbst wenn ein mit XSS manipulierter Benutzername von WordPress in den Kommentaren gefixt wird, kann er trotzdem noch im Original z.B. von einem Plugin in den Cookie geschrieben werden.
Und bei einer “Recent Comments” Anzeige dürfte das Problem deutlich werden o_O
CountZero meint
gerade da liegt soweit ich das problem verstehe der hase im pfeffer - der blog-admin ruft mit seinen adminrechten nen post ab, dessen kommentare ein solches manipulatives script enthalten, und schwups sind die adminrechte mal eben zu nem angreifer rübergereicht. genau so funktionieren XSS-attacken ja.
die anderen probleme, etwa anzeige der verzeichnisinhalte auf schlecht konfigurierten webservern, sind eher nebensächlich, können aber nem angreifer mehr informationen verraten als einem lieb ist und daher einen hack erleichtern.
Alex meint
Mal ne andere Frage. Kann den überhaupt wer schädlichen HTML oder Javascriptcode in Wordpress- Kommentaren ausführen. Wenn ich mich nicht täusche ist dies ohnehin nicht wirklich möglich, ausser derjeneige hat Adminrechte. Oder liege ich da falsch?
CountZero meint
richtig. das ist vorerst nur ein schneller workaround und kann keine endgültige lösung sein.
Phogex meint
Also wenn der Fix darin besteht, Name, Mail etc mit htmletities() zu bearbeiten ist dieser Umstand logisch. Dann werden weder Umlaute noch jegliche (erlaubten) anderen HTML-Sachen korrekt dargestellt.
Da muss man auf eine vernünftige Lösung warten seitens WordPress, die schädliche HTML-Tags vernünftig löscht.
Alex meint
Dein Plugin verwende ich bereits, trotzdem kommen diese Fehler zustande. ist nicht bei den einzelnen Überschriften oder Artikeln, sondern nur wenn wer über das Kommentarfeld schreibt.
CountZero meint
Ich verwende wegen der Sonderzeichen eh das CleanUmlauts-Plugin in der von mir verwursteten fehlerbereinigten Fassung, und damit tritt eine Störung der Umlaute eh nicht mehr auf, da diese serverseitig vorm Rendern der Seite in HTML-Entities umgewandelt werden. zur 404-CleanUmlauts-Version
Pingbacks & Trackbacks