Bugzilla Bug 46258

TCPDUMP v3.8.1 and earlier versions contain multiple flaws in the
   packet display functions for the ISAKMP protocol.  Upon receiving
   specially crafted ISAKMP packets, TCPDUMP will try to read beyond
   the end of the packet capture buffer and crash.

The vendor was notified and they have released an updated version
   of TCPDUMP, version 3.8.2, which fixes these defects.  Subsequently,
   the version number was bumped to 3.8.3 to match libpcap.

See the URL for more info.

Reproducible: Always
Steps to Reproduce:

Tobias,

Feel free to start including your recommended tip for resolution on bugs you 
report. Also I know it may seem redundant but could you include the url in the 
body of the report. Reason: Any reporter/commenter can pretty much overwrite 
the  URL field here. http://www.rapid7.com/advisories/R7-0017.html
-thanks.

---------------------------
bumped portage to tcpdump-3.8.3
KEYWORDS="~x86 ~ppc ~sparc ~alpha ~mips ~hppa ~ia64 ~amd64"

current stable tcpdump for arches looks like.
tcpdump-3.7.2.ebuild:KEYWORDS="x86 ppc sparc alpha mips hppa ia64"
tcpdump-3.8.1.ebuild:KEYWORDS="~x86 ppc sparc alpha ~mips hppa ia64 amd64"

Arch maintainers please test and mark stable when ready.

Are we going to be updating libpcap as well (as recommended in the advisory) or
just tcpdump?

libpcap-0.8.3 just added to the portage tree as 
KEYWORDS="~x86 ~ppc ~sparc ~alpha ~mips ~hppa ~amd64 ~ia64"

The depends on the tcpdump could use some love.
First arch testing please try current pcap.

Seems to do the trick for me here with both old and new libpcap.  marked both
libpcap and tcpdump stable on sparc.

mboman, others..

Do you know why libpcap.ebuild installs pcap to /usr/lib/libpcap.so.0.6 ?
Oversight or is this pkg supposed to have some funky magic going like 
openssl? Should it not be /usr/lib/libpcap.so.0.8 ?

AFAICT, this is a dup of bug 38206.

stable on amd64

sparc, ppc, x86: plztest

It's already stable on sparc...

The QA going here has me worried.. You guys are marking stable without 
paying attention at all to comment #6 in regards to both libpcap which
is now KEYWORDS="~x86 ~ppc sparc ~alpha ~mips ~hppa amd64 ~ia64" and the
depends for tcpdump-3.8.3

Comment #6 didn't exist when I stabilized it.  If it's causing known breaks in
programs I'm willing to downgrade it.

Also comment #4

Here is precisely what I think needs to happen for tcpdump.

-DEPEND=">=net-libs/libpcap-0.6.1
-	ssl? ( >=dev-libs/openssl-0.6.9 )"
+DEPEND=">=net-libs/libpcap-0.8.3
+	ssl? ( >=dev-libs/openssl-0.9.6m )"

------------------------------------------------------------------------
And for libpcap
-	gcc -Wl,-soname,libpcap.so.0 -shared -fPIC -o libpcap.so.0.6 *.o
+	gcc -Wl,-soname,libpcap.so.0 -shared -fPIC -o libpcap.so.${PV:0:3} *.o
 	assert "couldn't make a shared lib"
 }
 
@@ -31,9 +31,9 @@ src_install() {
 	einstall || die
 
 	insopts -m 755
-	insinto /usr/lib ; doins libpcap.so.0.6
-	dosym /usr/lib/libpcap.so.0.6 /usr/lib/libpcap.so.0
-	dosym /usr/lib/libpcap.so.0.6 /usr/lib/libpcap.so
+	insinto /usr/lib ; doins libpcap.so.${PV:0:3}
+	dosym /usr/lib/libpcap.so.${PV:0:3} /usr/lib/libpcap.so.0
+	dosym /usr/lib/libpcap.so.${PV:0:3} /usr/lib/libpcap.so

------------------------------------------------------------------------
On my local box I have made these changes then
emerge -C libpcap tcpdump
emerge tcpdump

I can merge these changes if a second developer says that these changes 
look like the ideal solution.

The changes work for me and look good.  If we want to make sure users are using
them though, we may have to -r1 each of them since they are live for all ~arch
users.

updated both packages in portage to -r1 and added generic metadata.xml to
tcpdump

See bug #37184 comment #14. -finline-functions needs to be filtered from CFLAGS
for the same reasons as -O3; -O3 implies -finline-functions, and it is the real
cause of the build problems. Here's the patch I came up with for 3.8.1:

--- tcpdump-3.8.1.ebuild        2004-01-15 09:37:48.000000000 -0500
+++ tcpdump-3.8.1-r1.ebuild     2004-02-11 09:26:35.146081000 -0500
@@ -22,6 +22,7 @@

 src_compile() {
        replace-flags -O[3-9] -O2
+       filter-flags -finline-functions

        econf `use_with ssl crypto` `use_enable ipv6` || die
        make CCOPT="$CFLAGS" || die

Added filter-flags -finline-functions and moved to stable on x86

Current status on tcpdump is as.

libpcap-0.8.3-r1:
KEYWORDS="x86 ppc ~sparc ~alpha ~mips ~hppa ~amd64 ~ia64"

tcpdump-3.8.3-r1:
KEYWORDS="x86 ppc ~sparc ~alpha ~mips ~hppa ~ia64 ~amd64"

sparc & amd64 have the prev revision of both marked stable.
This basicly covers core arches now.

Is this ready for a GLSA then?

I drafted one for bug 38206, which seems like it should apply to both of these.

CondorDes,

Yeah.. It's good to go. 
unless amd64, sparc mark -r1 stable before you send it out 
we just need to be sure to Note the following versions.
>=libpcap-0.8.3
>=tcpdump-3.8.3

sparc is stable with the -r1s for tcpdump and libpcap

I just marked both -r1s stable on amd64.

Thanks.

For the GLSA you can now use.
>=libpcap-0.8.3-r1
>=tcpdump-3.8.3-r1

These are marked stable on alpha and ia64 now

Can two people from security@ please review
https://dev.gentoo.org/glsamaker/frame-view.php?id=aaa20be62fe13261d2cab134e4d3d52f
?

(And can someone who has access please change the unaffected versions listed in
the GLSA to the -r1s that were just added?)

Thanks.

hppa & ppc should be set now

and mips should be set now

The GLSA looks fine to me, there is only a typo: 'responsbile' 

fixed the typo andrea found, changed versions to -r1, added space between
'emerge sync' and the rest of the <code> section to be consistent with earlier
GLSAs.

Also, I upgraded the severity from normal to high since this vuln. allows for
remote execution of arbitrary code, albeit not as root.

klieber -- Can you add the '-r1's to the code in the resolution as well?

...and then is this ready to send?

done and I moved it to 200404-02.  It can't go out until 01 goes out (or I need
to swap numbers with 01)

--kurt

*** Bug 38206 has been marked as a duplicate of this bug. ***

GLSA 200404-03.