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.
