Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Security PHP Programming

PHP Blogging Apps Open to XML-RPC Exploits 166

Posted by Zonk from the batten-down-the-hatches dept.
miller60 writes "A bunch of popular PHP-based blogging and content management apps are vulnerable to a security hole in the PHP libraries handling XML-RPC, which could allow a server compromise. Affected apps include Wordpress, Drupal, PostNuke, Serendipity, phpAdsNew, phpWiki and many more. The presence of the security hole in a large number of programs is among the factors leading the Internet Storm Center to warn that the environment is ripe for a major Internet security event."
This discussion has been archived. No new comments can be posted.

PHP Blogging Apps Open to XML-RPC Exploits More

PHP Blogging Apps Open to XML-RPC Exploits

Comments Filter:

  • How to patch PHP/PEAR (Score:5, Informative)

    by Anonymous Coward on Monday July 04, 2005 @06:16PM (#12981614)
    From the command line:

    pear clear-cache
    pear upgrade XML_RPC

  • Makes me happy (Score:3, Interesting)

    by orange haired boy ( 889758 ) * on Monday July 04, 2005 @06:17PM (#12981616) Homepage
    That I use Movable Type which won't be effected by this. Makes me sad that it's in PHP...since I love PHP. You can't have everything.
    • Where does it categorically state that Movable Type isn't affected?

    • Re:Makes me happy (Score:5, Insightful)

      by Sepodati ( 746220 ) on Monday July 04, 2005 @07:34PM (#12981934) Homepage
      Makes me sad that it's in PHP...since I love PHP

      This isn't a PHP vulnerability. It's another poorly written, widely used application that's vulernable because the developer fails to check external input. The vulnerability is in a PHP script that someone has written. It could have been written in any langauge; the fault is on the developer, not PHP.

      ---John Holmes...
      • You're correct. It's not a PHP problem. I'm only sad because of the association with PHP...perhaps like Microsoft is sad that Windows has some bad programs.

      • Re:Makes me happy (Score:3, Interesting)

        by 1110110001 ( 569602 )
        Pear is part of PHP. You could use PHP without Pear but in most cases you would install both.

        What's sad is that a default lib makes such a bad mistake. It uses eval on a string that's generated from user input. It doesn't matter how good you check the user-input, there's always one way for the user to bypass them. Someone needs to review the pear-code for such stupid mistakes.

        b4n

  • Question: does this effect phpbb? (Score:4, Informative)

    by RLiegh ( 247921 ) * on Monday July 04, 2005 @06:18PM (#12981622) Homepage Journal
    God knows there's a ton of free (and probably poorly maintained) php boards out there.

  • How is this a problem? (Score:5, Funny)

    by Anonymous Coward on Monday July 04, 2005 @06:20PM (#12981629)
    A blog server compromise cannot possibly lead to worse content.

    • Here's how (Score:3, Funny)

      by Anonymous Coward
      It could lead to more blogs!

    • A blog server compromise cannot possibly lead to worse content.

      Good point:
      1. Set up *vulnerable* blog server or useless forum
      2. Monitor it to see when it's compromised, and what new content gets uploaded
      3. ???
      4. Profit! (profit = time savings in obtaining new pr0n and wareZ)

  • this is news? (Score:5, Informative)

    by xWastedMindx ( 636296 ) on Monday July 04, 2005 @06:21PM (#12981632) Homepage
    wordpress released a fix for this [wordpress.org] on June 29. Changelog for 1.5.1.3 [wordpress.org]

  • Wouldn't This Be Called an XML Injection Attack? (Score:3, Interesting)

    by DanielMarkham ( 765899 ) on Monday July 04, 2005 @06:22PM (#12981635) Homepage
    I know when the same technique is used to compromise web sites with SQL in the back end it's called SQL injection. [unixwiz.net] I guess this would be XML Injection? Or perhaps PHP Injection and XML is only the wrapper. XML Injection sounds cooler.

    New wireless technology called XMax? [whattofix.com]

  • unhealthy (Score:1, Offtopic)

    by isnochys ( 566268 )
    blogging will lead to insane children
    --
    www.isnochys.com

  • Choice of words (Score:5, Funny)

    by Valacosa ( 863657 ) on Monday July 04, 2005 @06:24PM (#12981647)
    "...major Internet security event."

    A euphemism if I've ever heard one. Can I think of a better euphemism?

    "Wardrobe malfunction"

    Ah, there it is.

  • I hear sirens. Wooo. Woooo. Woo wooo. (Score:5, Funny)

    by dotslashdot ( 694478 ) on Monday July 04, 2005 @06:28PM (#12981666)
    The Internet Storm Center Reports that a high pressure coding flaw in PHP has created an error mass large enough to cause a rotation in sysadmin heads and has issued a red hat/flag Internet surf warning for all surfing sites.
  • I saw a request for phpmyadmin/index.php in one of my web server logs on July 1st around 4 AM EDT ..

    About 2 and a half hours ago i saw a request for phpmyadmin/index.php in my web server logs as well.

    I dont have PHP or any forums installed ..and in the couple years my web server has been up (somewhat aporadically though) i havent seen this request (just grepped the logs).

    So my opinion is that this attack is in the wild. Can someone confirm?
    • I just checked my logs.. and nothing. Then again I upgraded my Wordpress install the day WP came out with a fix. ;) you're best bet is to just delete the xmlrpc.php file, if you got one.

    • In the wild? (Score:3, Informative)

      by Saeed al-Sahaf ( 665390 )
      ... I saw a request for phpmyadmin/index.php in one of my web server logs...

      and...

      So my opinion is that this attack is in the wild. Can someone confirm?

      Probably just some script kiddie looking for a phpMyAdmin install not behind a password.

      • Probably just some script kiddie looking for a phpMyAdmin install not behind a password.

        And, the phpmyadmin documentation for as long as I can remember has said DONT USE PHPMYADMIN for the directory.

        Even a directory called admin is a very bad idea.
  • via this exploit. i was at my box (an old pentium II running gentoo, natch) when it happened. I heard the disk start thrashing and new something was wrong so i pulled the plug on it, before it could be turned into a spam-spewing zombie (or worse). If you don't have tripwire to verify nothing was trojaned, you should probably wipe your hard drive and reinstall.

    This appears to be the same exploit that hackers used on cowboyneal.org a few months back.

  • Use alternatives!
    Why not an app called Blosxom? [blosxom.com]
    It's tiny Perl scripts.
  • For once I don't regret using slashcode then! I'm sure there must be other reasons...

  • Don't want to bash PHP.... (Score:4, Interesting)

    by afra242 ( 465406 ) on Monday July 04, 2005 @06:35PM (#12981712)
    I really don't want to bash PHP - it seems flexible. However, after having people break into my server through phpBB and Gallery, I replaced those apps with their mod_perl equivalents, and things are working faster and more secure. Having said that, it was hard to find the Perl equivalents and even hard to find good support for it (ie. themes, etc). I'm still looking for a good Gallery replacement written in Perl.

    Obviously, security issues aren't always the language but usually come from the people who write it. It just seems to me that, since PHP is more popular for writing forums, image galleries, etc, that there are a lot more careless coders out there coding in PHP.

    phpBB is a good example of this. Every other week, they have some security issue.
    • I've waded through the php code on a few of the major php projects out there.

      I can only say that I was shocked in the first one, I was battle hardened by the time I untarred number two.

      sql injection & register_globals were my favourite finds.

      "you need to have your files set to chmod 777 for this to work" is another pearler.

      • "you need to have your files set to chmod 777 for this to work" is another pearler.

        This is necessary because mod_php runs scripts as the same user who started httpd, usually "nobody", so any files you want your PHP scripts to write to has to be world-writable. The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!

        You can already install suphp to do this, but you pay a performance penalty, since it has to start a new process for each invocati
        • Apache2 does that with the Perchild MPM. Unfortunatly this can't be used with PHP without running into insoluble threading issues. :(
          • This Perchild MPM [apache.org]? "This module is not functional. Development of this module is not complete and is not currently active. Do not use perchild unless you are a programmer willing to help fix it." Doesn't seem like something I could use for a production web site. ;)
        • mod_fastcgi allows suexec of application servers using the process manager. All the speed of mod_php/perchild hacks and more isolation and portability.

        • Re:Don't want to bash PHP.... (Score:5, Informative)

          by EvilIdler ( 21087 ) on Monday July 04, 2005 @07:51PM (#12982019)
          Thank goodness for suPHP:
          http://www.suphp.org/Home.html [suphp.org]

          My host uses this, so I don't need world-readable files and directories in my
          ~/www/ directories for each site. The webserver may run as nobody, but the
          PHP scripts run as the same user I log in as to upload the files.
        • the solution is php-fastcgi+suExec. fastcgi and not cgi, because cgi is too slow, especially for shared webhosting. suExex is used to run each php instance under the corresponding account's user.
        • This is necessary because mod_php runs scripts as the same user who started httpd, usually "nobody", so any files you want your PHP scripts to write to has to be world-writable.

          That's wrong. They only need to be writable by the user running httpd.

          The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!

          This is even worse. I don't want any root suid httpd process in my system, do you?.

          You can already install suphp to do this, but

          • That's wrong. They only need to be writable by the user running httpd.

            The distinction is only important if your sysadmin is kind enough to chown or chgrp the files for you. Otherwise, since httpd is probably running as nobody/nogroup and you're probably not in nogroup, your only choice is to make them o+w.

            And even if you can make them writable only by the user running httpd, that still means anyone else who shares the web server can overwrite your files, because their scripts run with the same permission

        • This is necessary because mod_php runs scripts as the same user who started httpd, usually "nobody", so any files you want your PHP scripts to write to has to be world-writable. The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!

          There's an answer for this - Metux MPM [metux.de] and it allows Apache to run as any user that owns the site with minimal performance degredation. (Obviously, there is SOME degredation!)

          Unlike SuPHP, which runs a separate

        • The problem would go away if mod_php could just run PHP scripts as their owners, instead of as the user running httpd!

          This is a simple permissions problem that's common to many unix apps. chmod 0777 is rarely the right answer to the problem (it's like swatting a fly with a sledgehammer).

          It's often easier to simply chown the directory containing the scripts to the web server's user. That way, local users cannot use that web directory illicitly.

          The suid stuff for php and mod_perl is kind of crap. M

    • The reason that noone's hacked the Perl equivs. is that not even the hackers want to code in Perl.

      (Jus' trolling. I'd write in BrainFuck [muppetlabs.com] over Perl.)

    • Re:Don't want to bash PHP.... (Score:4, Insightful)

      by Saeed al-Sahaf ( 665390 ) on Monday July 04, 2005 @06:55PM (#12981796) Homepage
      Obviously, security issues aren't always the language but usually come from the people who write it. It just seems to me that, since PHP is more popular for writing forums, image galleries, etc, that there are a lot more careless coders out there coding in PHP.

      Exactly. And, this is a very important point that all the Perl / Ruby / Python / Whatever FANBOYS like to ignore.

      phpBB is a good example of this. Every other week, they have some security issue.

      Come on now, you know very well that's an exageration.

      • Re:Don't want to bash PHP.... (Score:1, Insightful)

        by Anonymous Coward
        phpBB is a good example of this. Every other week, they have some security issue.

        Come on now, you know very well that's an exageration.

        Seriously, at least once a week.
    • The biggest problem I have always had with PHP is that it has never struck me like it was developed by a team and community that had any genuine sense of direction like the Perl and Python teams. IMO, what'd be a real coup for the Python community would be to really work on getting mod_python's PSP support distributed around to as many hosts as possible. It's a lot easier to write good code in Python than it is in PHP.
    • You don't need a perl replacement for Gallery.
      Choose G2 (Gallery 2), you will notice that it's a whole new application. It has no code in common with Gallery 1. And all inputs are checked thorougly.
      It's the cleanest PHP code I've ever seen. No spaghetti code. See: G2 Development Guidelines [menalto.com]. (G2 is almost finished, it's in its last beta cycle)

    • there are a lot more careless coders out there coding in PHP.

      That's exactly the issue. This isn't a PHP vulnerability. It's a poorly written script that doesn't check input properly.

      It annoys me to see PHP blamed for stuff like this when it's poor programmers that should be blamed. PHP is just easy to learn, so there are a lot of bad programmers out there creating scripts like this.

      I can't honestly say the xml-rpc scripts are bad because of this one issue, though, as I've never used it and only look

      • Re:Don't want to bash PHP.... (Score:4, Insightful)

        by Tassach ( 137772 ) on Tuesday July 05, 2005 @12:19AM (#12982956)
        there are a lot more careless coders out there coding in PHP.
        That's exactly the issue. This isn't a PHP vulnerability. It's a poorly written script that doesn't check input properly
        I'd say while it isn't exactly a PHP vulnerability it is an inherent PHP design flaw, which renders PHP dangerous (if not useless) for it's intended user community.

        To make an analogy, let's look at C. The C language was invented for systems programming, and it excels in that role -- C has been the language of choice for low level hacking for 20+ years. There's a damn good reason that OS kernels and device drivers are written in C -- it gives an expert programmer near-total control of the hardware.

        However, this very power is C's downfall when it's used for general application programming. In the hands of anyone other than an expert, C is dangerous because it places too much demand on the programmer to do things "the right way", rather than preventing those errors from ever happening in the first place. It's trivially easy to introduce a buffer overflow or a memory leak into a C program, because the language intentionally does not do bounds checking or garbage collection. Languages which are intended for developing applications include these features -- they intentionally introduce run-time overhead so that the programmer can concentrate his attention on the application's logic rather than working around the language's shortcomings.

        Having to manually write code to check each and every user input in an application is a horribly inefficent use of programmer time, and is prone to errors of omission. The development process is FAR more efficent if the language does this kind of housekeeping for the programmer automatically and transparently. This principle is doubly true for a scripting language like PHP, which is intended to be used by people who don't have a solid software engineering background.

    • Re:Don't want to bash PHP.... (Score:2, Interesting)

      by Anonymous Coward

      I really don't want to bash PHP - it seems flexible.

      You should bash PHP. It's an awful language. I don't think I'd call it flexible. I might call Lisp flexible. Try sorting an array of objects by comparing a field from each object in PHP. Now try it in Ruby. But that's not important at the moment, after all, we all had to start somewhere.

      However, after having people break into my server through phpBB and Gallery, I replaced those apps with their mod_perl equivalents

      This has nothing to do with PHP

    • I replaced those apps with their mod_perl equivalents, and things are working faster and more secure. Having said that, it was hard to find the Perl equivalents

      After admitting how hard it was to find them, you're going to have to get a dopeslap if you don't tell us what they are. ;)

      As a mod_perl hacker about to install Gallery, I'm quite interested.
  • PostNuke has a serious security vulnerability? I am SOOOOO surprised!
    • Normally I'd agree, but in this case, it's a PHP script written by someone else that's vulnerable. Any application using the xml-rpc server script (a plain old PHP script) is vulnerable becaus the developer didn't check user input.

      ---John Holmes...

  • Why PHP? (Score:3, Insightful)

    by mcc ( 14761 ) <amcclure@purdue.edu> on Monday July 04, 2005 @06:41PM (#12981736) Homepage
    It seems like there's a lot of security advisories along these lines lately and they mostly seem to revolve around PHP site engines. Why PHP? Why not perl, or python, or Ruby?

    Is there something about PHP that's making these things likely as opposed to some other language (which seems unlikely, there's plenty of simple mistakes you can make just as easily in perl, i.e. poor scrubbing of regexp/sql content), or is it just that there are more inexperienced people writing PHP code out there, or is it just that PHP site engines are getting installed by more security-inexperienced people, or are the PHP exploits getting publicized more, or am I just noticing them more?

    What's going on here?

    • Re:Why PHP? (Score:5, Insightful)

      by eddy the lip ( 20794 ) on Monday July 04, 2005 @07:18PM (#12981892)
      ...or is it just that there are more inexperienced people writing PHP code out there...

      Bingo...PHP has a very low barrier to entry. Add to that that it's mainly used in a networked environment, and you're going to have problems. You could code up this exact same problem in perl - the only difference is that by the time you knew enough to get input from the network into your script and passed to eval, you'd probably have had it beaten into you that it's a crime punishable with flogging.

      There may be cultural differences at work here as well. XML-RPC is in PEAR and often recommended as a good way of implementing this kind of functionality. This isn't a bug-free guarantee, but there should be some minimal level of quality implied by that. Passing untrusted input directly to eval is gross negligence, and it sort of amazes me that no one noticed this before. I've read a lot of PHP and a lot of perl. It's easy to find crap, bug-riddled code in both. The main difference seems to be that crappy perl code isn't tolerated near so quickly. Crappy PHP code becomes a flagship application.

    • Re:Why PHP? (Score:4, Insightful)

      by Saeed al-Sahaf ( 665390 ) on Monday July 04, 2005 @07:27PM (#12981918) Homepage
      ...Is there something about PHP that's making these things likely as opposed to some other language...

      See below.

      ...or is it just that there are more inexperienced people writing PHP code out there...

      Yes.

      ...or is it just that PHP site engines are getting installed by more security-inexperienced people...

      Yes.

      ...or are the PHP exploits getting publicized more...

      Yes.

      ...or am I just noticing them more...

      Yes.

    • I'd attribute it to the fact that PHP is a more popular platform, more people programming in PHP means more software using PHP, more software using PHP means more users running that software, more PHP web apps running means more people trying to exploit those web apps.

      The fact that there are more inexperience people writing PHP code is something that contributes to PHP web apps as a whole, but not really to these recent big exploits particularly.
  • If I read this correctly the venerability lies in how these blogging programs fetch RSS feeds from various places in that they don't check the input first. What are the chances that any popular blogs will link to sites likely to exploit this? And know how?

    A worm is very unrealistic for the simple reason that blogging isn't popular enough and crossed linked well enough. Although there are junctions in blogging networks very few automated blogs pull from these areas, they are primarily designed for user us

    • "If I read this correctly the venerability lies in how these blogging programs fetch RSS feeds from various places in that they don't check the input first. What are the chances that any popular blogs will link to sites likely to exploit this? And know how?"

      XML-RPC, actually -- or is that what you meant to type when you wrote "RSS"? It's push vs. pull. Both use XML, but XML-RPC deals with the art of posting to a blog (with a tool like w.bloggar, for example) using the Blogger API, the MT API, and so o

  • From the s9y forums:

    http://www.s9y.org/forums/viewtopic.php?t=2034 [s9y.org]

    Save yourself the hassle of doing a complete upgrade by simply downloading the new version an only copying the files from bundled-libs/XML/*

  • it amazes me people still use that thing. Scary. Nasty. Creepy.
    Should be forbidden from php.

    Ironically, didn't the Windows Logo Certification forbid people from using "system"?

    (ouch)
  • XOOPS has released an updated version [xoops.org] and patch on July 2'nd.
  • ... that right above this article in /. is another article titled "Anatomy of a Hack" which basically describes how one can h4xx0r b0x3n?
  • As I've always thought, running PHP is the same as hanging a "Root Me" sign outside your server.
  • YAZBS (Yet Another Zonk Blogging Story)
  • Without being explicit, don't count your chickens if you're using Perl based CMSs. I'm aware of issues with at least one of the main Perl based CMSs which could ultimately lead to a full server compromise and am currently in talks with their developers about how to fix it. The last thing any sys admin, web developer or web site owner should do, is attempt to sit on their laurels. Yes, code will have bugs. Go forth and audit.

  • Lessons to be learnt? (Score:2, Informative)

    by Anonymous Coward

    Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

    From a design perspective, it's really bizarre the way they've chosen to use eval() [php.net] in the first place.

    For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, th

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close