Bugzilla – Bug 48763
VUL-0: CVE-2004-0057: tcpdump ISAKMP overflow
Last modified: 2021-09-29 14:53:54 UTC
From vendor-sec: Date: Sun, 21 Dec 2003 00:04:50 -0500 From: Michael Richardson <mcr@sandelman.ottawa.on.ca> To: vendor-sec@lst.de Cc: George Bakos <gbakos@ists.dartmouth.edu>, Guy Harris <guy@alum.mit.edu> Subject: [vendor-sec] tcpdump 3.8 -----BEGIN PGP SIGNED MESSAGE----- okay. Thanks for the explanations about vendor-sec. tcpdump 3.8, which is in beta (2) has fixes for a vulnerability in the ISAKMP printer. These were found by a code review by George Bakos <gbakos@ists.dartmouth.edu>. I believe that one buffer overflow was most likely exploitable, and the other may depend heavily on a lot of other details. We know of no known exploit at this time. tcpdump 3.8 (and libpcap 0.8) will likely get released on Monday Dec. 22. Someone who reads the logs well could find the changes, but we haven't announced anything about these fixes. Since it is Xmas (and people might not patch immediately), we would propose deferring any security announcement until January, unless there is an exploit that becomes available. I think that the print-isakmp.c patches, or even the entire file, could easily be dropped onto a 3.7.2 tcpdump, if one wished. Although I have not yet tried this.
<!-- SBZ_reproduce --> ...
CVE project has assigned CAN-2003-0989 to it.
Ok, I will fix it.
Thomas, I will need p&p files for this security update, could you send me it?
Created attachment 15582 [details] patchinfo.tcpdump
Created attachment 15583 [details] patchinfo-box.tcpdump
Thnx Thomas. Fixed and submited for sles7-i386, sles7-ppc, 8.0 - STABLE and I will submit p&p files after check-in all packages. The sles7-i386 and sles7-ia64 isn't vulnerable, becouse they have older version of tcpdump which doesn't contain ISAKMP packet.
set up "Internal Bugs Access"
p&p files submited
QA sais the new packages do no resolve names anymore on SLES8 s390/s390x. Any idea? You didnt touch the name resolution no?
Ihno told me that the problem has to be fixed before releasing for sles8 s390/s390x.
Do you have machine, where I can test it? (I mean the machine where problem was found). I haven't seen any problem with resolving.
the problem appeared on s390zvi37 (s390) s390zvi73 (s390x) both machines still got the non-resolving tcpdump installed. Hust run tcpdump and see the not-resolved names. When doing the same with the previous version on another machine the names get resolved: old Version (tcpdump-3.7.1-122): ---------------------------------snip----------------------------------------- +- 17:08:55.350632 F58.suse.de > s390z02.suse.de: icmp: echo request (DF) 17:08:55.350678 s390z02.suse.de > F58.suse.de: icmp: echo reply 17:08:56.351141 F58.suse.de > s390z02.suse.de: icmp: echo request (DF) 17:08:56.351230 s390z02.suse.de > F58.suse.de: icmp: echo reply 17:08:57.351992 F58.suse.de > s390z02.suse.de: icmp: echo request (DF) 17:08:57.352038 s390z02.suse.de > F58.suse.de: icmp: echo reply 17:08:58.352847 F58.suse.de > s390z02.suse.de: icmp: echo request (DF) 17:08:58.352889 s390z02.suse.de > F58.suse.de: icmp: echo reply ---------------------------------snip----------------------------------------- update Version (tcpdump-3.7.1-128): --------------------------------snip------------------------------------------ +- 17:01:02.367860 10.10.102.58 > 10.11.134.101: icmp: echo request (DF) 17:01:02.367892 10.11.134.101 > 10.10.102.58: icmp: echo reply 17:01:03.369088 10.10.102.58 > 10.11.134.101: icmp: echo request (DF) 17:01:03.369131 10.11.134.101 > 10.10.102.58: icmp: echo reply 17:01:04.369622 10.10.102.58 > 10.11.134.101: icmp: echo request (DF) 17:01:04.369654 10.11.134.101 > 10.10.102.58: icmp: echo reply 17:01:05.370540 10.10.102.58 > 10.11.134.101: icmp: echo request (DF) 17:01:05.370580 10.11.134.101 > 10.10.102.58: icmp: echo reply 17:01:06.371538 10.10.102.58 > 10.11.134.101: icmp: echo request (DF) --------------------------------snip------------------------------------------
It is strange, because on s390z04.suse.de it works fine, I will debug it tomorrow.
~hmuelle/Export/tcpdump/ tcpdump-strace.s390z04 tcpdump-strace.s390zvi37 Here you see that s390z04.suse.de is doing a lookup and s390zvi37 isn't doing it. But i don't see anything in the strace, why it isn't. Could it be that the resolving code-snippet is jumped to? At the missing beginning both are making a read of /etc/nsswitch.conf I used this to lines from s390z04.suse.de to s390zvi37.suse.de and vice verse You have only to adjust the host when using telnet. This is convinient to get only one packet. s390zvi37:~ # strace -f -ff -o tcpdump.strace tcpdump dst port 10011 s390zvi37:~ # telnet s390z04 10011
This is no new tcpdump problem. The original tcpdump from SLES8 has the same problem.
We got additional buginfo for different bugs: Date: Mon, 12 Jan 2004 22:21:23 +0100 From: Jonathan Heusser <jonny@drugphish.ch> To: security@debian.org Subject: multiple vulnerabilities in tcpdump 3.8.1 and below Hello security@debian.org, On the 4th January I reported two critical security bugs to the tcpdump-workers mailinglist. The bugs have now been fixed in the CVS version. Anyway I thought it may be well to notify you about this vulnerabilities too. The original post can be found at: http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2 Thank you, jonathan .... Another mail reads: I've extracted the following from CVS which I hope is all that's required for these two issues: --- print-isakmp.c 20 Dec 2003 10:03:19 -0000 1.41 +++ print-isakmp.c 7 Jan 2004 08:00:51 -0000 1.42 @@ -30,7 +30,7 @@ #ifndef lint static const char rcsid[] _U_ = - "@(#) $Header: /tcpdump/master/tcpdump/print-isakmp.c,v 1.40 2003/12/20 09:58:10 guy Exp $ (LBL)"; + "@(#) $Header: /tcpdump/master/tcpdump/print-isakmp.c,v 1.41 2003/12/20 10:03:19 guy Exp $ (LBL)"; #endif #ifdef HAVE_CONFIG_H @@ -327,9 +327,13 @@ static u_char *p; size_t i; + TCHECK2(*loc, len); + p = (u_char *)loc; for (i = 0; i < len; i++) printf("%02x", p[i] & 0xff); +trunc: + } struct attrmap { @@ -1111,6 +1115,8 @@ cp = (const u_char *)ext; while (np) { + TCHECK2(*ext, sizeof(e)); + safememcpy(&e, ext, sizeof(e)); if (ep < (u_char *)ext + ntohs(e.len)) { @@ -1136,6 +1142,8 @@ ext = (struct isakmp_gen *)cp; } return cp; +trunc: + return NULL; } static char * --- print-radius.c 15 Dec 2003 13:52:15 -0000 1.23 +++ print-radius.c 7 Jan 2004 08:00:52 -0000 1.24 @@ -44,7 +44,7 @@ #ifndef lint static const char rcsid[] _U_ = - "$Id: print-radius.c,v 1.22 2003/11/26 08:49:15 hannes Exp $"; + "$Id: print-radius.c,v 1.23 2003/12/15 13:52:15 hannes Exp $"; #endif #ifdef HAVE_CONFIG_H @@ -476,7 +476,7 @@ break; } - for (i=0; i < length ; i++, data++) + for (i=0; *data && i < length ; i++, data++) printf("%c",(*data < 32 || *data > 128) ? '.' : *data ); return; So it seems we have to do the whole procedure again... :/
reassigned to Harald on request .
I fixed bug with not-resolved names (backported) and successfuly tested on s390zvi37(s390), s390zvi73(s390x). Today I fix second security bug in isakmp and in radius and will submit it together.
Thomas, I will need p&p file for second security update of tcpump, could you send me it, please? All information about this second security bug is in http://marc.theaimsgroup.com/?l=tcpdump-workers&m=107325073018070&w=2
I will write the p&p files. Did you already send a laufzettel? Which versions are affected? 8.2 and 9.0?
Created attachment 15669 [details] patchinfo for the new bugs Please remove distribution strings from list if they are not affected.
Created attachment 15670 [details] box patchinfo for the new bugs please remove distribution strings if they are not affected.
First, I didn't send a laufzettel. I found on http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tcpdump another security bug CAN-2003-1029 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1029) and I hope, that is for this fix update the lastest ;)... recapitulation: I fixed for second security update CAN-2003-1029 (l2tp), CAN-2004-0055 (radius), CAN-2004-0057 (isakmp) Affected distributions: 8.0-i386, 8.1-i386, 8.2-i386, 9.0-i386, 9.0-x86_64, sles7-ppc, sles7-s390x, sles8-beta-ppc, sles8-beta-s390, sles8-beta-s390x, sles8-i386, sles8-ppc, sles8-s390, sles8-s390x, sles8-slec-i386, ul1-beta-i386, ul1-beta-ia64, ul1-beta-x86_64, ul1-i386, ul1-ia64, ul1-x86_64 Not affected distributions: 7.2-s390, sles7-i386, sles7-ia64 Not-resolved-bug I fixed only for 8.1: 8.1-i386, sles8-beta-ppc, sles8-beta-s390, les8-beta-s390x, sles8-i386, sles8-ppc, sles8-s390, sles8-s390x, sles8-slec-i386, ul1-beta-i386, ul1-beta-ia64, ul1-beta-x86_64, ul1-i386, ul1-ia64, ul1-x86_64 I will submit it all after prepare all packages...
I submited all affected packages except STABLE (there I will make version update). After autobuild rebuild rpms I will submit p&p files.
Rpms was rebuilded and I submited p&p files.
Hi Sebastian. I assign this to you for tracking.
I approved the packages a few desconds ago and close this bug now.
CVE-2004-0057: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)