- Test - lists.nanog.org

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

ISP/CO-LO Start-up...
by York, Tracy (CEI-Atlanta) 17 May '00

17 May '00

For a couple of years now, I've been lurking on this list and have learned some great things... and at times been very amused. Now its time to ask a few questions... My company is starting an ISP/CO-LO to provide services to some of their business units. These business units provide everything from e-mail to web services to their customers, public and private. We have already ordered 4 DS-3's (I know, small time) with tier one providers and plan on setting up BGP peering with each of them. We already have an ASN and IP addresses. What I would like to know, is if their are any good guidelines that we should follow in getting all this cranked up. I know some of you (if not all) have experienced various issues in starting up an ISP and I would like to draw on that knowledge to make sure we get it right the first time. I'm looking for information on everything from BGP to good business practices from the technical side. Please reply off list. Thanks -TY "Give beer to those who are perishing..." (Proverbs 31:6)

1 0

Re: Private ASN suppression
by Danny McPherson 16 May '00

16 May '00

Actually, RFC 2270 is only suggested to be used when sites are homed to a single provider. In this case, there won't be origin AS inconsistencies. I believe most implementors (some listed, some not) of this "remove-private-as" capability only intended for it to be used in configurations where the source of the route(s) is homed only to a single upstream AS. -danny > ...as well as rfc2260. > > to be more specific, we have to note that two different options > are considered there. if you use the first one (read rfc), > then you cannot use private asn until you're ok with > generating inconsistencies (and it seems from the previous > discussions of this topic that this becomes (illegal? -> > no answer...) practice for some smaller isps). > > with the second option of 2260, you can use private asn > since the more specific pa routes are always aggregated > (and you cannot use confederations, btw). > > after all, as was noted, remove-private-as on cisco can be > replaced by a simple route map, and the attribute manipulation > functionality should definitely exist on versalars... > -- > dima. > > > >

2 1