Re: CVE request for catfish program

["Vincent Danen" <vdanen () redhat com>]

On 02/25/2014, at 11:18 AM, cve-assign () mitre 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

Attachment: signature.asc
Description: OpenPGP digital signature