Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Feb 2014 09:10:53 -0700
From: "Vincent Danen" <vdanen@...hat.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE request for catfish program

On 02/25/2014, at 7:56 AM, cve-assign@...re.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
Download attachment "signature.asc" of type "application/pgp-signature" (711 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.