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 [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ