We're seeing requests on multiple sites for URLs ending in "xmlrpc.php" which apparently relate to this worm. So far only from IP addresses in Morocco. The first attempt was 02 November.
I've heard a few mentions around
lock 'em down folks, no one wants to be a test case
More info at ISC-SANS [isc.sans.org]. You will want to search through the (vast) list of apps at [securityfocus.com...] One obvious one for absolutely everybody is PEAR.
First, here are examples from my Apache access-log:
|126.96.36.199 - - [12/Oct/2005:08:03:00 +0100] "POST /xmlrpc.php HTTP/1.1" 404 1013 "-" "-"In:- Out:-:-pct. |
188.8.131.52 - - [12/Oct/2005:08:36:35 +0100] "POST /adxmlrpc.php HTTP/1.1" 404 1013 "-" "-" In:- Out:-:-pct.
184.108.40.206 - - [14/Oct/2005:03:05:11 +0100] "POST /xmlrpc.php HTTP/1.1" 404 1013 "-" "-"In:- Out:-:-pct.
220.127.116.11 - - [21/Oct/2005:08:09:55 +0100] "POST /xmlrpc.php HTTP/1.1" 404 1013 "-" "-" In:- Out:-:-pct.
18.104.22.168 - - [21/Oct/2005:10:46:36 +0100] "POST /xmlrpc.php HTTP/1.1" 404 1013 "-" "-" In:- Out:-:-pct.
22.214.171.124 - - [08/Nov/2005:14:42:19 +0000] "POST /xmlrpc.php HTTP/1.1" 301 244 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" In:- Out:-:-pct.
126.96.36.199 - - [08/Nov/2005:14:42:21 +0000] "POST /blog/xmlrpc.php HTTP/1.1" 301 249 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" In:- Out:-:-pct.
Next, even though PEAR is as new as it (should be able to be) on my server, updating it was one vast pain. The latest version is 1.4.4, and my CentOS (RHEL) k2.6 reported 1.3.1 (I think). The PEAR servers seem to be giving grief.
A word of advice. This latest PEAR requires v1.3.3 to already be installed. I suggest that you do the following:
...in that order. I was getting all kinds of errors, including "Segmentation fault" - not a pretty sight.
|# pear install -f pear-1.3.3 |
# pear upgrade pear
# pear channel-update pear.php.net
Retrieving channel.xml from remote server
Update of Channel "pear.php.net" succeeded
# pear upgrade-all
Which software/scripts or methods are affected by this vunarability?
|We're seeing requests on multiple sites for URLs ending in "xmlrpc.php" which apparently relate to this worm. |
xmlrpc.php is a WordPress [wordpress.org] file - if you are running any version of WordPress prior to 1.5 then you must upgrade now, or at the very least disable pingbacks etc. and delete the xmlrpc.php file from the server (this should not affect the basic functionality of the system). WordPress 1.5 and later does not use the problematic library so is unaffected by the worm.
The list of affected applications include "PHP PHP 4.3.10". Does this mean PHP itself is affected? Does the mere fact that I have an older version of PHP on my server mean I'm vulnerable?
yes it does
I'm assuming that if I keep wordpress up to date and have all the latest patches for my distro that I should be pretty much fine? I checked the Mandrake security notices and it looks like they actually patched this at the OS level back in June or July.
>> hat I should be pretty much fine
as fine as you can be
I also made my /tmp directory non-executable (not yet sure how to mount/unmount that on a live system to get it to take effect - suggestions?). Saw that in one of the bulletins somewhere related to this.
All the info I'm finding concerns XML-RPC. If I don't have any applications like Wordpress, etc, how would someone go about exploiting this hole? Do you have any links to details you could post, please?
I did a quick search for
XML RPC Vulnerability [google.com]
this one mentions it quickly
Wheel, this *should* work :
mount -o remount /tmp
|Does the mere fact that I have an older version of PHP on my server mean I'm vulnerable? |
jatar_k's response is both correct and incorrect depending on the source of your PHP, so perhaps "it depends" would have been more accurate.
Explanation: my server has always run RedHat linux (currently CentOS aka RH). RH have a policy of backporting [redhat.com] fixes - this means fixing the problem, but keeping the software main version-number the same (only the minor number changes).
So, this problem was fixed by RH on 2005-08-19 (see https://rhn.redhat.com/errata/RHSA-2005-748.html). If you check out the version-numbers involved you will see them to vary between php-4.3.2-25 and php-4.3.9-3.8, which is a long way behind the current php-version of 4.4.0. Yet, those versions are bang up-to-date.
PS Those versions include an update for PHP-PEAR, which should mean that the PEAR updates on page#1 of this thread are unnecessary. Shucks. It appears that the difficulties I suffered were because XML-RPC is now a required component for PEAR to be used from the CLI, but I do not have that component of PHP installed.
>> it depends
hehe, you are quite right AlexK but I could in essence answer it depends to any question asked here, everything always depends on something ;)
if your version isn't up to date it is vulnerable, if you don't use xml-rpc then it is more than likely not applicable
ps redhat is always a pain ;)
I'm a bit confused but what's new ;-) I was aware of this since June (and then August ) when Drupal was affected and patches were made available.
As far as I know the vulnerability is in a third party library found on sourceforge at [phpxmlrpc.sourceforge.net...]
This is NOT what gets compiled with PHP when you use "--with-xmlrpc". This part of php [php.net...] uses this completely different C program [xmlrpc-epi.sourceforge.net...] I haven't found any security announcements concerning this part.
So the real problem is not with PHP but with the PEAR distro that is bundled with PHP.
Here's a better explanation from the horse's mouth at phpxmlrpc.sourceforge.net
|Scope of the problem |
* the bug affects the two libraries known as PEAR::XMLRPC and PHPXMLRMPC.
It DOES NOT affect the xmlrpc implementation which is built-in in php and enabled at compile time with the "--with-xmlrpc" option (on Unix, on windows generally it is enabled/disabled by changing the appropriate line in php.ini)
* the bug (execution of php-code injected by remote hosts) resides exclusively in the file xmlrpc.inc in the phpxmlrpc distribution and RPC.php in the PEAR distribution
* both PEAR::XMLRPC and PHPXMLRMPC have released updated versions of the library that fix the problem
* both libraries have been used in a large number of php applications (see the incomplete list above).
Since the whole lib consists basically of 2 very simple files, everybody tends to patch them according to its own tastes/needs and bundle them when distributing their app.
Most high-profile projects have been extremely quick in releasing new versions of their respective apps, but it will take a much longer time for every single user to update his system.
So if you don't have PEAR installed then don't freak out but do upgrade soon. If you do have PEAR then update immediately. If you have PEAR installed and are not using it then I think it would be best to dump it.
From what I've read so far that is my understanding as well, Timotheos. But, we could both be wrong ;)
THAT is why we discuss issues like this in our forum. To clarify and keep each other in check so that ultimately we are on top of our game here.
execution of php-code injected by remote hosts
This, in my mind, remains the issue. We are right back to the old injection issue. This time, the injection is coming from what most folks wouldn't really consider a 3rd-party application such as phpnuke, phpbb, etc. but from a *trusted* repository that comes bundled with most PHP installations, PEAR. As stated here by everyone else, but I'll say it again, if you are using PEAR, patch it. If not, remove it.
After closer inspection it turned out I do have PEAR installed. The admin must have installed it when he set up my system, I must admit I haven't ever used it.
Thanks to everyone for the help, turns out I was vulnerable even though I didn't know it!