Bug 48763 (CVE-2004-0057)

<!-- 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)