Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 25 Feb 2014 16:28:47 -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 11:18 AM, cve-assign@...re.org wrote:

>> I was looking at the installed script on a Fedora 19 box
>
> Apparently the situation is that the Fedora catfish.spec file
> generates the duplicate checks for $APPNAME.py. It's uncommon to have
> different CVE mappings for Fedora-shipped versions versus upstream
> versions, but in this case we'll proceed to do that because the CVE
> abstraction was already stated that way, and the attack vectors are
> actually different.
>
> 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.
>
> If someone installs the upstream version of either catfish 0.4.0.2 or
> catfish 0.8.2, they get a script that unsafely looks for both
> catfish.pyc and catfish.py.
>
> If someone installs either the Fedora 19 catfish-0.4.0.2-2 package or
> the Fedora 20 catfish-0.8.2-1 package, they get a script that unsafely
> looks for only catfish.py (twice).
>
> This apparently occurs because of:
>
> [Fedora 19 catfish.spec]
> %{__sed} -i.byte \
>       -e 's|pyc|py|' \
>       %{name}.in
>
> [Fedora 20 catfish.spec]
> %{__sed} -i.byte \
>       -e 's|pyc|py|' \
>       bin/%{name}.in.in
>
> We don't know why that was done. (Maybe Fedora has a policy against
> certain uses of .pyc files, and this policy is implemented in
> the .spec files of various packages?)
>
> 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.

AFAIK there is no policy.  This may be something the maintainer chose to do for some unknown reason.

Thanks for all this extra analysis.  I've updated our bug with the new and proper CVEs for this issue.

-- 
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.