It is reportedly included in the current wordpress release and likely also ampache. I don't know wether the packages are actually vulnerable to the exploit.
I know our auditors don't like web-apps but until we confirm vulnerability I'll still set this to Auditing :)
CC'ing super stuart to see if that helps.
CC'ing Renat.
Wordpress and ampache both seems vulnerable. web-apps please advise. [09:36:02] <shellsage> Yes, wordpress uses snoopy. [09:36:33] <shellsage> If you download the archive, snoopy is in /wordpress/wp-includes/class-snoopy.php [09:36:34] <jaervosz_work> and I presume it is one of the vulnerable versions? [09:36:54] <shellsage> Yeah, it's version 1.0. [09:41:17] <shellsage> Yes ampache is vulnerable because it is distributed with snoopy-1.2, verified by looking at the file modules/amazon/Snoopy.class.php in the current release archive.
We should probably involve superlag and marienam since they own the two vulnerable packages.
I notified the ampache developer earlier today, he will put out a new release soon. I also just found that this is exploitable via ampache via something like the following request: http://billybob/ampache/albums.php?cover=https://localhost/%60echo+'hello'+%3E+/tmp/test.txt.jpg%60&action=find_art&album_id=86 the above exuctes %60echo+'hello'+%3E+/tmp/test.txt.jpg%60 aka `echo 'hello' > /tmp/test.txt.jpg` but this only worked for me if /usr/local/bin/curl existed as Snoopy hardcoded that path in.
So ampache is not really vulnerable, unless you have curl in /usr/local/bin/... About Wordpress : It has var $curl_path = "/usr/bin/curl"; so unchecked calls to Snoopy->fetch would trigger the vulnerability. But Snoopy->fetch is only called from _fetch_remote_file in rss-functions.php, which in turn seems only used in fetch_rss (same file). This function is called only on controlled input : $rss = @fetch_rss('http://feeds.technorati.com/cosmos/rss/?url='. trailingslashit(get_option('home')) .'&partner=wordpress'); $rss = @fetch_rss('http://wordpress.org/development/feed/'); $rss = @fetch_rss('http://planet.wordpress.org/feed/'); so it doesn't look affected to me.
ampache-3.3.1.5 released to fix this issue.
New ampache relase in CVS now.
Well, crap, I finally had time tonight to retest the new release of ampache and the issue still exists. The current version of Snoopy is still vulnerable. I'll poke at snoopy and see if I can get a more robust patch going.
The exact issue I am currently exploiting is that they escape " quotations but it is sill possbile to execute code in back ticks ` within " quotes. $safer_URI = strtr( $URI, "\"", " " ); // strip quotes from the URI to avoid shell access exec($this->curl_path." -D \"$headerfile\"".$cmdline_params." \"".$safer_URI."\"",$results,$return);
I also took a look at wordpress, and it seems ok to me. However in addition to those controlled calls to fetch_rss listed in the bug, it is called from get_rss and wp_rss, but I can't find a use of either of those two functions. If they are used and I'm just missing it then they may provide a path in, but as long as they aren't used all is well. back to ampache, we tacked in a quick fix for snoopy and put out another release which I will have in cvs shortly. I will attach the included patch for refrence.
Created attachment 73781 [details, diff] snoopy quick fix This was the quick and simple way to fix it. The old strtr calles that were being used to make the string a little safer can probably be removed. I also heard that this was also sent along to the wordpress developers so they are aware of the issue.
Opened so that upstream can access the bug. Note that Gentoo is as far as we can tell, unaffected by these (ampache has a wrong curl hardcoded path and wordpress doesn't seem to use that function on untrusted input). So I'm not sure it warrants a security fix here...
Closing the bug as a non-security issue. Feel free to reopen/reassign if you want to fix it.
