| Summary: | TCPDUMP: ISAKMP payload handling denial-of-service vulnerabilities | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Tobias Weisserth <tobias> |
| Component: | GLSA Errors | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | base-system, condordes, netmon, rajiv |
| Priority: | Highest | Flags: | condordes:
Assigned_To+
|
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.rapid7.com/advisories/R7-0017.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 38206 | ||
| Bug Blocks: | |||
|
Description
Tobias Weisserth
2004-03-30 10:40:32 UTC
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. |
