Bug 152657 - tcpdump security fix in rh7x, rh80
Summary: tcpdump security fix in rh7x, rh80
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: Package request
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
URL:
Whiteboard: rh72, rh73, rh80
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-16 16:41 UTC by Christian Pearce
Modified: 2007-04-18 17:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-05 22:42:46 UTC
Embargoed:


Attachments (Terms of Use)

Description David Lawrence 2005-03-30 23:23:00 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
                                                                                
Patches for tcpdump security fixed.  While gleamed from various sources,
we grabbed the patches from Red Hat AS2.1 src.rpm.  They were close to the
same source in 7.2-8.0.  If there is a patch in the future of tcpdump we will
be able to benefit from this approach.  We could have generated the patches
are self and basically did with the help of Johhny Strom, but it will be
consistent to use this patches.
                                                                                
The tcpdump spec is a little bit of a mess.  The backport was kind of messy
as well.  Fortunately the spec file for version 7.2-8.0 are the same except
the release which contains a dist tag.  I guess this is a habit RedHat picked
up for security releases.
                                                                                
I had to add a DEFINE of _U_=\"\" to get it to compile properly.  Similiar to
JohnnyS pulling it out.
 
Here are the upstream sources:
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0989
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0055
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0057
http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2
 
All the spec files are virtual same, so I am intrementing the release by one
and adding legacy.
 
The last two CAN's seem to be a fix RedHat put into the wild, while I don't
think other vendors had a chance to update, an example is progeny.  I have
not checked other sources.
 
RH72: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm
RH73: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm
RH80: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.8.0.4.legacy.src.rpm
MD5SUM: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.x.x.4.md5sum
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
 
iD8DBQFACFrrdlzgVFWktjoRAtJOAJ9Ca2UvZU5zgC3rrkO/Bgh40HOaGgCeKSeQ
u1wfRQyEuHqkoxtcNp6wYvU=
=PnL5
-----END PGP SIGNATURE-----



------- Additional Comments From drees 2004-01-20 00:32:59 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA on RH73

Using:
http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm

* md5 check OK
* Builds OK on RH73
* ldd of tcpdump matches previous version tcpdump-3.6.3-17.7.3.3.i386.rpm
* Changes diffed against
  http://updates.redhat.com/8.0/en/os/SRPMS/tcpdump-3.6.3-17.8.0.3.src.rpm
  - Found two additional patch files as expected:
    Patch20: tcpdump-3.6.2-CAN-2003-0989.patch
    Patch21: tcpdump-3.6.2-CAN-2003-0989-2.patch
    Patches verified against
   
http://updates.redhat.com/enterprise/2.1ES/en/os/SRPMS/tcpdump-3.6.2-12.2.1AS.5.src.rpm
  - I also found autoheader to be uncommented (see diff below) in the spec
    file compared to the last SRPMS for 7.3 and 8.0, which is probably
    harmless.  The 2.1ES srpm does have the change.

- - --- old-8.0/SPECS/tcpdump.spec  Tue May 13 05:55:53 2003
+++ new/SPECS/tcpdump.spec      Fri Jan 16 13:25:14 2004
@@ -176,9 +180,10 @@
 pushd %tcpdump_dir
 %define        optflags $RPM_OPT_FLAGS -DIP_MAX_MEMBERSHIPS=20
- - -#autoheader
+#autoconf
+autoheader
 %configure --enable-ipv6 --with-user=pcap
 %undefine optflags

- - -DEFS="-g -DHAVE_CONFIG_H"
+DEFS="-D_U_=\"\" -g -DHAVE_CONFIG_H"
 %ifarch alpha sparc sparc64
 DEFS="$DEFS -DHAVE_ETHER_HOSTTON=1 -DLBL_ALIGN=1 -DHAVE_ETHER_NTOA=1"

* Passes basic functionality tests on two RH73 machines.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADQTUNTjPeWOqtfsRApPLAKDkTTfPk6xjbniD3gan2c0xfS0TFgCbBehS
o/fyEKZO2gmnYo43rzkt9uY=
=8nUf
-----END PGP SIGNATURE-----




------- Additional Comments From drees 2004-01-20 22:42:31 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forgot to mention this in my previous message:

Vote PUBLISH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADjx7NTjPeWOqtfsRAm7aAJ0QviV6gGJSHZaKmrV02E1nWqjJVgCdEKEj
oNpbAyP4afJmjgz0jWV+Yck=
=XinX
-----END PGP SIGNATURE-----




------- Additional Comments From warren 2004-01-21 00:09:20 ----

David Rees, please be careful about posting several of your previous message. 
Notice how it contains no unique markers specific to any package?  That means
the clearsigned message could be copied into any report in a "replay attack" and
could be used to misrepresent what you mean.  You can defeat the "replay attack"
by including at a minimum the name-version-release.src.rpm of the package that
you mean, and perhaps also the md5sum.

Otherwise thank you for your work.  It takes dedicated folks like you for
packages to become published rather than languish forever.




------- Additional Comments From drees 2004-01-21 07:30:55 ----

Thanks for the tip Warren.  Perhaps it would be good policy to ignore such
messages when trying to determine whether or not to publish a message?  We
should definitely mention this during the QA process documents.



------- Additional Comments From warren 2004-01-21 07:58:32 ----

We do mention this in the QA process document, but it could be more salient. 
Please mention this on the mailing list if you have a chance.

As a process thing fedora.us has enforced ignoring of replayable GPG messages,
and warns the submitter each time it happens.



------- Additional Comments From drees 2004-01-21 08:10:54 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fixing my "replay attack" vulnerable message above:

RH73 38fcdb54299bb93fb0eb0c8c7383d7cb580b82a3  tcpdump-3.6.3-17.7.3.4.legacy.src.rpm

Vote PUBLISH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADsGzNTjPeWOqtfsRAtSsAKCDwRGxqLFYVbDnyjZorOriuebtuACgwItH
rcR6nJ5BK9xGOkm2Dx4k2mg=
=okQk
-----END PGP SIGNATURE-----




------- Additional Comments From pearcec 2004-01-21 12:22:53 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
RH72: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm
RH73: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm
RH80: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm
MD5SUM: http://www.commnav.com/~pearcec/tcpdump-3.6.3-17.x.x.4.md5sum
  
I had to update the MD5SUM file.  We bumped the version of tcpdump for RedHat
8.0.  I didn't do a build on it.  Just a rpmbuild -bs.  So I never tested it.
I should of.  As a result the autoheader didn't work since it is a newer
version.  I updated the BuildRequires to look for autoconf213.  And now
we are calling autoheader-2.13.  Happy QAing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFADvzUdlzgVFWktjoRAl9fAJ9Stpmhc+LK0mSamZBX7t9/7S5mCwCfQVL8
AFSPPfXwz8a3j0/LzuQMJKc=
=Xstz
-----END PGP SIGNATURE-----




------- Additional Comments From jkeating 2004-01-21 13:28:57 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
7.2
 
dc250842304b916a3d894cd5e061cd2537bbacb5  tcpdump-3.6.3-17.7.2.4.legacy.src.rpm
 
+ echo 'Patch #20 (tcpdump-3.6.2-CAN-2003-0989.patch):'
Patch #20 (tcpdump-3.6.2-CAN-2003-0989.patch):
+ patch -p1 -b --suffix .CAN-2003-0989 -s
+ echo 'Patch #21 (tcpdump-3.6.2-CAN-2003-0989-2.patch):'
Patch #21 (tcpdump-3.6.2-CAN-2003-0989-2.patch):
+ patch -p0 -b --suffix .CAN-2003-0989-2 -s
 
Patches apply cleanly, packages build cleanly.
 
Packages install cleanly.  ldds of tcpdump, arpwatch, and /usr/lib/libpcap.so
match from old to new.
 
Basical functionality tests pass.
 
8.0
 
d1aea52958e112e1cb57a7acc540e69dab49f61a  tcpdump-3.6.3-17.8.0.5.legacy.src.rpm
 
 
+ echo 'Patch #20 (tcpdump-3.6.2-CAN-2003-0989.patch):'
Patch #20 (tcpdump-3.6.2-CAN-2003-0989.patch):
+ patch -p1 -b --suffix .CAN-2003-0989 -s
+ echo 'Patch #21 (tcpdump-3.6.2-CAN-2003-0989-2.patch):'
Patch #21 (tcpdump-3.6.2-CAN-2003-0989-2.patch):
+ patch -p0 -b --suffix .CAN-2003-0989-2 -s
 
Patches apply cleanly, packages build cleanly.  ldds of tcpdump, arpwatch, and
/usr/lib/libpcap.so match from old to new.
 
I'm still not sure about bumping the version.  Got some good reasons not to.  I
tend to agree with the reasons not to, while the package is still in bugzilla,
pre updates-testing phase.  So, perhaps bumping -5 back down to -4 would be in
order here.
 
I vote PUBLISH.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFADwqi4v2HLvE71NURAun6AJ0VgCogNlSzP6h9ZhPcQxB3jXQyXwCcCLhX
VnEC2UZ4Cb7KkvuaVrO6XHk=
=VU45
-----END PGP SIGNATURE-----



------- Additional Comments From jkeating 2004-01-21 13:52:15 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
Wed Jan 21 15:55:57 PST 2004
 
Since we have the votes for publish, I'll build these and stick them in
updates-testing tonight, using the -4 release, not the -5.  Any objections?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFADxA74v2HLvE71NURAruaAJwJXnu2oHLxTiitzuD690kNXcJK/QCglijc
we3KEoILVm/X/t15ZvEZobo=
=YKa5
-----END PGP SIGNATURE-----



------- Additional Comments From jonny.strom 2004-01-22 07:05:36 ----

I have downloaded the test version of tcpdump and from my testing so dose it
work ok on RH 7.3.




------- Additional Comments From jkeating 2004-01-22 07:38:52 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Packages published to download.fedoralegacy.org updates-testing

http://download.fedoralegacy.org/redhat/

a10c0d99cd919f459a25fdb5562d6907667b33d3 
7.2/updates-testing/SRPMS/tcpdump-3.6.3-17.7.2.4.legacy.src.rpm
e3777ee05d6b57a81fa08a96b64aa45a0758e42f 
7.2/updates-testing/i386/tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm
8e860cb231b7dd59345c2f82531d527ca78090b5 
7.2/updates-testing/i386/arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm
795dd99495f288aacea6a8775e9aba8eb801e570 
7.2/updates-testing/i386/libpcap-0.6.2-17.7.2.4.legacy.i386.rpm
 
3b7cb6c9f62c259e2c24d056263281a44a5ce406 
7.3/updates-testing/SRPMS/tcpdump-3.6.3-17.7.3.4.legacy.src.rpm
cc1f3f75f7eb32a1ea2aa224cbae64190e5dcaf5 
7.3/updates-testing/i386/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm
7fbb66ee934dcb388489c94551c56ac74c3d0540 
7.3/updates-testing/i386/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm
5aeb410a107e4b82d0f62c6f8931d20998a8e1de 
7.3/updates-testing/i386/libpcap-0.6.2-17.7.3.4.legacy.i386.rpm
 
c9e455ef10ea70f69e269f6d71c3ded700424ca1 
8.0/updates-testing/SRPMS/tcpdump-3.6.3-17.8.0.5.legacy.src.rpm
cbb7cd725a50be1cbdbc8ee75a357229e847afac 
8.0/updates-testing/i386/tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm
1f9aacbd480af1a754adc9d6190ddc06d2b491ab 
8.0/updates-testing/i386/arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm
643931721424765748895f57f4ca53dba896378c 
8.0/updates-testing/i386/libpcap-0.6.2-17.8.0.5.legacy.i386.rpm

Pleae Verify in production.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAEAo+4v2HLvE71NURAnWmAJ9MeaBdH9tfuGgnlmBR+RZ7LI2nwQCgneIS
/Z8UDSXPmzYKbBcS9c4GOSQ=
=7ye6
-----END PGP SIGNATURE-----



------- Additional Comments From jpdalbec 2004-01-22 10:10:19 ----

What does "verify in production" involve?

I installed the tcpdump and arpwatch packages from updates-testing on a VMWare
box.  I ran tcpdump over SSH and it seemed to sniff its own traffic OK.  I'm not
sure how to test arpwatch.

d3d87acfc92a64df3ec7e45310d2998f 
/var/cache/yum/fedora-updates-rhl-73/packages/arpwatch-2.1a11-17.7.3.4.legacy.i386.rpm
30303c168187510fa7ad0a4cd9487b0b 
/var/cache/yum/fedora-updates-rhl-73/packages/tcpdump-3.6.3-17.7.3.4.legacy.i386.rpm

Am I supposed to generate a GPG key and clearsign this?



------- Additional Comments From pearcec 2004-01-28 08:27:40 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
[pearcec@pack pearcec]$ cat /etc/redhat-release
Red Hat Linux release 7.2 (Enigma)
[pearcec@pack pearcec]$ cd /var/cache/yum/updates-testing/packages
[pearcec@pack packages]$ sha1sum arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm
libpcap-0.6.2-17.7.2.4.legacy.i386.rpm tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm
8e860cb231b7dd59345c2f82531d527ca78090b5  arpwatch-2.1a11-17.7.2.4.legacy.i386.rpm
795dd99495f288aacea6a8775e9aba8eb801e570 
libpcap-0.6.2-17.7.2.4.legacy.i386.rpme3777ee05d6b57a81fa08a96b64aa45a0758e42f 
tcpdump-3.6.3-17.7.2.4.legacy.i386.rpm                                         
                                      
[pearcec@pearcec pearcec]$ cat /etc/redhat-release
Red Hat Linux release 8.0 (Psyche)
[pearcec@pearcec pearcec]$ cd /var/cache/yum/updates-testing/packages
[pearcec@pearcec packages]$ sha1sum arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm
libpcap-0.6.2-17.8.0.5.legacy.i386.rpm tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm
1f9aacbd480af1a754adc9d6190ddc06d2b491ab  arpwatch-2.1a11-17.8.0.5.legacy.i386.rpm
643931721424765748895f57f4ca53dba896378c 
libpcap-0.6.2-17.8.0.5.legacy.i386.rpmcbb7cd725a50be1cbdbc8ee75a357229e847afac 
tcpdump-3.6.3-17.8.0.5.legacy.i386.rpm                                         
                                      
rpm --checksig is good
ldd of new cvs binary matches previous RedHat version.
File list of new binary matches old list
Passes basic functionality tests
 
VERIFIED
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFAGABxdlzgVFWktjoRAn2sAJ9++n+2XFycHCApoQ9xhwLXbKmKqwCeIAyq
g+4/gnbQCze9MG97m6r0ve8=
=iq5M
-----END PGP SIGNATURE-----




------- Additional Comments From jkeating 2004-01-31 09:44:04 ----

Pushed to Updates.



------- Bug moved to this database by dkl 2005-03-30 18:23 -------

This bug previously known as bug 1222 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=1222
Originally filed under the Fedora Legacy product and Package request component.

Unknown priority P1. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Unknown severity critical. Setting to default severity "normal".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.



Comment 1 Marc Deslauriers 2005-04-05 22:42:46 UTC
This was resolved a long time ago.


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