what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

phpRPC07.txt

phpRPC07.txt
Posted Mar 2, 2006
Authored by James Bercegay | Site gulftech.org

phpRPC versions 0.7 and below suffer from a remote code execution flaw.

tags | advisory, remote, code execution
SHA-256 | 2cc289b5a0eae7208104836c1d8e959923fbaa86da1ac47f8b9d19538d5d159c

phpRPC07.txt

Change Mirror Download
##########################################################
# GulfTech Security Research February 26, 2006
##########################################################
# Vendor : Robert Hoffman
# URL : http://sourceforge.net/projects/phprpc/
# Version : phpRPC <= 0.7
# Risk : Remote Code Execution
##########################################################



Description:
phpRPC is meant to be an easy to use xmlrpc library. phpRPC
is greatly simplified with the use of database/rpc-protocol
abstraction. It should run on any php server with most data
bases. Unfortunately, there is a easily exploitable remote php
code execution vulnerability in the phpRPC library that allows
an attacker to execute arbitrary code on the affected webserver.
This vulnerability, like previously discovered vulnerabilities
in various implementations of the XMLRPC protocol is possible
because of unsanitized data being passed to an eval call. This
of course could ultimately lead to a compromise of the under
lying web server, and disclosure of sensitive data.



Remote Code Execution:
There is a very serious, easy to exploit remote code execution
issue in the phpRPC library. This issue takes place in the file
rpc_decoder.php within the decode() function. This function is
basically responsible for decoding the incoming XML data into
php readable data that can be used by the application.

/**
* Tells the decoder to process the xml data
*
* Used internaly but can also be used to send xml data to the decoder
* @param string $data Transforms $data into a php readable array
* @return array Returns an array containing the extracted data
*/
function decode($data) {

$this->parser = xml_parser_create($this->encoding);

xml_set_object($this->parser, &$this);
xml_set_element_handler($this->parser, "tag_open", "tag_close");
xml_set_character_data_handler($this->parser, "cdata");
xml_parser_set_option($this->parser, XML_OPTION_SKIP_WHITE, 1);
xml_parser_set_option($this->parser, XML_OPTION_CASE_FOLDING, 1);
xml_parser_set_option($this->parser, XML_OPTION_TARGET_ENCODING,
$this->encoding);
xml_parse($this->parser, $data);
xml_parser_free($this->parser);

if ($this->debug == 1) { $this->dump(); }
eval($this->code);
return $params;
}

The variable $this->code in our case is constructed by the cdata()
function, and is never sanitized when placed within a base64 tag.
I guess this is because it is assumed that the data will be base64
encrypted and thus harmless, but the base64_decode call isn't
really executed until AFTER the vulnerable eval call parses the
data within "$this->code".

<?xml version="1.0"?>
<methodCall>
<methodName>test.method</methodName>
<params>
<param>
<value><base64>'));phpinfo();exit;
</param>
</params>
</methodCall>

The above xml request sent to the phpRPC server would successfully
execute the phpinfo() function, but this could just as easily have
been some malicious payload. The phpRPC library is not as popular
as other php XMLRPC implementations, but it is used fairly often
and in popular open source projects such as runcms and exoops.



Solution:
Several attempts to contact the developers were made, but according
to the current exoops webmaster the phpRPC author stopped maintaining
the project around 2004. Also, runcms were contacted as far back as
July/August 2005 about this issue, and did respond confirming they
would look in to it. However, as of last time I checked runcms (which
was only about five minutes ago) still contained the vulnerable phpRPC
libraries. Since there is no patch to be released, and since the
project is seemingly un maintained all users are encourage to quit
using the phpRPC library until a patch becomes publicly available.



Credits:
James Bercegay of the GulfTech Security Research Team



Related Info:
The original advisory can be found at the following location
http://www.gulftech.org/?node=research&article_id=00105-02262006


Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    0 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close