• https://news.netcraft.com/archives/2005/07/04/php_blogging_apps_vulnerable_to_xmlrpc_exploits.html
    “Many popular PHP-based blogging, wiki and content management programs can be exploited through a security hole in the way PHP programs handle XML commands. The flaw allows an attacker to compromise a web server, and is found in programs including PostNuke, WordPress, Drupal, Serendipity, phpAdsNew, phpWiki and phpMyFAQ, among others.”

    What are WP users on shared servers supposed to do? “Disabling XML-RPC features is the recommended workaround” – How to do?

    If you control the server, try this:

    pear clear-cache
    pear upgrade XML_RPC

Viewing 5 replies - 16 through 20 (of 20 total)
  • I don’t understand why WordPress upgrades are only provided as a zip/tgz of the entire thing. Upgrades could be made significantly smaller and easier if incremental patches were provided, especially for security releases. You could have upgrade.php run the patch for those without shell access.

    Those with a heavily modified installation would first need to take a diff -ur of their files against the stock WordPress of their current version, reverse apply it (or just reinstall the stock), then apply the upgrade patch, then reapply their modification patch. It shouldn’t be rocket science to do most of that automatically too, even down to fetching the full tgz of the current version as required. The system as it stands is needlessly painful.

    As a start, I’ve made some patches for the latest upgrade and the one before. If you have shell access (and it’s a unix box) you can apply them by copying the patch file to your wordpress root, cd there, and type patch -p1 <wordpress-xxx-to-xxx.patch

    Both patches applied cleanly on my system, but your mileage may vary and no warranty, so I strongly advise you take backups before doing this.

    As I said in another thread, diffs and patches are far more complicated for the bulk of WordPress users. The time it takes to bundle “update only” archives is not the issue — it’s a matter of support. By having one download, it makes it super easy for all of volunteer support providers to talk to users of all skill levels. It makes it easy for new users to follow-along in support discussions about what they need to do.

    People who understand diffs can look at the changelog and determine what they need to do.

    People who do not understand diffs are likely not modifying core files, so a full re-install is no more challenging than an incremental upgrade.

    @ the original thread

    WordPress and PHP’s vunerabilities are unreleated. The pear commands given will in no way affect WordPress. The article above is entirely incorrect in listing WordPress as a vunerable software because of the way that PHP handles XMLRPC.

    WordPress uses its own builtin XMLRPC server, and it is just coincidence that these vunerabilities were discovered at the same time.

    Okay, so I have 1.5. I did some sort of “security upgrade” not all that long ago where I changed a line in template-functions-category.php in the wp-includes directory. I think that corresponded roughly to 1.5.1? (file changed 6-7-2005) How do I handle this? Do I follow the above instructions? Or do I have to do more?

    kickass: if you have not modified any core files (beyond the application of a previous security fix), the easiest solution is to do a full upgrade. Upgrading WordPress has all the instructions.

Viewing 5 replies - 16 through 20 (of 20 total)
  • The topic ‘PHP Blogging Apps Open to XML-RPC Exploits’ is closed to new replies.