Bug 1069396 - (CVE-2014-2093, CVE-2014-2094, CVE-2014-2095, CVE-2014-2096) CVE-2014-2093 CVE-2014-2096 catfish: insecure loading of python script
CVE-2014-2093 CVE-2014-2096 catfish: insecure loading of python script
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20140224,reported=2...
: Security
Depends On: 1069398
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-24 17:41 EST by Vincent Danen
Modified: 2015-02-04 07:49 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-04 13:56:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2014-02-24 17:41:48 EST
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
Comment 1 Vincent Danen 2014-02-24 17:47:50 EST
CVE request:

http://openwall.com/lists/oss-security/2014/02/24/7
Comment 2 Vincent Danen 2014-02-24 17:49:15 EST
Created catfish tracking bugs for this issue:

Affects: fedora-all [bug 1069398]
Comment 3 Vincent Danen 2014-02-25 11:14:42 EST
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.
Comment 4 Vincent Danen 2014-02-25 18:27:12 EST
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.
Comment 5 Tomas Hoger 2014-02-26 02:44:36 EST
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.
Comment 6 Mamoru TASAKA 2014-03-02 04:48:19 EST
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?
Comment 7 Mamoru TASAKA 2014-03-02 04:49:51 EST
This question is important, so as to I can judge if changes I would apply to Fedora packages really fixes these issues.
Comment 8 Mamoru TASAKA 2014-03-02 05:23:10 EST
(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?
Comment 9 Vincent Danen 2014-03-03 17:57:36 EST
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.
Comment 10 Mamoru TASAKA 2014-03-04 00:54:48 EST
(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...
Comment 11 Mamoru TASAKA 2014-03-04 00:57:19 EST
Again bin/catfish.py is already there (not bin/catfish.in.in), and
would you again clarify if bin/catfish.py is affected?
Comment 12 Mamoru TASAKA 2014-03-04 01:52:27 EST
(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.
Comment 13 Mamoru TASAKA 2014-03-04 02:06:07 EST
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.
Comment 14 Mamoru TASAKA 2014-03-04 03:29:19 EST
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.
Comment 15 Tomas Hoger 2014-03-04 04:30:22 EST
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.
Comment 16 Vincent Danen 2014-06-04 13:56:11 EDT
This has been corrected in:

* Fedora 19: catfish-0.4.0.2-4.fc19
* Fedora 20: catfish-1.0.1-1.fc20

Note You need to log in before you can comment on or make changes to this bug.