Slashdot Mirror


PHP Blogging Apps Open to XML-RPC Exploits

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."

166 comments

  1. How to patch PHP/PEAR by Anonymous Coward · · Score: 5, Informative

    From the command line:

    pear clear-cache
    pear upgrade XML_RPC

    1. Re:How to patch PHP/PEAR by xWastedMindx · · Score: 0, Offtopic
      or...
      apt-get update; apt-get dist-upgrade
    2. Re:How to patch PHP/PEAR by iamdrscience · · Score: 1

      -bash: apt-get: command not found -bash: apt-get: command not found

    3. Re:How to patch PHP/PEAR by ciroknight · · Score: 1

      Who said to use Apt-get?

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    4. Re:How to patch PHP/PEAR by cortana · · Score: 1

      Upgrade your distribution.

      Oh wait, Debian's security support is still broken. Never mind.

    5. Re:How to patch PHP/PEAR by ScytheBlade1 · · Score: 3, Informative

      Well that was easy.

      server bin # ./pear upgrade XML_RPC
      downloading XML_RPC-1.3.1.tgz ...
      Starting to download XML_RPC-1.3.1.tgz (25,310 bytes)
      .........done: 25,310 bytes
      upgrade ok: XML_RPC 1.3.1


    6. Re:How to patch PHP/PEAR by pcraven · · Score: 1

      Too bad my php install is broken. Never figured it out:

      [root@server2 ~]# pear clear-cache /usr/local/bin/php: error while loading shared libraries: libldap.so.2: cannot open shared object file: No such file or directory

      I'm not sure why it doesn't like my ldap library. I've tried uninstalling, reinstalling, etc. Running FC3.

      I actually have PHP pages though.

    7. Re:How to patch PHP/PEAR by ryanov · · Score: 1

      ldd -v /usr/local/bin/php

    8. Re:How to patch PHP/PEAR by Denis+Lemire · · Score: 1

      cvsup ~/ports-supfile
      portupgrade pear-XML_RPC

  2. How long.. by Anonymous Coward · · Score: 0

    Worm anyone?

    1. Re:How long.. by Krankheit · · Score: 2, Funny

      A worm is not likely to be interested. Worms have a very simple nervous system (one "string"). Their motor skills are poor. Their central nervous system does not meet recommended requirements, but I am worried most that there is no keyboard compatible with worms. However, Google has developed a system to allow the pigeons they employ to use computers to rank search result relevence. A modified version could work with an earthworm.

      --
      Powered by caffeine and sugar; BSD
  3. Makes me happy by orange+haired+boy · · Score: 3, Interesting

    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.

    1. Re:Makes me happy by BiggyP · · Score: 0

      Where does it categorically state that Movable Type isn't affected?

    2. Re:Makes me happy by orange+haired+boy · · Score: 0

      In the Story. Movable Type is written in Perl...not PHP. The problem is in the PHP XML-RPC libraries.

    3. Re:Makes me happy by BoneFlower · · Score: 4, Funny

      Well, Perl tends to be invulnerable to PHP flaws in the vast majority of situations.

    4. Re:Makes me happy by hostyle · · Score: 1

      Movable Type was written in Perl last time I checked. These are PHP library vulnerabilities.

      --
      Caesar si viveret, ad remum dareris.
    5. Re:Makes me happy by BiggyP · · Score: 1

      erm, oops, indeed it is, i'm not sure why i assumed it was PHP.

    6. Re:Makes me happy by Sepodati · · Score: 5, Insightful

      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...

    7. Re:Makes me happy by orange+haired+boy · · Score: 1

      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.

    8. Re:Makes me happy by onlyjoking · · Score: 1

      Read the article. It IS a PHP vuln. PHP's XML-RPC libraries are faulty.

    9. Re:Makes me happy by Anonymous Coward · · Score: 0

      You're an idiot, too true.

    10. Re:Makes me happy by Sepodati · · Score: 5, Informative

      I read the vulnerability which links to the sourceforge.net page that has the source code of this "library". It's a PHP script that you include() into other PHP scripts to use the functions/methods defined. The developer of this PHP script used eval() in an incorrect manner.

      Unless you have another article that shows the PHP XML-RPC Functions to be vulnerabile, this is not a PHP vulnerability.

      ---John Holmes...

    11. Re:Makes me happy by 1110110001 · · Score: 3, Interesting

      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

    12. Re:Makes me happy by iwan-nl · · Score: 1

      So you're saying the pear code should be peer reviewed? ;)

      --
      I'm trying to improve my English. Please correct me on any spelling/grammar errors in this post.
    13. Re:Makes me happy by noz · · Score: 1

      Excellent point!

      "That I use Movable Type which won't be effected by this."

      Please learn the difference.

  4. Question: does this effect phpbb? by RLiegh · · Score: 3, Informative

    God knows there's a ton of free (and probably poorly maintained) php boards out there.

    1. Re:Question: does this effect phpbb? by iamdrscience · · Score: 4, Informative

      No, PHPBB doesn't use either of the PHP XML RPC libraries that have been compromised because, well, PHPBB doesn't use XML at all.

    2. Re:Question: does this effect phpbb? by Anonymous Coward · · Score: 0

      I hope not as I just did an upgrade of phpbb last night, only to come across an unsuccessful install. However, all is working fine now.

    3. Re:Question: does this effect phpbb? by Anonymous Coward · · Score: 0

      this one? no, but there are dozen of other vulnerabilities for phbb : - )

    4. Re:Question: does this effect phpbb? by Anonymous Coward · · Score: 1, Informative

      No, but phpBB had a bug of its own recently - another hole in their highlight-handling code, very much like the one in 2.0.10 that allowed for Santy. Fixed in 2.0.16.

    5. Re:Question: does this effect phpbb? by cecil36 · · Score: 1

      The link below is more detailed information of the phpBB exploit.

      http://www.phpfreaks.com/articles/245/0.php

    6. Re:Question: does this effect phpbb? by iamdrscience · · Score: 1

      ...and plenty of security patches to go with them. For the most part PHPBB does a good job, although it's difficult to compare the number of vulnerabilities between board because of the X-factor popularity, i.e. do they have more vulnerabilites than other board just because they're more popular or because they're worse at programming too.

      What I do know is that I once found a flaw in another PHP board I won't name and rather than fix it, I was told by the developers that they don't consider it a bug. Now, granted this bug didn't let and attacker execute arbitrary PHP or anything but it did allow them to hijack the sessions of anybody on the board and generally wreak havoc.

    7. Re:Question: does this effect phpbb? by 1110110001 · · Score: 1

      The problems is the phpBB guys don't get it. First of all the rewrote phpBB and still have an awfull structured code. And they use things like serialized strings in cookies, but they don't think it's their fault if it raises problems.

      b4n

    8. Re:Question: does this effect phpbb? by GraemeDonaldson · · Score: 1

      1. Fork it.
      2. Fix it.
      3. ???
      4. Profit!!!

      --
      I think, therefore I am. I think?
  5. How is this a problem? by Anonymous Coward · · Score: 5, Funny

    A blog server compromise cannot possibly lead to worse content.

    1. Re:How is this a problem? by Alwin+Henseler · · Score: 1

      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)
    2. Re:How is this a problem? by Ravatar · · Score: 1

      If anything, the exploiter will remove the blog from the face of the earth, saving us all a tiny shred of annoyance.

  6. this is news? by xWastedMindx · · Score: 5, Informative

    wordpress released a fix for this on June 29. Changelog for 1.5.1.3

    1. Re:this is news? by iamdrscience · · Score: 1

      It's news because just because something was patched by the developers 5 days ago doesn't mean that every user has patched their installations. I'm rather certain that the vast majority of people running these programs haven't patched them (or at least hadn't patched them until they read this slashdot post).

    2. Re:this is news? by tyagiUK · · Score: 1

      Kudos to the Wordpress guys for releasing a fix before the PHP exploit was widely broadcast. The upgrade was simple and fast.

      Obviously, those Black Hats who wanted to know this stuff would already know it. The early release of this information to PHP-based developers did, however, limit the damage done by worms based on the exploit (see PHPBB exploit in December 2004).

      --
      Contribute to the online videogame encyclopedia: GamerWiki
    3. Re:this is news? by deathazre · · Score: 1

      now, honest question here, is this the same exploit that has had gentoo hard-masking wordpress for some time now?

      --
      Karma: Negative (Mostly affected by dorm trolling)
    4. Re:this is news? by 1110110001 · · Score: 1

      Yeah and Tobias Schlitt of Pear posted about it on the same day in his blog: http://www.schlitt.info/applications/blog/index.ph p?/archives/349-PEARXML_RPC-Security-vulnerability !.html and other PHP software, like Bitflux http://blog.bitflux.ch/archive/2005/06/29/bxcms-1- 2-1-security-bugfix-release-codename-not-our-fault -2.html, was patched on June 29th too.

      http://www.php.net/ had a news entry about the issue last week. So everyone should have patched their pear-libs in the meanwhile.

      b4n

    5. Re:this is news? by Anonymous Coward · · Score: 0

      The Gentoo security people are just being stupid paranoid, the last "vulnerability" I saw them bug out about was that WordPress author's can post HTML to a website. That's like saying FTP being able to modify files is a security problem.

    6. Re:this is news? by scotty · · Score: 1

      WordPress' patch has nothing to do with vulnerability in Userful Inc's XML-RPC library. WordPress uses IXR. However, the fixes in WP 1.5.13 is related, i.e. not escaping the data coming from XMLRPC calls, which might result SQL inject, but not PHP script injection like Userful Inc's one.

    7. Re:this is news? by akulbe · · Score: 1

      Paranoid? perhaps. Stupid? I don't think so. Perhaps some things were lost in communication, with past issues. I'm not sure. I know that the WordPress folks are doing a good job of keeping on top of things. I'm the new Gentoo maintainer for WordPress, and I personally think that paranoia is an appropriate response. Better that, than be responsible for your userbase getting their boxes hacked.

  7. Wouldn't This Be Called an XML Injection Attack? by DanielMarkham · · Score: 2, Interesting

    I know when the same technique is used to compromise web sites with SQL in the back end it's called SQL injection. 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?

  8. Here's how by Anonymous Coward · · Score: 3, Funny

    It could lead to more blogs!

  9. unhealthy by isnochys · · Score: 1, Offtopic

    blogging will lead to insane children
    --
    www.isnochys.com

  10. Choice of words by Valacosa · · Score: 5, Funny

    "...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.

    --
    "Live as if you'll die tomorrow." Ridiculous. You could die later today.
    1. Re:Choice of words by haakondahl · · Score: 1
      Can I think of a better euphemism? "Wardrobe malfunction"
      Actually, I prefer your meta-euphemism.
      --
      Don't trust anyone under thirty.
    2. Re:Choice of words by Anonymous Coward · · Score: 0

      I've always liked "The dictator has no clothes".

  11. I hear sirens. Wooo. Woooo. Woo wooo. by dotslashdot · · Score: 5, Funny

    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.

  12. XML-RPC sucks. by Anonymous Coward · · Score: 0, Flamebait

    It always did. It always will.

  13. noticed something in my webserver logs by backslashdot · · Score: 2, Interesting

    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?

    1. Re:noticed something in my webserver logs by xWastedMindx · · Score: 1

      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.

    2. Re:noticed something in my webserver logs by Anonymous Coward · · Score: 0

      I can confirm. I run a private server where the only user is mostly me. And even I got some signs of the attack, for example these folders are trying to be accessed: /var/www/forum /var/www/phpBB /var/www/forums /var/www/phpbb /var/www/board /var/www/boards /var/www/phpBB2 /var/www/msgboard /var/www/foros /var/www/portal

    3. Re:noticed something in my webserver logs by sleeper0 · · Score: 1

      exploit doesnt effect PHPBB, so this is unrelated - there are plenty of other phbb exploits. Similar to the grandparent, those were unrelated scans for an unprotected base php install.

      as far as it being "in the wild" since the web page explains exactly how to perform it in a few lines of code, that should qualify as in the wild.

    4. Re:noticed something in my webserver logs by Anonymous Coward · · Score: 0

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

      Yes, it is your opinion by virtue that you were the one who said it. Unless you usually say things that aren't your opinion, your statement was correct.

      HTH. HAND.

  14. That's it, I'm blogging this! by VeganBob · · Score: 0, Redundant
    --
    Being funny is my sig nature.
  15. i was hacked yesterday by larry+bagina · · Score: 2, Funny
    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.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

    1. Re:i was hacked yesterday by DrSkwid · · Score: 3, Insightful

      sounds like you are a bit paranoid thewrre larry me old beauty

      not quite got a handle on locking your box down so your web server can only write to specific directories huh, well, you might learn now.

      Not running your webserver chrooted ? well, you might learn now.

      Wiping your hard drive is very Windows.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    2. Re:i was hacked yesterday by Anonymous Coward · · Score: 2, Funny

      Let's think about this for a second.

      Pentium II.. Gentoo.. Wiped.

      Ouch. I wouldn't wanna' watch him reinstall that.

    3. Re:i was hacked yesterday by myov · · Score: 2, Informative

      If a box is compromised, the only way to know you have removed everything is to wipe it and reinstall from clean media. It doesn't matter what platform.

      --
      I use Macs to up my productivity, so up yours Microsoft!
    4. Re:i was hacked yesterday by Anonymous Coward · · Score: 1, Informative

      "If you don't have tripwire to verify nothing was trojaned, you should probably wipe your hard drive and reinstall."

      Wiping your hard drive is very Windows.

      Maybe so, but in this situation it's also very right. If you have no way to verify any executables, you can't trust them.

      BTW, it's easier to start with something that's already locked down. ;)

    5. Re:i was hacked yesterday by mbyte · · Score: 1

      P2 ? Thats high end hardware ... i've got gentoo running on a Pentium (1 that is) with 120 Mhz, functioning as email server ... as long as you distcc the hell out of it, it works like a charm :)

    6. Re:i was hacked yesterday by DrSkwid · · Score: 1

      lol, so wrong

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  16. Re:I hear sirens. Wooo. Woooo. Woo wooo. by jd · · Score: 1

    I thought the high pressure region in PHP was responsible for fine weather but storms later.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  17. On the insecurity of PHP blogging by Haiku+4+U · · Score: 2, Informative

    Use alternatives!
    Why not an app called Blosxom?
    It's tiny Perl scripts.

    1. Re:On the insecurity of PHP blogging by subtropolis · · Score: 1

      If there's one thing that 's about as worrying as debugging through fifty perl scripts *cough*discusware*cough* it's wading through a thousand tiny ones.

      --
      "Our interests are to see if we can't scale it up to something more exciting," he said.
  18. Re:Wouldn't This Be Called an XML Injection Attack by haakondahl · · Score: 1
    XML Injection sounds cooler.
    My rig's a dual-cooled PPC 975 with XML Injection and a Slashdot gearshift knob. Yea-a-a-ah, Buddy.
    --
    Don't trust anyone under thirty.
  19. slashcode it is then by grqb · · Score: 1

    For once I don't regret using slashcode then! I'm sure there must be other reasons...

  20. Don't want to bash PHP.... by afra242 · · Score: 3, Interesting

    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.

    1. Re:Don't want to bash PHP.... by DrSkwid · · Score: 1

      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.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    2. Re:Don't want to bash PHP.... by KhaZ · · Score: 2, Funny

      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 over Perl.)

      --
      - - - -

      KickingDragon

    3. Re:Don't want to bash PHP.... by Saeed+al-Sahaf · · Score: 3, Insightful
      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.

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    4. Re:Don't want to bash PHP.... by Anonymous Coward · · Score: 1, Insightful

      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.

    5. Re:Don't want to bash PHP.... by Mr2001 · · Score: 2, Informative

      "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 invocation.

      mod_php's advantage is that it runs scripts in the httpd process, so of course they have the same permissions as the user running httpd. But it could be changed: spawn a new process for each unique user who owns a PHP script (setuid to that user), and have the main httpd process communicate to the appropriate user's child process via a local socket whenever it's time to run one of their scripts. Then you only have to spawn one process for each user, and once that's done, the scripts could run just as fast as they do now.

      --
      Visual IRC: Fast. Powerful. Free.
    6. Re:Don't want to bash PHP.... by cortana · · Score: 1

      Apache2 does that with the Perchild MPM. Unfortunatly this can't be used with PHP without running into insoluble threading issues. :(

    7. Re:Don't want to bash PHP.... by Fweeky · · Score: 1

      mod_fastcgi allows suexec of application servers using the process manager. All the speed of mod_php/perchild hacks and more isolation and portability.

    8. Re:Don't want to bash PHP.... by Mr2001 · · Score: 1

      This Perchild MPM? "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. ;)

      --
      Visual IRC: Fast. Powerful. Free.
    9. Re:Don't want to bash PHP.... by uss_valiant · · Score: 1

      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. (G2 is almost finished, it's in its last beta cycle)

    10. Re:Don't want to bash PHP.... by EvilIdler · · Score: 4, Informative

      Thank goodness for suPHP:
      http://www.suphp.org/Home.html

      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.

    11. Re:Don't want to bash PHP.... by Sepodati · · Score: 1

      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 looked at the source after this story was posted.

      ---John Holmes...

    12. Re:Don't want to bash PHP.... by uss_valiant · · Score: 1

      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.

    13. Re:Don't want to bash PHP.... by Mr2001 · · Score: 5, Funny

      BTW, suphp is my favorite way to check the overall status of an HP-UX system.

      # suphp
      Not much, runnin' some processes. 'Sup with you?

      --
      Visual IRC: Fast. Powerful. Free.
    14. Re:Don't want to bash PHP.... by Anonymous Coward · · Score: 2, Interesting

      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 itself. Your server is no more secure today than it was last week.

      The problem is a simple one: PHP is popular, so it attracts a lot of programmers. I would estimate that about 80% of all programmers (open-source or otherwise) are just incompetent, so phpBB, WordPress, etc., are written VERY poorly.

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

      Again, it has NOTHING to do with the language. Take a look at phpBB's source code. Take a look at the code that contained the security hole patched recently:

      $message = str_replace('\"', '"', substr(@preg_replace('#(\>(((?>([^><]+|(?R)))*)\<) )#se', "@preg_replace('#\b("
      . str_replace('\\', '\\\\', addslashes($highlight_match)) . ")\b#i', '<span style=\"color:#" . $theme['fontcolor3'] . "\"><b>\\\\
      1</b></span>', '\\0')", '>' . $message . '<'), 1, -1));

      phpBB is fulll of crap like that. This is what you're trusting your server security to. "Are you feeling lucky"?

    15. Re:Don't want to bash PHP.... by geekdreams · · Score: 1
      Doesn't seem like something I could use for a production web site. ;)
      Neither does Apache 2.
      --
      ^ obsolete.
    16. Re:Don't want to bash PHP.... by onlyjoking · · Score: 1

      No, the REAL solution is Persistent Perl.

    17. Re:Don't want to bash PHP.... by Anonymous Coward · · Score: 0

      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.

      Just create a separate daemon that runs as a separate user id (daemontools is perfect for this, no special daemon programming required on your part), and have the web process communicate with the daemon using a simple well-defined protocol over a socket. Then if someone takes over the web server, they can only do whatever that protocol allows them to.

      These problems were solved years ago. Just partition your processes. Ignorance is not an excuse.

    18. Re:Don't want to bash PHP.... by otis+wildflower · · Score: 1

      You should bash PHP. It's an awful language.

      Thanks for validating my own budding prejudice!

      Seriously, data 'structures' and OO in PHP are teh unfun. Perl may look like line noise but at least it's _meaningful_ line noise.. $@% are distinct sigils, though () and [] could be differentiated better.

    19. Re:Don't want to bash PHP.... by TardisX · · Score: 1

      I'm still looking for a good Gallery replacement written in Perl.

      Apache::Gallery is awesome.

      --

      Command attempted to use minibuffer while in minibuffer
    20. Re:Don't want to bash PHP.... by Tassach · · Score: 3, Insightful
      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.

      --
      Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
    21. Re:Don't want to bash PHP.... by Santana · · Score: 1
      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 you pay a performance penalty, since it has to start a new process for each invocation.

      That means installing another vulnerable point in your system. You don't want that unless you're looking for trouble.

      --
      The best way to predict the future is to invent it
    22. Re:Don't want to bash PHP.... by mcrbids · · Score: 1


      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 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 process for each site hit, this runs separate apache child processes, each child behaving in much the same was as Apache would, anyway, only per UID rather than per server.

      This results in more child processes hanging around, but providses good performance when a particular user's site gets hit hard.

      It supports chroot jails. This is the feature for which I will *finally* move to Apache 2.0, once I complete my migration testing!

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    23. Re:Don't want to bash PHP.... by Mr2001 · · Score: 1

      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 permissions as yours.

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

      httpd itself wouldn't have to be suid root; only the per-user process it spawns would.

      --
      Visual IRC: Fast. Powerful. Free.
    24. Re:Don't want to bash PHP.... by ajayrockrock · · Score: 1

      I have nothing to add other then it's 1:45am, I'm tired, and you're joke is crackin' me up.

      --ajay

    25. Re:Don't want to bash PHP.... by narkotix · · Score: 1

      best joke ever!

      --
      We played dungeons and dragons for 3 hours.....then i was slain by an elf
    26. Re:Don't want to bash PHP.... by jjohn · · Score: 1

      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. More trouble than it's worth.

    27. Re:Don't want to bash PHP.... by Mr2001 · · Score: 1

      Actually, someone else on ifMUD came up with it recently while I was griping about suPHP... thanks, though. ;)

      --
      Visual IRC: Fast. Powerful. Free.
    28. Re:Don't want to bash PHP.... by aweiland · · Score: 1

      If it's a design flaw in PHP then it's a design flaw in many other languages, by your logic.

      You want the language to pre-filter before it gets to the programmer? What happens when you want the raw text from the user?

      In my bag of tricks library I use when developing PHP I have a few functions that I run text through depending on what I need. If the text is coming in from a large input box, I run it through a function that strips out as much XSS problems as possible. If it's coming from a check box and being stored in a DB as an integer, not a whole lot I'd like to do to it. I would hate for the language to just hijack what the users are inputing.

      It's not a waste of programmer time. I've compiled the functions over months and years. How much time does it take me to type: $str = stripXSS($str); ?

    29. Re:Don't want to bash PHP.... by bill_mcgonigle · · Score: 1

      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.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    30. Re:Don't want to bash PHP.... by Tassach · · Score: 1
      If it's a design flaw in PHP then it's a design flaw in many other languages, by your logic
      Yep. Just because everyone else is doing it, doesn't make it right.

      For both POST and GET, user input from a web form is, by definition, passed to your program as a URL-encoded string. In order to use that string in your program, it has to be decoded, parsed out into name-value pairs, and then be assigned to the appropriate user variables and/or objects. There's ample opportunity to validate the input in this process. For a language that is specifically designed to handle web forms, this validation should be as automatic and transparent as is possible, especially when you consider that you MUST anticipate that a malicious user can submit any arbitrary set of values via the POST or GET.

      In a strongly-typed language, it's impossible to assign an invalid value to a variable -- an illegal assignment will either throw an error or be subjected to a well-defined conversion rule. EG: if I define a variable as an 80-char string, then if I attempt to assign 200 chars to that variable the language should react in a well-defined manner, by either throwing an error or silently truncating the input. While variant data types / typeless variables are useful (and sometimes indispensable), it places the burden for type-checking on the programmer. In a language targeted at novices / non-programmers, this is dangerous -- this class of user can't be relied on to do manual type checking.

      However, even in a loosely-typed language, there's no excuse for an object's constructor to not sanitize, validate, and type-check the input it is given, particuarly if it's performing some security-critical or commonly-exploited operation.

      --
      Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
  21. My God! by iamdrscience · · Score: 1

    PostNuke has a serious security vulnerability? I am SOOOOO surprised!

    1. Re:My God! by Anonymous Coward · · Score: 0

      postnuke isn't that bad, you're thinking of PHP Nuke which is known for it's number and frequency of vulnerabilities.. hence the need to fork it a long time ago to postnuke.

    2. Re:My God! by Anonymous Coward · · Score: 0

      I had a job developing PostNuke, and I have to say that PostNuke sourcecode makes my eyes bleed...
      And the architecture of the festering pile of... unpleasantness... I can only label as "Pure crap"

      I'm convinced that everytime someone installs PostNuke on a server, god kills a dozen kittens.

  22. Re:Wouldn't This Be Called an XML Injection Attack by Anonymous Coward · · Score: 0

    Indeed, SQL injection attacks inject and run SQL commands, so this vulnerability would be a PHP Injection attack, as it's PHP code that gets executed on the server.

  23. Why PHP? by mcc · · Score: 2, Insightful

    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?

    1. Re:Why PHP? by Anonymous Coward · · Score: 0

      Well, because it's shit.

      I don't call it 'the tool for tools' for nothing.

    2. Re:Why PHP? by eddy+the+lip · · Score: 4, Insightful
      ...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.

      --

      This is the voice of World Control. I bring you Peace.

    3. Re:Why PHP? by Saeed+al-Sahaf · · Score: 3, Insightful
      ...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.

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    4. Re:Why PHP? by iamdrscience · · Score: 1

      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.

    5. Re:Why PHP? by Anonymous Coward · · Score: 0

      The real problem is that PHP is installed on nearly every web server, so any issues which occur affect a large number of servers. There are some other issues as well. There are a number of widely used popular apps which are poorly coded, allowing for SQL injection, cross site scripting attacks, among other things. As far as PHP itself goes, the kitchen sink approach to its function library allows more bugs to occur in the language itself. Adoption of something similar to Perl's tainted variable checking would help quite a bit with the poor coding.

    6. Re:Why PHP? by Anonymous Coward · · Score: 0

      I think it is a combination of the popularity attributed to PHP and the use of extension libraries. To get a good diagnosis of the problem though, it is best to look at the vulerability itself.

  24. WordPress Fix by Anonymous Coward · · Score: 0
    There's already a fix for WordPress.

    We would like to announce that WordPress 1.5.1.3 is now released as we continue the availablity of a highly stable and extremely popular branch based on the 1.5 Strayhorn codebase. Development has moved on to some exciting new features for the next major release, but an important security issue was brought to our attention which required an update for our users. The problem is not yet public but you should update your blog as soon as possible to 1.5.1.3. If you are unable to do upgrade in the short-term you may protect yourself by deleting the xmlrpc.php file from your WordPress directory.
  25. Un-Exploitable by Manip · · Score: 1

    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 use.

    I'm sure this 'Internet Storm Centre' loved all this attention but it doesn't reflect on how good their alerts are or if there are any experts.

    1. Re:Un-Exploitable by shark72 · · Score: 1

      "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 on. RSS involves pulling content.

      This isn't a worm-like situation (e.g. an RSS feed with some malicious SQL injection) but instead an opportunity for a hacker to compromise a system that's known to use PHP and have an XML-RPC interface.

      --
      Sitting in my day care, the art is decopainted.
    2. Re:Un-Exploitable by Anonymous Coward · · Score: 0

      "this 'Internet Storm Centre[sic]' loved all this attention"? "or if there are any experts"? Are you kidding me? You've never heard of sans.org? Obviously, you've never been a professional sysadmin.

  26. Patching Serendipity by raarky · · Score: 1

    From the s9y forums:

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

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

  27. Re:Wouldn't This Be Called an XML Injection Attack by Anonymous Coward · · Score: 0

    lol

  28. In the wild? by Saeed+al-Sahaf · · Score: 2, Informative
    ... 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.

    --
    "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    1. Re:In the wild? by Anonymous Coward · · Score: 0

      Yes, it's in the wild:


      xxxxxxxxxxxxxx - - [01/Jul/2005:19:44:56 -0500] "GET //wp/wp-admin/xmlrpc.php HTTP/1.1" 404 998 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
      xxxxxxxxxxxxxx - - [01/Jul/2005:19:44:57 -0500] "GET //wp/xmlrpc.php HTTP/1.1" 404 998 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"


      Fortunately, I don't have Wordpress installed.

    2. Re:In the wild? by HD+Webdev · · Score: 1

      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.

      --
      This is not a dream, not a dream...we are transmitting from the year 1-9-9-9.
  29. Stupid eval... by Spy+der+Mann · · Score: 1

    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)

    1. Re:Stupid eval... by Just+Some+Guy · · Score: 1

      Several important languages (eg Lisp) execute code-in-data as a matter of course. eval() isn't bad; people using eval() because it looks handy is the problem.

      --
      Dewey, what part of this looks like authorities should be involved?
  30. Open-source, bah! by tonyblake2003 · · Score: 0, Offtopic

    How *dare* an open-source product have bugs! This is exactly the reason that I threw my MSWin servers into the sea. Now you're expecting me to update my PHP libs? God almighty, you're all the same.

  31. PHP definitely needs to be less ad hoc by ShatteredDream · · Score: 1

    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.

  32. mod_perl by holy+zarquon's+singi · · Score: 0, Flamebait

    And that's exactly why I use mod_perl for this kind of stuff. That and perl is a more flexible language

    --
    "...we should just trust our president in every decision that he makes and we should just support that." B.Spears 2003
  33. kdedevelopers.org hit by this earlier today. by Anonymous Coward · · Score: 0

    kdedevelopers.org was hit by this flaw earlier today. And drupal's website no longer seems to have a list of drupal-using websites (I would suppose for this reason).

  34. Not PostNuke's issue this time, though... by Sepodati · · Score: 1

    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...

  35. ... lucky by onlyjoking · · Score: 1

    This here's a 48 Magnum that'll blow your head right off. Now you gotta ask yourself one question, "Do I feel lucky?". Well, DO YA, PUNK?

    1. Re:... lucky by EvilStein · · Score: 2, Informative

      Uh, you mean .44 Magnum, the most powerful handgun in the world. :P

      Of all things to misquote, don't misquote Dirty Harry! ;)

      "I know what you're thinking: "Did he fire six shots, or only five?" Well, to tell you the truth in all this excitement, I've kinda lost track myself. But, being this is a .44 Magnum, the most powerful handgun in the world, and would blow your head clean off, you've got to ask yourself one question: "Do I feel lucky?" Well, do ya punk?"

    2. Re:... lucky by onlyjoking · · Score: 1

      (shrinks away suitably chastened)

    3. Re:... lucky by Anonymous Coward · · Score: 0

      'Here's your five-point suppository captain.'

      'WHAT DID YOU SAY!?!'

  36. XOOPS by pjay_dml · · Score: 1

    XOOPS has released an updated version and patch on July 2'nd.

  37. Drupal fixed 29th june by zxsqkty · · Score: 1

    Old news travels fast ;)

    http://drupal.org/drupal-4.6.2

    --
    Caution: May contain nuts.
    1. Re:Drupal fixed 29th june by hugejeans · · Score: 1

      drupal.org - website has been down for a couple of days, any news anyone?

    2. Re:Drupal fixed 29th june by Anonymous Coward · · Score: 0

      I've been wondering the same thing and can't find any news about it anywhere. This thing is too big to be offine this long. Makes me think something very bad has happened.

  38. nope by EvilStein · · Score: 1

    phpBB has its own huge set of gaping security holes. :)

  39. Isn't it great... by It's+the+tripnaut! · · Score: 2, Funny

    ... that right above this article in /. is another article titled "Anatomy of a Hack" which basically describes how one can h4xx0r b0x3n?

  40. Root Me by fire-eyes · · Score: 1

    As I've always thought, running PHP is the same as hanging a "Root Me" sign outside your server.

    --
    -- Note: If you don't agree with me, don't bother replying. I won't read it.
    1. Re:Root Me by Anonymous Coward · · Score: 0

      As I've always thought, running PHP is the same as hanging a "Root Me" sign outside your server.

      Ha, because you are a moron and can't figure out it has nothing to do with the language and everything to do with a poor programmer...you know...like your mom in regards to your programming.

      Here's YOUR sign (STUPID!)

  41. Too True by mfh · · Score: 1

    Passing untrusted input directly to eval is gross negligence

    I pass ALL fsk'ing data through strict purify scripts. Most data is assumed numeric and if'd to be >0 or forced to -10.

    Man Slashdot has stupid filters but I guess they are needed... I just tried posting some PHP code to this comment and got this error: Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.

    Well I guess that ends my post about purification. Sometimes you have too much of it and sometimes you don't have enough. Go figure.

    --
    The dangers of knowledge trigger emotional distress in human beings.
  42. How to fix PostNuke by pukerz · · Score: 1

    It is recommended that all admins deactivate and remove the 'xmlrpc' module within administration-modules and additionaly remove /xmlrpc.php and and the /modules/xmlrpc folder completly from the filesystem.
    The PostNuke CMS Development Team highly recommends to *not* use the xml rpc library until the maintainers [1] provide a secure solution. Once an updated version is available a modularized version will be provided for download as an additional module.
    Note: The upcoming .760 release will not contain the xml rpc library.

    --
    the dead shall rise, from their graves, to destroy, geometry.
    1. Re:How to fix PostNuke by Anonymous Coward · · Score: 0

      You can fix your postnuke installation by removing it and installing PHP-Nuke instead.

      Did you see? There isn't any completely secure CMS software out there, then people make complains all the time. Now PHP-Nuke isn't vulnerable to this security hole and PostNuke IS vulnerable... eat this! (FYI it isn't the first time that postnuke has its own security issue and PHP-Nuke isn't vulnerable...) So, please learn the lesson, there isn't a perfect solution.

      Being said.

  43. Open Source? by shmlco · · Score: 1

    So? A question. Would the vulnerability have been apparent, or the hack possible, without access to the blog source code?

    --
    Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
    1. Re:Open Source? by Breakfast+Pants · · Score: 1

      Perhaps not widely to the public. And would the subsequent fix ever have occured?

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    2. Re:Open Source? by shmlco · · Score: 1

      Perhaps not widely to the public? I didn't know the "public" at large was committed to hacking web sites and servers. So one may ask again, how likely would it have been that a hacker would have discovered this vulnerability without having had access to the source code?

      --
      Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
    3. Re:Open Source? by Breakfast+Pants · · Score: 1

      That came off wrong, I meant "publically available" rather than "widely known to the public." Regardless the details in this case are pretty sparse and we don't even know if he discovered the vulnerability by toying with inputs to the sites or by examining the source code.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
    4. Re:Open Source? by SillyNickName4me · · Score: 1

      So one may ask again, how likely would it have been that a hacker would have discovered this vulnerability without having had access to the source code?

      Considering the number of security vulnerabilities found in closed source applications and systems, yes, it would most likely have been discovered at some point.

      I suggest you follow bugtraq for a few months.

  44. Re:Wouldn't This Be Called an XML Injection Attack by Anonymous Coward · · Score: 1, Insightful

    I prefer a hot beef injection

  45. Zonk and blogging stories by The+Hobo · · Score: 1

    YAZBS (Yet Another Zonk Blogging Story)

    --
    There is another kind of evil which we must fear most, and that is the indifference of good men. -- Boondock Saints
  46. PHP + MYSQL can do everything.... by Anonymous Coward · · Score: 0

    next version Deep Impact will be implemented on PHP+MYSQL...

  47. Bragging rights for Perl developers unwarranted by timbrown · · Score: 4, Insightful

    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.

    --
    Tim Brown
    1. Re:Bragging rights for Perl developers unwarranted by CoolVibe · · Score: 1

      Well said. Good to see the voice of reason and sanity for once instead of the tiresome language/blog-system/OS/whatever-fanboyism and groupthink.

      If I had modpoints, I would have modded you up.

  48. Already fixed. by Anonymous Coward · · Score: 0

    Security Focus reports that if you are not using phpBB 2.0.16 or later, then you are vulnerable.

    So if you subscribe to their list (which updated everyone as soon as this was known and fixed), you should have very little issue at all. Upgrades are available via "changed files only", "patch methods" or full upgrades, so please, let's go easy on the FUD eh?

  49. Lessons to be learnt? by Anonymous Coward · · Score: 2, Informative

    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() 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, there's no need to use eval() in the first place.

    You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

    Two further things that are disturbing about this exploit.

    First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

    Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

    This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

    These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

    What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

    But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

  50. It wasn't designed with security in mind... by pjc50 · · Score: 1

    .. so it's always going to lag behind in that area, unfortunately.

  51. fire with fire by piggydoggy · · Score: 1
    ...As a first ingredient we have the probing and even at least one worm/botnet on the loose attacking unpatched phpBB installations. Probes we see on patched phpBB boards range from trying the highlight bug to trying to run "uname -a".
    ...
    - patch XML_RPC: "pear upgrade XML_RPC" should do the trick, or visit the distribution site for more details.

    So why not run loose a spider that probes `pear upgrade XML_RPC`?

  52. Bullshit... by Anonymous Coward · · Score: 0

    I'm a member of the support team for phpBB and deal with such things.

    You're quite simply wrong.

  53. NIH syndrom pays out by EXTmilky · · Score: 1

    Happily I've been using my homegrown XML-RPC library for PHP - mainly because Edd Dumbills version was unreadable and had an ugly API - and how dumb it looks use eval() on unchecked data?!

    http://xprofile.berlios.de/