A Debian bug report [1] indicated that catfish suffers from some bad logic when loading the catfish.py script from the /usr/bin/catfish script. This script intentionally looks to load catfish.py in the current working directory. If a user were to run catfish in an untrusted directory that contained a malicious catfish.py, that script would be executed with the privileges of the user running catfish. This script: #!/usr/bin/env bash APPNAME=catfish if [ -e $APPNAME.py ] then python $APPNAME.py "$@" else if [ -e $APPNAME.py ] then python $APPNAME.py "$@" else cd /usr/share/$APPNAME if [ -e $APPNAME.py ] then python $APPNAME.py "$@" else python $APPNAME.py "$@" fi fi fi should probably be: #!/bin/sh python /usr/share/catfish.py "$@" The rest is just development fluff and very poorly written. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739958
CVE request: http://openwall.com/lists/oss-security/2014/02/24/7
Created catfish tracking bugs for this issue: Affects: fedora-all [bug 1069398]
According to: http://openwall.com/lists/oss-security/2014/02/25/2 the assignment of CVEs looks like: 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. Based on the above, CVE-2014-2095 affects Fedora 20. CVE-2014-2093 and CVE-2014-2094 affect Fedora 19. The rationale for the two CVEs for catfish.py vs catfish.pyc in the same directory seem to be due to affects via "different versions" but MITRE never indicated what those version differences are.
More poking around by MITRE leads to the following: 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 under the current working directory - Use CVE-2014-2095. bin/catfish.py under the current working directory - Use CVE-2014-2096. This specific case isn't very interesting because every one of the mentioned versions of catfish on every platform is actually vulnerable. However, probably no Fedora advisory should map to either CVE-2014-2094 or CVE-2014-2095. So essentially this issue is, for Fedora, CVE-2014-2093 and CVE-2014-2096 because we don't look for .pyc files due to some sed magic in the specfile that we're unsure of.
Let's keep the other two CVEs as alias here too. It makes it easy to find that those issues are known and not relevant to Fedora.
Well, would you make it clear to what version of what scripts these CVEs are assigned? It seems that CVE-2014-2095,2096 are assigned against catfish-1.0.0 bin/catfish.py{,c} , and maybe catfish-0.4.0.2 catfish (not catfish.py)? And to what CVE-2014-2093,94 apply? There is no "catfish.py" in 1.0.0 (bin/catfish.py is CVE-2014-2096, again?) and I don't see 0.4.0.2 "catfish.py" looks into cwd?
This question is important, so as to I can judge if changes I would apply to Fedora packages really fixes these issues.
(In reply to Mamoru TASAKA from comment #6) > It seems that CVE-2014-2095,2096 are assigned against catfish-1.0.0 > bin/catfish.py{,c} , And actually this not not bin/catfish.py but bin/catfish.in.in , right?
It's not so complicated. Comment #4 has the particulars. For Fedora, that means: "So essentially this issue is, for Fedora, CVE-2014-2093 and CVE-2014-2096 because we don't look for .pyc files due to some sed magic in the specfile that we're unsure of." And from a source perspective, catfish.in.in becomes catfish.py. Just look for where the problem is. It's silly that four CVEs got assigned to one script, but there it is. I would be concerned less with which CVEs are applicable as to just getting the fix out. But in case it's important, let me re-phrase what I've already noted: * CVE-2014-2096 affects Fedora 20. * CVE-2014-2093 affect Fedora 19.
(In reply to Vincent Danen from comment #9) > And from a source perspective, catfish.in.in becomes catfish.py. I don't see where you see here. bin/catfish is to be made from bin/catfish.in.in, but not catfish.py. And bin/catfish.py is already there and seems no relation to this. Well, this report is very confusing and not kind to the affected maintainers...
Again bin/catfish.py is already there (not bin/catfish.in.in), and would you again clarify if bin/catfish.py is affected?
(To clarify: bin/catfish.in.in generates finally bin/catfish, which is to be installed as /usr/bin/catfish, while bin/catfish.py is installed as /usr/share/catfish/bin/catfish.py , and /usr/bin/catfish and /usr/share/catfish/bin/catfish.py are completely different. What I am asking is * CVE-2014-2096 is perhaps talking about bin/catfish.in.in or /usr/bin/catfish, not bin/catfish.py or /usr/share/catfish/bin/catfish.py and I would like you to clarify this * And I would like you to clarify if bin/catfish.py or /usr/share/catfish/bin/catfish.py is affected by any CVE assigned number or not.
And note that CVE-2014-2094 or CVE-2014-2095 are strange - because (with _no_ modification as written on Fedora spec file, i.e. by default) the procedure written on "INSTALL" (as README says "For installation instructions read INSTALL") does _NOT_ produce any .pyc files. build.py produces .pyc files with "build" option, but the instruction written on INSTALL does not use this option (as a result). Fedora rpm contains many .pyc files, but these are generated by /usr/lib/rpm/brp-python-bytecompile , not the procedure by catfish installation process. So from my point of view CVE-2014-2094 or CVE-2014-2095 points to nowhere.
Correction to my comment 13: catfish-0.4.0.2 Makefile.in calls "build.py build", so CVE-2014-2094 seems valid, still CVE-2014-2095 seems invalid.
All CVEs here are for catfish shell launcher script which basically attempts to run "python catfish.py". In binary rpms, it's /usr/bin/catfish, while in source rpms it's catfish.in (0.4.0.2) or bin/catfish.in.in (0.8.2 and 1.0.0). None of the CVEs is for catfish.py. Note that there is difference between older and newer versions of that script. catfish.in contains: #!/usr/bin/env bash APPNAME=catfish if [ -e $APPNAME.pyc ] then python $APPNAME.pyc "$@" else if [ -e $APPNAME.py ] then python $APPNAME.py "$@" and bin/catfish.in.in contains: #!/usr/bin/env bash APPNAME=catfish if [ -e bin/$APPNAME.pyc ] then %python% bin/$APPNAME.pyc "$@" else if [ -e bin/$APPNAME.py ] then %python% bin/$APPNAME.py "$@" Note that older versions try to run "python catfish.py", while newer versions attempt to run "python bin/catfish.py". Therefore CVE-2014-2093 and CVE-2014-2094 may apply to Fedora 19 (which currently has catfish 0.4.0.2), while CVE-2014-2095 and CVE-2014-2096 may apply to Fedora 20+ (with catfish 0.8.2 or later). Additionally, as noted in comment 4, CVE-2014-2094 and CVE-2014-2095 are not applicable to Fedora, as catfish.spec contains the following to avoid trying to run "python catfish.pyc" and only .py extension is tried. 0.4.0.2: %{__sed} -i.byte \ -e 's|pyc|py|' \ %{name}.in 0.8.2: %{__sed} -i.byte \ -e 's|pyc|py|' \ bin/%{name}.in.in Hence only CVE-2014-2093 is really applicable to Fedora 19, and only CVE-2014-2096 to Fedora 20. From your point of view as maintainer, it's sufficient to know that changing the script to only do "python /full/path/to/catfish.py" is all that's needed to fix, regardless of the messy CVE assignment nuisances. I believe that was already done, either by updating to upstream version that does, that, or by only backporting changed launcher script: http://pkgs.fedoraproject.org/cgit/catfish.git/commit/?h=f19&id=099b986 Of course, the change assumes catfish does not require its CWD to be catfish installation root directory (/usr/share/catfish) for some other reason.
This has been corrected in: * Fedora 19: catfish-0.4.0.2-4.fc19 * Fedora 20: catfish-1.0.1-1.fc20