[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE request for catfish program
From:       "Vincent Danen" <vdanen () redhat ! com>
Date:       2014-02-25 23:28:47
Message-ID: 79D410D6-6EF4-4308-818C-3EAE8D9B5D19 () redhat ! com
[Download RAW message or body]

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 an=
d proper CVEs for this issue.

-- =

Vincent Danen / Red Hat Security Response Team
["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQGcBAEBAgAGBQJTDScvAAoJEJS+gzzouGyrpDML/1mj04Z1YJXMqhas0amSWavp
/hRcnX7U8UpsIHFggjS11CLy54qg5guI3WGFIz5Skna+/ENZt3lEvkOVjghCIw8W
Xlj2J3d8fcpzs5uvHqAWTjIVxnGpkiqFi1nIcvjRLB5t+CP4X/vSQOYJhAESHO7S
Qkilas/sh6PipGJA1PHpMugz0gyDyWd8M1ZG9RJycrIEmNmTs8k6qZV554vaQ6uH
Mb9ehRPhO4XoM0ZRwn+5uQygTy1zcy43VpRVxe4+WpiAlsc091UlYvViiSRBHUGP
PEp7XujLU+mP8wZlQRzclCyF0W+ierPARxpLlti/nslbAhi4HvLLperyCqAKgNVU
mZ7HoTUzw2AI5+ORiK0fGKTt5312F388ceIWl2x5JP2YfcQ4hZAz4wo0gxX/IAHq
lsQg73ZINZJ5WXqeHwsGWDhz+tiGdw7Me3ir4YsIpGKJGX3kkGgM2I4byYOd+uYC
0nEXCmlRb7tMIP1llymPlxDP0o6AW7tM+5/k+Fnbag==
=wpjq
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]