Re: CVE request for catfish program

["Vincent Danen" <vdanen () redhat com>]

On 02/25/2014, at 7:56 AM, cve-assign () mitre org wrote:

> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739958
> > https://bugzilla.redhat.com/show_bug.cgi?id=1069396
>
> > This script intentionally looks to load catfish.py in the current
> > working directory.
>
> "intentionally" tends to be a complicating factor for a CVE
> assignment; one could possibly instead express this as: the author
> didn't consider that catfish would sometimes be executed with cwd
> outside of the user's home directory. The nature of the program
> suggests that it could be started interactively by any user at any
> time, and there's no documentation indicating that the cwd could or
> should be constrained.

Well, given that they wrote what they did, I think "intentionally" is a correct observation (I mean, someone wrote 
this).  Whether or not they knew this would lead to any kind of security consequence is the question.

> We couldn't immediately figure out where your quoted source code came
> from.

I was looking at the installed script on a Fedora 19 box, so that is catfish 0.4.0.2.  Sorry, I should have been a bit 
clearer.

> http://ftp.de.debian.org/debian/pool/main/c/catfish/catfish_0.3.2.orig.tar.gz
> has a catfish.in that looks for $APPNAME.pyc before $APPNAME.py. The
> quoted code has duplicate checks for $APPNAME.py. This affects the
> number of CVEs. Apparently, "a crafted catfish.py file in the current
> working directory" is an attack vector with a certain set of affected
> versions, and "a crafted catfish.pyc file in the current working
> directory" is an attack vector with a different set of affected
> versions. Also, the Debian bug report specifically names a much later
> package (1.0.0-2) that might be considered an independent codebase,
> and at least has different attack vectors. The ChangeLog says "v0.6.0
> Complete rewrite from the ground-up." The problematic 1.0.0 code is
> distributed in bin/catfish.in.in and has attack vectors of "a crafted
> bin/catfish.pyc or bin/catfish.py file under the current working
> directory."
>
> The primary Red Hat bug report refers to
> https://bugzilla.redhat.com/show_bug.cgi?id=1069398 which is for
> "Product: Fedora ... Component: catfish ... Version: 20" but
> http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Everything/source/SRPMS/c/catfish-0.8.2-1.fc20.src.rpm
> is essentially the same as 1.0.0: the code is found in
> bin/catfish.in.in in the distribution, and bin/catfish.pyc and
> bin/catfish.py are the attack vectors. So, apparently your quoted code
> isn't the Fedora 20 code.

No.  But, to be honest, I didn't think this would receive two separate CVEs for "./script" vs "./bin/script" so there 
was one tracking bug to fix this in all versions of Fedora versus one per version of Fedora.  This isn't an exceptional 
thing and we do it pretty much all the time unless there are differing CVEs or other special reasons.

> Finally, we didn't find any evidence of a case where only
> bin/catfish.py is checked within the post-complete-rewrite codebase.
>
> catfish.py in the current working directory - Use CVE-2014-2093.
>
> catfish.pyc in the current working directory - Use CVE-2014-2094.
>
> bin/catfish.pyc and bin/catfish.py file under the current working
> directory - Use CVE-2014-2095.

So many...

Thanks for this.

-- 
Vincent Danen / Red Hat Security Response Team

Attachment: signature.asc
Description: OpenPGP digital signature