May 2000 - Test - lists.nanog.org

Re[2]: Class B address routing
by Kenji Anzai 18 May '00

18 May '00

Hi, All. Thanks to Todd & All of you helped us. We are really appreciated your help and suggestions. I think that we can do this now. Thanks to all again. Regards, Kenji Anzai On Thu, 18 May 2000 19:33:54 -0400 (EDT) Todd Romero <todd(a)routeflap.net> wrote: > > easily done..redistribute static into bgp with a route map. one /16 static > and one /17 static pointing to Null0. the more specific will override the > /16 always even tho its still there. > > > router bgp xxxx > redistribute static route-map static-to-bgp > ! > ip route x.x.x.x 255.255.0.0 Null0 254 > ip route x.x.x.x 255.255.128.0 Null0 254 > ! > access-list 10 permit x.x.x.x 0.0.255.255 > access-list 10 permit x.x.x.x 0.127.255.255 > ! > route-map static-to-bgp permit 10 > match ip address 10 > ! > > > the only difference at each pop.. your /17 will be different in the static > and ACL. > > > On Thu, 18 May 2000, Kenji Anzai wrote: > > > > > Hi, All. > > > > Thanks for all your replay to help us out. > > They were really helpful. > > > > However, let me add some mor info for this question. > > > > 1. We have 2 routers at each POP, and own AS number. > > 2. The routers use EBGP, and use IBGP between the routers at each POP > > (not between POP). > > 3. 2 POP are located at different location. > > 4. We use same data center company's data center, so our network is > > under the company's network. > > 5. The data center won't aggrigate our netowrk as /16. > > > > After I read all your response, How could we annouce /16 and /17 from > > the same router using BGP ? > > > > Regards, > > > > Kenji > > > > > > On Thu, 18 May 2000 14:04:15 -0400 > > Kenji Anzai <kenji(a)itochu.net> wrote: > > > > > > > > Hi, All. > > > > > > I'm having problem with our class B address. Last month, we tested our class B address. We announce the address as 2 x /17 from 2 different POP under the same ISP's data center. However, some ISP do NOT accept our route since the address belongs to traditional Class B address, and they told me that they only accept if we announce it as /16. (They filtered out our route…..) > > > > > > I talked to some people, they suggested me that we need to announce the block as /16 from both POP, even though we only like to announce /17 from each POP (Front /17 from one POP, the other /17 from another POP.). > > > > > > How could we do so ? Please help us. > > > > > > |--------- | > > > | POP A | > > > | /17 |------| > > > |----------| | |--------| > > > |-----| ISP C |-- Internet---X----ISP D > > > | ---------| | |--------| Filtered out here… > > > | POP B |------| > > > | /17 | > > > ----------- > > > > > > Regards, > > > > > > Kenji Anzai > > > > > > > > > > > > > > > ITIの安齋です。 > > お世話になっております。 > > > > > > ***携帯電話の番号が変わりました*** > > > > *************************************** > > > > Kenji Anzai > > > > Network Engineer > > > > Engineering Department > > Network Operation Group > > > > Itochu Technology, Inc. > > 3100 Patrick Henry Drive > > Santa Clara, CA 94504 > > > > Tel: (408) 653-2817 (Direct) > > Fax: (408) 727-4619 > > Cellular: (408) 910-4170 > > Email: kenji(a)itochu.net > > Pager:1-888-830-3638 > > kenji_pager(a)itochu.net > > (English Only) > > *************************************** > > > > ITIの安齋です。お世話になっております。 ***携帯電話の番号が変わりました*** *************************************** Kenji Anzai Network Engineer Engineering Department Network Operation Group Itochu Technology, Inc. 3100 Patrick Henry Drive Santa Clara, CA 94504 Tel: (408) 653-2817 (Direct) Fax: (408) 727-4619 Cellular: (408) 910-4170 Email: kenji(a)itochu.net Pager:1-888-830-3638 kenji_pager(a)itochu.net (English Only) ***************************************

1 0

Re[2]: Class B address routing
by Kenji Anzai 18 May '00

18 May '00

Hello, Glenn. I already tried it, but they (Our ISP ) told me that they won't do it. At first, they said that they will. However, they said that they won't do it later.... Then, I got this problem... Kenji On Thu, 18 May 2000 17:34:46 -0400 (EDT) Glenn Staniforth <glenns(a)UUNET.CA> wrote: > > > Hello Kenji, > > Do you have your own AS number? Unless I am mistaken, if you do ,the > easiest solution would be to advertise both your /17's vis BGP to your > ISP. So long as they accept them and aggregate your /17's into a /16 you > should have no problems... > > > Glenn Staniforth > MTL CNS Team Lead > UUNET, a Worldcom Company > Tel: (514) 871-2731 > Fax: (514) 875-5735 > http://www.uu.net > http://www.uunet.ca > > On Thu, 18 May 2000, Kenji Anzai wrote: > > > > > Hi, All. > > > > I'm having problem with our class B address. Last month, we tested our class B address. We announce the address as 2 x /17 from 2 different POP under the same ISP's data center. However, some ISP do NOT accept our route since the address belongs to traditional Class B address, and they told me that they only accept if we announce it as /16. (They filtered out our route…..) > > > > I talked to some people, they suggested me that we need to announce the block as /16 from both POP, even though we only like to announce /17 from each POP (Front /17 from one POP, the other /17 from another POP.). > > > > How could we do so ? Please help us. > > > > |--------- | > > | POP A | > > | /17 |------| > > |----------| | |--------| > > |-----| ISP C |-- Internet---X----ISP D > > | ---------| | |--------| Filtered out here… > > | POP B |------| > > | /17 | > > ----------- > > > > Regards, > > > > Kenji Anzai > > > > > > ITIの安齋です。お世話になっております。 ***携帯電話の番号が変わりました*** *************************************** Kenji Anzai Network Engineer Engineering Department Network Operation Group Itochu Technology, Inc. 3100 Patrick Henry Drive Santa Clara, CA 94504 Tel: (408) 653-2817 (Direct) Fax: (408) 727-4619 Cellular: (408) 910-4170 Email: kenji(a)itochu.net Pager:1-888-830-3638 kenji_pager(a)itochu.net (English Only) ***************************************

2 1

Re: IGPs and services?
by ww＠shadowfax.styx.org 18 May '00

18 May '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >>>>> "Roeland" == Roeland Meyer (E-mail) <rmeyer(a)mhsc.com> writes: >> From: jlewis(a)lewis.org: Wednesday, May 17, 2000 7:15 PM >> Running a routing protocol on a unix box doesn't mean you're >> using it as a router. Roeland> Oh? ... routing, is routing. The distinction is between a device having knowledge of routing tables and forwarding packets -- in fact in most instances where I am doing something like this I have "net.inet.ip.forwarding = 0". - -w - -- Will Waites \________ ww(a)shadowfax.styx.org\____________________________ Idiosyntactix Ministry of Research and Development\ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (OpenBSD) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/> iQEXAwUBOSQmzQ4cK24IcAwYFAOOlgQAl3Own4xlX5/TkLwwOvHkKdsUHnAY+iBf 2gVYyyvuZ3hoCPvlnOQQkdSFminq7aqPTKldHa1hNkJ7ocoeaYt/9m9/6mXufkHs Z7asWICn6ZkPatOCVr/2fBww8aBATFih7s++j3eXkazc+qBlytPrfhejuFuiy46M vAvGZAKMzDgD/R12yaXjq9kXLD5zWpeBkafWVQvYqfVDDD/oDxFA6mkx/3glCuej xMaj/aOBzHxUGe5AyiKBwHI1i14yElOdvcsmdKLKUKYxyX0dA4cH2DYazfOOgezF 78atAVuDMWD/90IP1blYZnnT13WvS/ULSgpit74L/k87IfBlfugX7Cyu =Rcs6 -----END PGP SIGNATURE-----

2 1

Private ASN suppression
by Howard C. Berkowitz 18 May '00

18 May '00

I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit? RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.

4 5

RE: CIDR Report
by wolfgang＠whnet.com 18 May '00

18 May '00

> > > In any case, I think the point is made that we can talk > > all we want about how we want <insert router vendor > > name here> to provide a truly high-end > > router that solves everything, but the reality of the cost > > pressure does need to be considered.... > > That is one major point, maybe the entire point. > This suggests a generally flatter architecture, maybe parallel. Still remember the supercomputer discussions a few years back when experts argued if either KSR or Thinking Machines is going to be *the* big win? And today when you need a lot of processing e.g. for rendering, you simply stick a couple dozen Pentiums on a fast switched ethernet.

5 4

BUFFER OVERRUN VULNERABILITIES IN KERBEROS (fwd)
by Steve Bellovin 17 May '00

17 May '00

------- Forwarded Message Return-Path: <owner-bugtraq(a)SECURITYFOCUS.COM> Received: from 127.0.0.1 by fetchmail-4.5.7 POP3 for <smb/localhost> (single-drop); Wed, 17 May 2000 16:03:19 EDT Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA18750 for <smb(a)postal.research.att.com>; Wed, 17 May 2000 14:47:44 -0400 (EDT) Received: by mail-green.research.att.com (Postfix) id 6DA6C1E033; Wed, 17 May 2000 14:47:43 -0400 (EDT) Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]) by mail-green.research.att.com (Postfix) with ESMTP id 420CC1E019 for <smb(a)RESEARCH.ATT.COM>; Wed, 17 May 2000 14:47:42 -0400 (EDT) Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]) by lists.securityfocus.com (Postfix) with ESMTP id 37C071F97B; Wed, 17 May 2000 11:36:06 -0700 (PDT) Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9633298 for BUGTRAQ(a)LISTS.SECURITYFOCUS.COM; Wed, 17 May 2000 11:34:51 -0700 Received: from securityfocus.com (mail.securityfocus.com [207.126.127.78]) by lists.securityfocus.com (Postfix) with SMTP id 3B5FC1F700 for <bugtraq(a)lists.securityfocus.com>; Tue, 16 May 2000 12:09:14 -0700 (PDT) Received: (qmail 25616 invoked by alias); 16 May 2000 19:09:10 -0000 Received: (qmail 25608 invoked from network); 16 May 2000 19:09:09 -0000 Received: from road-warrior-177.mit.edu (18.177.3.178) by mail.securityfocus.com with SMTP; 16 May 2000 19:09:09 -0000 Received: (from jis@localhost) by ROAD-WARRIOR-177.MIT.EDU (8.8.7/8.8.7) id PAA00633; Tue, 16 May 2000 15:09:05 -0400 jis(a)mit.edu using -f Delivered-To: smb(a)research.att.com Approved-By: aleph1(a)SECURITYFOCUS.COM Delivered-To: bugtraq(a)lists.securityfocus.com Delivered-To: bugtraq(a)securityfocus.com X-Authentication-Warning: ROAD-WARRIOR-177.MIT.EDU: jis set sender to jis(a)mit.edu using -f Message-ID: <200005161909.PAA00633(a)ROAD-WARRIOR-177.MIT.EDU> Date: Tue, 16 May 2000 15:09:05 -0400 Reply-To: "Jeffrey I. Schiller" <jis(a)MIT.EDU> Sender: Bugtraq List <BUGTRAQ(a)SECURITYFOCUS.COM> From: "Jeffrey I. Schiller" <jis(a)MIT.EDU> Subject: BUFFER OVERRUN VULNERABILITIES IN KERBEROS X-To: kerberos(a)mit.edu, bugtraq(a)securityfocus.com To: BUGTRAQ(a)SECURITYFOCUS.COM Content-Type: text X-UIDL: 54432cb591e46cfb2f0b3b397b08a6d3 - -----BEGIN PGP SIGNED MESSAGE----- BUFFER OVERRUN VULNERABILITIES IN KERBEROS SUMMARY: Serious buffer overrun vulnerabilities exist in many implementations of Kerberos 4, including implementations included for backwards compatibility in Kerberos 5 implementations. Other less serious buffer overrun vulnerabilites have also been discovered. ALL KNOWN KERBEROS 4 IMPLEMENTATIONS derived from MIT sources are believed to be vulnerable. IMPACT: * A remote user may gain unauthorized root access to a machine running services authenticated with Kerberos 4. * A remote user may gain unauthorized root access to a machine running krshd, regardless of whether the program is configured to accept Kerberos 4 authentication. * A local user may gain unauthorized root access by exploiting v4rcp or ksu. DETAILS: The MIT Kerberos Team has been made aware of a security vulnerability in the Kerberos 4 compatibility code contained within the MIT Kerberos 5 source distributions. This vulnerability consists of a buffer overrun in the krb_rd_req() function, which is used by essentially all Kerberos-authenticated services that use Kerberos 4 for authentication. It is possible for an attacker to gain root access over the network by exploiting this vulnerability. An exploit is known to exist for the Kerberized Berkeley remote shell daemon (krshd) for at least the i386-Linux platform, and possibly others. The extent of distribution of this exploit is unknown at this time. Other buffer overruns have been discovered as well, though with less far-reaching impact. The existing exploit does not directly use the buffer overrun in krb_rd_req(); rather, it uses the buffer that was overrun by krb_rd_req() to exploit a second overrun in krb425_conv_principal(). The krb_rd_req() code itself might not be exploitable once the overrun in krb425_conv_principal() is repaired, though it is likely that some other method of exploit may be found that does not require that an overrun exist in krb425_conv_principal(). VULNERABLE DISTRIBUTIONS AND PROGRAMS: Source distributions which may contain vulnerable code include: MIT Kerberos 5 releases krb5-1.0.x, krb5-1.1, krb5-1.1.1 MIT Kerberos 4 patch 10, and likely earlier releases as well KerbNet (Cygnus implementation of Kerberos 5) Cygnus Network Security (CNS -- Cygnus implementation of Kerberos 4) Daemons or services that may call krb_rd_req() and are thus vulnerable to remote exploit include: krshd klogind (if accepting Kerberos 4 authentication) telnetd (if accepting Kerberos 4 authentication) ftpd (if accepting Kerberos 4 authentication) rkinitd kpopd In addition, it is possible that the v4rcp program, which is usually installed setuid to root, may be exploited by a local user to gain root access by means of exploiting the krb_rd_req vulnerability. The ksu program in some MIT Kerberos 5 releases has a vulnerability that may result in unauthorized local root access. This bug was fixed in krb5-1.1.1, as well as in krb5-1.0.7-beta1. Release krb5-1.1, as well as krb5-1.0.6 and earlier, are believed to be vulnerable. There is an unrelated buffer overrun in the krshd that is distributed with at least the MIT Kerberos 5 source distributions. It is not known whether an exploit exists for this buffer overrun. It is also not known whether this buffer overrun is actually exploitable. WORKAROUNDS: Certain daemons that are called from inetd may be safe from exploitation if their command line invocation is modified to exclude the use of Kerberos 4 for authentication. Please consult the manpages or other documentation for your Kerberos distribution in order to determine the correct command line for disabling Kerberos 4 authentication. Daemons for which this approach may work include: krshd (*) klogind telnetd (*) The krshd program may still be vulnerable to remote attack if Kerberos 4 authentication is disabled, due to the unrelated buffer overrun mentioned above. It is best to disable the krshd program completely until a patched version can be installed. The v4rcp program should have its setuid permission removed, since it may be possible to perform a local exploit against it. The krb5 ksu program should have its setuid premission removed, if it was not compiled from krb5-1.1.1, krb5-1.0.7-beta1, or later code. Merely replacing the ksu binary with one compiled from krb5-1.1.1 or krb5-1.0.7-beta1 should be safe, provided that it is not compiled with shared libraries (the vulnerability is related to some library bugs). If ksu was compiled with shared libraries, it may be best to install a new release that has the library bug fixed. In the MIT Kerberos 5 releases, it may not be possible to disable Kerberos 4 authentication in the ftpd program. Note that only releases krb5-1.1 and later will have the ability to receive Kerberos 4 authentication. FIXES: The best course of action is to patch the code in the krb4 library, in addition to patching the code in the krshd program. The following patches include some less essential patches that also affect buffer overruns in potentially vulnerable code, but for which exploits are somewhat more difficult to construct. Please note that there are two sets of patches in this file that apply against identically named files in two different releases. You should separate out the patch set that is relevant to you prior to applying them; otherwise, you may inadvertently patch some files twice. MIT will soon release krb5-1.2, which will have these changes incorporated. PATCHES AGAINST krb5-1.0.x: The following are patches against 1.0.7-beta1 (roughly). The most critical ones are: appl/bsd/krshd.c lib/krb4/rd_req.c lib/krb5/krb/conv_princ.c The rest are not as important but you may wish to apply them anyway out of paranoia. These patches may apply with a little bit of fuzz against releases prior to krb5-1.0.7-beta1, but there likely have not been significant changes in the affected code. These patches may also apply against KerbNet. The lib/krb4/rd_req.c patch may also apply against CNS and MIT Kerberos 4. Index: appl/bsd/krshd.c =================================================================== RCS file: /cvs/krbdev/krb5/src/appl/bsd/krshd.c,v retrieving revision 5.66.2.6 diff -c -r5.66.2.6 krshd.c *** krshd.c 1999/03/09 00:27:31 5.66.2.6 - - --- krshd.c 2000/04/29 02:58:52 *************** *** 1469,1483 **** strcpy((char *) cmdbuf + offst, kprogdir); cp = copy + 3 + offst; if (auth_sys == KRB5_RECVAUTH_V4) { ! strcat(cmdbuf, "/v4rcp"); } else { ! strcat(cmdbuf, "/rcp"); } if (stat((char *)cmdbuf + offst, &s) >= 0) ! strcat(cmdbuf, cp); else ! strcpy(cmdbuf, copy); free(copy); } #endif - - --- 1469,1484 ---- strcpy((char *) cmdbuf + offst, kprogdir); cp = copy + 3 + offst; + cmdbuf[sizeof(cmdbuf) - 1] = '\0'; if (auth_sys == KRB5_RECVAUTH_V4) { ! strncat(cmdbuf, "/v4rcp", sizeof(cmdbuf) - 1 - strlen(cmdbuf)); } else { ! strncat(cmdbuf, "/rcp", sizeof(cmdbuf) - 1 - strlen(cmdbuf)); } if (stat((char *)cmdbuf + offst, &s) >= 0) ! strncat(cmdbuf, cp, sizeof(cmdbuf) - 1 - strlen(cmdbuf)); else ! strncpy(cmdbuf, copy, sizeof(cmdbuf) - 1 - strlen(cmdbuf)); free(copy); } #endif Index: lib/krb4/kuserok.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb4/kuserok.c,v retrieving revision 1.3 diff -c -r1.3 kuserok.c *** kuserok.c 1996/01/27 06:06:22 1.3 - - --- kuserok.c 2000/04/29 02:59:02 *************** *** 115,122 **** if ((pwd = getpwnam(luser)) == NULL) { return(NOTOK); } ! (void) strcpy(pbuf, pwd->pw_dir); ! (void) strcat(pbuf, "/.klogin"); if (access(pbuf, F_OK)) { /* not accessible */ /* - - --- 115,125 ---- if ((pwd = getpwnam(luser)) == NULL) { return(NOTOK); } ! if (strlen (pwd->pw_dir) + sizeof ("/.klogin") >= sizeof (pbuf)) ! return NOTOK; ! (void) strncpy(pbuf, pwd->pw_dir, sizeof(pbuf) - 1); ! pbuf[sizeof(pbuf) - 1] = '\0'; ! (void) strncat(pbuf, "/.klogin", sizeof(pbuf) - 1 - strlen(pbuf)); if (access(pbuf, F_OK)) { /* not accessible */ /* Index: lib/krb4/rd_req.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb4/rd_req.c,v retrieving revision 1.4 diff -c -r1.4 rd_req.c *** rd_req.c 1996/02/24 14:29:26 1.4 - - --- rd_req.c 2000/04/29 02:59:02 *************** *** 155,160 **** - - --- 155,162 ---- Kerberos used to encrypt ticket */ int status; + tkt->mbz = req_id->mbz = 0; + if (authent->length <= 0) return(RD_AP_MODIFIED); *************** *** 190,197 **** mutual = 0; #endif /* lint */ s_kvno = *ptr++; /* get server key version */ ! (void) strcpy(realm,ptr); /* And the realm of the issuing KDC */ ! ptr += strlen(ptr) + 1; /* skip the realm "hint" */ /* * If "fn" is NULL, key info should already be set; don't - - --- 192,200 ---- mutual = 0; #endif /* lint */ s_kvno = *ptr++; /* get server key version */ ! (void) strncpy(realm,ptr,REALM_SZ); /* And the realm of the issuing KDC */ ! realm[REALM_SZ-1] = '\0'; ! ptr += strlen(realm) + 1; /* skip the realm "hint" */ /* * If "fn" is NULL, key info should already be set; don't *************** *** 277,289 **** #define check_ptr() if ((ptr - (char *) req_id->dat) > req_id->length) return(RD_AP_MODIFIED); ptr = (char *) req_id->dat; ! (void) strcpy(r_aname,ptr); /* Authentication name */ ptr += strlen(r_aname)+1; check_ptr(); ! (void) strcpy(r_inst,ptr); /* Authentication instance */ ptr += strlen(r_inst)+1; check_ptr(); ! (void) strcpy(r_realm,ptr); /* Authentication name */ ptr += strlen(r_realm)+1; check_ptr(); memcpy((char *)&ad->checksum, ptr, 4); /* Checksum */ - - --- 280,295 ---- #define check_ptr() if ((ptr - (char *) req_id->dat) > req_id->length) return(RD_AP_MODIFIED); ptr = (char *) req_id->dat; ! (void) strncpy(r_aname,ptr,ANAME_SZ); /* Authentication name */ ! r_aname[ANAME_SZ-1] = '\0'; ptr += strlen(r_aname)+1; check_ptr(); ! (void) strncpy(r_inst,ptr,INST_SZ); /* Authentication instance */ ! r_inst[INST_SZ-1] = '\0'; ptr += strlen(r_inst)+1; check_ptr(); ! (void) strncpy(r_realm,ptr,REALM_SZ); /* Authentication name */ ! r_realm[REALM_SZ-1] = '\0'; ptr += strlen(r_realm)+1; check_ptr(); memcpy((char *)&ad->checksum, ptr, 4); /* Checksum */ Index: lib/krb5/krb/conv_princ.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb5/krb/conv_princ.c,v retrieving revision 1.19.8.1 diff -c -r1.19.8.1 conv_princ.c *** conv_princ.c 1999/02/07 00:52:01 1.19.8.1 - - --- conv_princ.c 2000/04/29 02:59:04 *************** *** 243,249 **** if (retval == 0 && full_name && full_name[0]) { instance = full_name[0]; } else { ! strcpy(buf, instance); retval = krb5_get_realm_domain(context, realm, &domain); if (retval) return retval; - - --- 243,250 ---- if (retval == 0 && full_name && full_name[0]) { instance = full_name[0]; } else { ! strncpy(buf, instance, sizeof(buf)); ! buf[sizeof(buf) - 1] = '\0'; retval = krb5_get_realm_domain(context, realm, &domain); if (retval) return retval; *************** *** 251,258 **** for (cp = domain; *cp; cp++) if (isupper(*cp)) *cp = tolower(*cp); ! strcat(buf, "."); ! strcat(buf, domain); krb5_xfree(domain); } instance = buf; - - --- 252,259 ---- for (cp = domain; *cp; cp++) if (isupper(*cp)) *cp = tolower(*cp); ! strncat(buf, ".", sizeof(buf) - 1 - strlen(buf)); ! strncat(buf, domain, sizeof(buf) - 1 - strlen(buf)); krb5_xfree(domain); } instance = buf; Index: lib/krb5/os/kuserok.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb5/os/kuserok.c,v retrieving revision 5.19 diff -c -r5.19 kuserok.c *** kuserok.c 1996/06/12 05:15:02 5.19 - - --- kuserok.c 2000/04/29 02:59:04 *************** *** 77,84 **** if ((pwd = getpwnam(luser)) == NULL) { return(FALSE); } ! (void) strcpy(pbuf, pwd->pw_dir); ! (void) strcat(pbuf, "/.k5login"); if (access(pbuf, F_OK)) { /* not accessible */ /* - - --- 77,85 ---- if ((pwd = getpwnam(luser)) == NULL) { return(FALSE); } ! (void) strncpy(pbuf, pwd->pw_dir, sizeof(pbuf) - 1); ! pbuf[sizeof(pbuf) - 1] = '\0'; ! (void) strncat(pbuf, "/.k5login", sizeof(pbuf) - 1 - strlen(pbuf)); if (access(pbuf, F_OK)) { /* not accessible */ /* Index: lib/krb5/posix/syslog.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb5/posix/syslog.c,v retrieving revision 5.7 diff -c -r5.7 syslog.c *** syslog.c 1996/06/12 05:16:04 5.7 - - --- syslog.c 2000/04/29 02:59:04 *************** *** 115,121 **** (void)sprintf(tbuf, "<%d>%.15s ", pri, ctime(&now) + 4); for (p = tbuf; *p; ++p); if (LogTag) { ! (void)strcpy(p, LogTag); for (; *p; ++p); } if (LogStat & LOG_PID) { - - --- 115,121 ---- (void)sprintf(tbuf, "<%d>%.15s ", pri, ctime(&now) + 4); for (p = tbuf; *p; ++p); if (LogTag) { ! (void)strncpy(p, LogTag, sizeof(tbuf) - 1 - (p - tbuf)); for (; *p; ++p); } if (LogStat & LOG_PID) { *************** *** 146,151 **** - - --- 146,156 ---- } (void)vsprintf(p, fmt_cpy, ap); + /* Bounds checking?? If a system doesn't have syslog, we + probably can't rely on it having vsnprintf either. Try not + to let a buffer overrun be exploited. */ + if (strlen (tbuf) >= sizeof (tbuf)) + abort (); /* output the message to the local logger */ if (send(LogFile, tbuf, cnt = strlen(tbuf), 0) >= 0 || *************** *** 169,175 **** if ((fd = open(CONSOLE, O_WRONLY, 0)) < 0) return; (void)alarm((u_int)0); ! (void)strcat(tbuf, "\r"); p = strchr(tbuf, '>') + 1; (void)write(fd, p, cnt + 1 - (p - tbuf)); (void)close(fd); - - --- 174,181 ---- if ((fd = open(CONSOLE, O_WRONLY, 0)) < 0) return; (void)alarm((u_int)0); ! tbuf[sizeof(tbuf) - 1] = '\0'; ! (void)strncat(tbuf, "\r", sizeof(tbuf) - 1 - strlen(tbuf)); p = strchr(tbuf, '>') + 1; (void)write(fd, p, cnt + 1 - (p - tbuf)); (void)close(fd); PATCHES AGAINST krb5-1.1.1: The following are patches against 1.1.1. The most critical ones are: appl/bsd/krshd.c lib/krb4/rd_req.c lib/krb5/krb/conv_princ.c The rest are not as important but you may wish to apply them anyway out of paranoia. Index: appl/bsd/krshd.c =================================================================== RCS file: /cvs/krbdev/krb5/src/appl/bsd/krshd.c,v retrieving revision 5.79.2.1 diff -c -r5.79.2.1 krshd.c *** krshd.c 1999/08/23 18:55:10 5.79.2.1 - - --- krshd.c 2000/04/29 03:00:38 *************** *** 1468,1482 **** strcpy((char *) cmdbuf + offst, kprogdir); cp = copy + 3 + offst; if (auth_sys == KRB5_RECVAUTH_V4) { ! strcat(cmdbuf, "/v4rcp"); } else { ! strcat(cmdbuf, "/rcp"); } if (stat((char *)cmdbuf + offst, &s) >= 0) ! strcat(cmdbuf, cp); else ! strcpy(cmdbuf, copy); free(copy); } #endif - - --- 1468,1483 ---- strcpy((char *) cmdbuf + offst, kprogdir); cp = copy + 3 + offst; + cmdbuf[sizeof(cmdbuf) - 1] = '\0'; if (auth_sys == KRB5_RECVAUTH_V4) { ! strncat(cmdbuf, "/v4rcp", sizeof(cmdbuf) - 1 - strlen(cmdbuf)); } else { ! strncat(cmdbuf, "/rcp", sizeof(cmdbuf) - 1 - strlen(cmdbuf)); } if (stat((char *)cmdbuf + offst, &s) >= 0) ! strncat(cmdbuf, cp, sizeof(cmdbuf) - 1 - strlen(cmdbuf)); else ! strncpy(cmdbuf, copy, sizeof(cmdbuf) - 1 - strlen(cmdbuf)); free(copy); } #endif Index: lib/krb4/kuserok.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb4/kuserok.c,v retrieving revision 1.5 diff -c -r1.5 kuserok.c *** kuserok.c 1997/09/26 02:41:41 1.5 - - --- kuserok.c 2000/04/29 03:00:53 *************** *** 118,125 **** if ((pwd = getpwnam(luser)) == NULL) { return(NOTOK); } ! (void) strcpy(pbuf, pwd->pw_dir); ! (void) strcat(pbuf, "/.klogin"); if (access(pbuf, F_OK)) { /* not accessible */ /* - - --- 118,128 ---- if ((pwd = getpwnam(luser)) == NULL) { return(NOTOK); } ! if (strlen (pwd->pw_dir) + sizeof ("/.klogin") >= sizeof (pbuf)) ! return NOTOK; ! (void) strncpy(pbuf, pwd->pw_dir, sizeof(pbuf) - 1); ! pbuf[sizeof(pbuf) - 1] = '\0'; ! (void) strncat(pbuf, "/.klogin", sizeof(pbuf) - 1 - strlen(pbuf)); if (access(pbuf, F_OK)) { /* not accessible */ /* Index: lib/krb4/rd_req.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb4/rd_req.c,v retrieving revision 1.9 diff -c -r1.9 rd_req.c *** rd_req.c 1999/02/09 02:57:14 1.9 - - --- rd_req.c 2000/04/29 03:00:53 *************** *** 184,189 **** - - --- 184,191 ---- krb5_keyblock keyblock; int status; + tkt->mbz = req_id->mbz = 0; + if (authent->length <= 0) return(RD_AP_MODIFIED); *************** *** 219,226 **** mutual = 0; #endif /* lint */ s_kvno = *ptr++; /* get server key version */ ! (void) strcpy(realm,ptr); /* And the realm of the issuing KDC */ ! ptr += strlen(ptr) + 1; /* skip the realm "hint" */ /* * If "fn" is NULL, key info should already be set; don't - - --- 221,229 ---- mutual = 0; #endif /* lint */ s_kvno = *ptr++; /* get server key version */ ! (void) strncpy(realm,ptr,REALM_SZ); /* And the realm of the issuing KDC */ ! realm[REALM_SZ-1] = '\0'; ! ptr += strlen(realm) + 1; /* skip the realm "hint" */ /* * If "fn" is NULL, key info should already be set; don't *************** *** 324,336 **** #define check_ptr() if ((ptr - (char *) req_id->dat) > req_id->length) return(RD_AP_MODIFIED); ptr = (char *) req_id->dat; ! (void) strcpy(r_aname,ptr); /* Authentication name */ ptr += strlen(r_aname)+1; check_ptr(); ! (void) strcpy(r_inst,ptr); /* Authentication instance */ ptr += strlen(r_inst)+1; check_ptr(); ! (void) strcpy(r_realm,ptr); /* Authentication name */ ptr += strlen(r_realm)+1; check_ptr(); memcpy((char *)&ad->checksum, ptr, 4); /* Checksum */ - - --- 327,342 ---- #define check_ptr() if ((ptr - (char *) req_id->dat) > req_id->length) return(RD_AP_MODIFIED); ptr = (char *) req_id->dat; ! (void) strncpy(r_aname,ptr,ANAME_SZ); /* Authentication name */ ! r_aname[ANAME_SZ-1] = '\0'; ptr += strlen(r_aname)+1; check_ptr(); ! (void) strncpy(r_inst,ptr,INST_SZ); /* Authentication instance */ ! r_inst[INST_SZ-1] = '\0'; ptr += strlen(r_inst)+1; check_ptr(); ! (void) strncpy(r_realm,ptr,REALM_SZ); /* Authentication name */ ! r_realm[REALM_SZ-1] = '\0'; ptr += strlen(r_realm)+1; check_ptr(); memcpy((char *)&ad->checksum, ptr, 4); /* Checksum */ Index: lib/krb5/krb/conv_princ.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb5/krb/conv_princ.c,v retrieving revision 1.23.2.2 diff -c -r1.23.2.2 conv_princ.c *** conv_princ.c 1999/10/12 23:16:58 1.23.2.2 - - --- conv_princ.c 2000/04/29 03:00:55 *************** *** 234,240 **** if (retval == 0 && full_name && full_name[0]) { instance = full_name[0]; } else { ! strcpy(buf, instance); retval = krb5_get_realm_domain(context, realm, &domain); if (retval) return retval; - - --- 234,241 ---- if (retval == 0 && full_name && full_name[0]) { instance = full_name[0]; } else { ! strncpy(buf, instance, sizeof(buf)); ! buf[sizeof(buf) - 1] = '\0'; retval = krb5_get_realm_domain(context, realm, &domain); if (retval) return retval; *************** *** 242,249 **** for (cp = domain; *cp; cp++) if (isupper(*cp)) *cp = tolower(*cp); ! strcat(buf, "."); ! strcat(buf, domain); krb5_xfree(domain); } instance = buf; - - --- 243,250 ---- for (cp = domain; *cp; cp++) if (isupper(*cp)) *cp = tolower(*cp); ! strncat(buf, ".", sizeof(buf) - 1 - strlen(buf)); ! strncat(buf, domain, sizeof(buf) - 1 - strlen(buf)); krb5_xfree(domain); } instance = buf; Index: lib/krb5/os/kuserok.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb5/os/kuserok.c,v retrieving revision 5.20.4.2 diff -c -r5.20.4.2 kuserok.c *** kuserok.c 1999/09/23 00:50:45 5.20.4.2 - - --- kuserok.c 2000/04/29 03:00:55 *************** *** 80,87 **** if ((pwd = getpwnam(luser)) == NULL) { return(FALSE); } ! (void) strcpy(pbuf, pwd->pw_dir); ! (void) strcat(pbuf, "/.k5login"); if (access(pbuf, F_OK)) { /* not accessible */ /* - - --- 80,88 ---- if ((pwd = getpwnam(luser)) == NULL) { return(FALSE); } ! (void) strncpy(pbuf, pwd->pw_dir, sizeof(pbuf) - 1); ! pbuf[sizeof(pbuf) - 1] = '\0'; ! (void) strncat(pbuf, "/.k5login", sizeof(pbuf) - 1 - strlen(pbuf)); if (access(pbuf, F_OK)) { /* not accessible */ /* Index: lib/krb5/posix/syslog.c =================================================================== RCS file: /cvs/krbdev/krb5/src/lib/krb5/posix/syslog.c,v retrieving revision 5.8 diff -c -r5.8 syslog.c *** syslog.c 1998/07/17 20:39:43 5.8 - - --- syslog.c 2000/04/29 03:00:55 *************** *** 115,121 **** (void)sprintf(tbuf, "<%d>%.15s ", pri, ctime(&now) + 4); for (p = tbuf; *p; ++p); if (LogTag) { ! (void)strcpy(p, LogTag); for (; *p; ++p); } if (LogStat & LOG_PID) { - - --- 115,121 ---- (void)sprintf(tbuf, "<%d>%.15s ", pri, ctime(&now) + 4); for (p = tbuf; *p; ++p); if (LogTag) { ! (void)strncpy(p, LogTag, sizeof(tbuf) - 1 - (p - tbuf)); for (; *p; ++p); } if (LogStat & LOG_PID) { *************** *** 146,151 **** - - --- 146,156 ---- } (void)vsprintf(p, fmt_cpy, ap); + /* Bounds checking?? If a system doesn't have syslog, we + probably can't rely on it having vsnprintf either. Try not + to let a buffer overrun be exploited. */ + if (strlen (tbuf) >= sizeof (tbuf)) + abort (); /* output the message to the local logger */ if (send(LogFile, tbuf, cnt = strlen(tbuf), 0) >= 0 || *************** *** 169,175 **** if ((fd = open(CONSOLE, O_WRONLY, 0)) < 0) return; (void)alarm((u_int)0); ! (void)strcat(tbuf, "\r"); p = strchr(tbuf, '>') + 1; (void)write(fd, p, cnt + 1 - (p - tbuf)); (void)close(fd); - - --- 174,181 ---- if ((fd = open(CONSOLE, O_WRONLY, 0)) < 0) return; (void)alarm((u_int)0); ! tbuf[sizeof(tbuf) - 1] = '\0'; ! (void)strncat(tbuf, "\r", sizeof(tbuf) - 1 - strlen(tbuf)); p = strchr(tbuf, '>') + 1; (void)write(fd, p, cnt + 1 - (p - tbuf)); (void)close(fd); ACKNOWLEDGEMENTS: Thanks to Jim Paris <jim(a)jtan.com> (MIT class of 2003) for pointing out the krb_rd_req() vulnerability. Thanks to Nalin Dahyabhai of Redhat for pointing out some other buffer overruns and coming up with patches. - -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Comment: Processed by Mailcrypt 3.5b6, an Emacs/PGP interface Charset: noconv iQCVAwUBOSGcyMUtR20Nv5BtAQEMxgP9EE0BPsV74PIzQsuf0YXK41x4eeMzAwJ0 IDn/PyfqvdAu6pdhf9CaQSMEDCdfdnsP/TYe7Kj3dmI3ijJUsSbKiovBF1pUTWat tcQebpaL/z9AfVvROXGhINifXyHv2FlQ6sLbfC+1N4XFafDIs2j1EaPsp+Mk83mY uy8Ud3DQ6FY= =bHIH - -----END PGP SIGNATURE----- ------- End of Forwarded Message --Steve Bellovin

1 0

Re: IGPs and services?
by R.P. Aditya 17 May '00

17 May '00

In message <Pine.LNX.4.21.0005171452440.14436-100000(a)harmony.hudes.org>, dhudes(a)hudes.org writes: > Why not just inject the /32 in the router as a static route? > Keep OSPF overhead off the UNIX system and keep the application server out > of my IGP. Perfectly valid, except that DNS servers are usually attached by some sort of broadcast media via a switch to the router that has the static route, and if the DNS server stops responding, the static route doesn't "go away". I have used a cross-over cable from the DNS server to a dedicated ethernet interface on the router to solve this, however, it didn't fly as it came down to not wanting to have a single underutilized interface per DNS server...Cisco ethernet ports aren't cheap (fade to other thread about using Unix/PC boxes with cheap 4 port ethernet cards as routers)... Adi > On Tue, 16 May 2000, R.P. Aditya wrote: > > > > > The scenario the original poster described, wanting to have regionally based > > caching DNS servers for clients is a fine example of when in fact it is a good > > and plausible idea to run a routing protocol on a Unix machine. > > > > I've run ospf on the DNS servers to redistribute the same /32 loopback address > > at different pops on local machines. I know of at least one large provider who > > uses BGP to achieve the same thing...It works well because bind tends to be > > far more stable and robust than the routing protocol program. > > > > I would recommend BGP since you can filter everything to the (DNS) server and > > only announce the /32... > > > > I can imagine doing the same thing for smtp relay boxes, never tried it > > though. > > > > Adi > > > > In message <00e201bfbfc8$3b7597f0$eaaf6cc7@PEREGRIN>, "Roeland M.J. Meyer" writes: > > > > > > > ww(a)shadowfax.styx.org: Tuesday, May 16, 2000 10:34 PM > > > > > > > What is the general feeling about running routing protocols on > > > > web/dns/mail servers? > >

1 0

Re: CIDR Report
by Vadim Antonov 17 May '00

17 May '00

Valdis.Kletnieks(a)vt.edu wrote: > Sure, *any* good router vendor can build a router that can handle 100 million > routing table entries. Not. The empirical evidence suggests that aggregate flap rate is proportional to the number of prefixes in RIB. Now, when people talk about route update processing they tend to forget that IGP and routing table updates are easy; matching prefixes against ruting policy filters is not. I would say that a computing device capable of doing today's border routing policies at 1M updates per second is well into the realm of science fiction. > The questions are (a) can they do it for a pricetag > of under $2M, and (b) how many will they sell? The question of profitability of cheese mining on the Moon is irrelevant, because Moon isn't made from cheese. --vadim

3 3

Re: Bell Atlantic DACS failure 280 T3s
by Steven Schnell 17 May '00

17 May '00

A DCS has the capability to loop any DS-0, DS-1 or DS-3 signal onto itself or any other signal in the digital crossconnect system's electronic matrix. Whether or not the DCS has a test head (e.g., Hekemian or other) outboard or integrated in the DCS is a choice of the carrier. At the command of a DCS admin person a digital signal can be crossconnected to the test head's test port on the DCS, where it can be remotely tested for continuity, signal impairments or other operating parameters. DDS and/or DS-n signals can be generated by the test head and the circuit's response compared against a "signal mask" stored in the test head. Whether or not the circuit meets the carrier's standards for Bit Error Rate (BER) and other operating parameters can be quickly ascertained. I can't believe that Bell Atlantic does not have this capability within their network. Steven NetEffect Corporation ------Original Message------ From: Travis Pugh <tpugh(a)shore.net> To: Sean Donelan <sean(a)donelan.com> Sent: May 16, 2000 8:54:22 PM GMT Subject: Re: Bell Atlantic DACS failure 280 T3s I'm curious about BA DACS. I don't know if this is standard, but they are the only telco who has also told me "we put a loop up on the DACS, but sometimes it doesn't work ... so don't assume that it is a valid test." And I have witnessed that same happening. If you can't create a simple maintenance loop on BA's DACS, their choice of vendors does seem questionable. -travis On 16 May 2000, Sean Donelan wrote: > > Bell Atlantic lost another DACS yesterday taking out 280 T3s for 3-1/2 hours > in the northeastern corridor and New York City. > > I'm not a transmission person, but what is the problem with DACS? Why > do these "highly reliable" systems fail in such catastrophic ways? > > > >

1 0

Re: The %^&# did it!
by Jim Mercer 17 May '00

17 May '00

On Tue, May 16, 2000 at 01:29:05PM -0700, Eric A. Hall wrote: > > i don't use ICQ, but i sorta understood it to be half between biff and > > irc. > > > > how is ICQ considered an "online telephone service"? > > It has two modes. In simple mode it is as you state. In advanced mode it > offers a voice chat function. ah, that would explain it. -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

5 4