- NANOG - lists.nanog.org

CERT Vendor-Initiated Bulletin VB-95:04 (Wietse Venema)
by CERT Bulletin 14 Jun '95

14 Jun '95

CERT Vendor-Initiated Bulletin VB-95:04 June 14, 1995 Topic: Logdaemon/FreeBSD vulnerability in S/Key Source: Wietse Venema (wietse(a)wzv.win.tue.nl) To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Wietse Venema, who urges you to act on this information as soon as possible. Please contact Wietse Venema if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ A vulnerability exists in my own S/Key software enhancements. Since these enhancements are in wide-spread use, a public announcement is appropriate. The vulnerability affects the following products: FreeBSD version 1.1.5.1 FreeBSD version 2.0 logdaemon versions before 4.9 I recommend that users of this software follow the instructions given below in section III. ----------------------------------------------------------------------------- I. Description An obscure oversight was found in software that I derived from the S/Key software from Bellcore (Bell Communications Research). Analysis revealed that my oversight introduces a vulnerability. Note: the vulnerability is not present in the original S/Key software from Bellcore. II. Impact Unauthorized users can gain privileges of other users, possibly including root. The vulnerability can be exploited only by users with a valid account. It cannot be exploited by arbitrary remote users. The vulnerability can affect all FreeBSD 1.1.5.1 and FreeBSD 2.0 implementations and all Logdaemon versions before 4.9. The problem exists only when S/Key logins are supported (which is the default for FreeBSD). Sites with S/Key logins disabled are not vulnerable. III. Solution Logdaemon users: ================ Upgrade to version 4.9 URL ftp://ftp.win.tue.nl/pub/security/logdaemon-4.9.tar.gz. MD5 checksum 3d01ecc63f621f962a0965f13fe57ca6 To plug the hole, build and install the ftpd, rexecd and login programs. If you installed the keysu and skeysh commands, these need to be replaced too. FreeBSD 1.1.5.1 and FreeBSD 2.0 users: ====================================== Retrieve the corrected files that match the system you are running: URL ftp://ftp.cdrom.com/pub/FreeBSD/CERT/libskey-1.1.5.1.tgz MD5 checksum bf3a8e8e10d63da9de550b0332107302 URL ftp://ftp.cdrom.com/pub/FreeBSD/CERT/libskey-2.0.tgz MD5 checksum d58a17f4216c3ee9b9831dbfcff93d29 Unpack the tar archive and follow the instructions in the README file. FreeBSD current users: ====================== Update your /usr/src/lib/libskey sources and rebuild and install libskey (both shared and non-shared versions). The vulnerability has been fixed with FreeBSD 2.0.5. ----------------------------------------------------------------------------- S/KEY is a trademark of Bellcore (Bell Communications Research). Wietse Venema appreciates helpful assistance with the resolution of this vulnerability from CERT/CC; Rodney W. Grimes, FreeBSD Core Team Member; Guido van Rooij, Philips Communication and Processing Services; Walter Belgers. =========================FORWARDED TEXT ENDS HERE============================= CERT bulletins, CERT advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University.

1 0

RADB cleanup - route objects with obsolete peers in advisory lists
by Brian Renaud 12 Jun '95

12 Jun '95

Some of the route objects in the RADB registry contain advisory lists which specify non-existant peers. (Many of these entries became incorrect when the NSFNET routers were shut down at the end of April.) We have produced a list of these route objects, which you can obtain via the web page: http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/problems.html or, for those that prefer just ftp: ftp.ra.net:routing.arbiter/radb/problems/*.badav ftp.ra.net:routing.arbiter/radb/problems/*.badav.gz We would prefer not to modify your data. However, these entries need to be revised. On June 23, we will modify the advisory lines of any route objects in the RADB with references to non-existant peers. (The references to the peers will be removed and the preferences renumbered.) Please contact us at db-admin(a)ra.net if you have any questions about this. -Brian

1 0

RADB cleanup - route objects with no origin AS entries
by Brian Renaud 09 Jun '95

09 Jun '95

Many of the entries in the RADB were translated from entries present in the NSFNET PRDB. Some of the PRDB entries contained no information about Origin AS (Home AS), which is required for the RIPE/RADB syntax. When possible, therefore, information about the Origin AS was added to these PRDB entries when they were converted to the RADB system. However, in some cases no information could be found about the AS "owner," and these entries were converted to RADB Route objects without the required 'origin:' attribute. As we discussed at the NANOG conference in May, these objects will be removed from the RADB. This will be done on Wednesday, June 14. A copy of the 2030 route objects which will be removed from the registry has been put into a 600K file at: ftp://ftp.ra.net/routing.arbiter/radb/problems/radb.noorigin A compressed copy is available at: ftp://ftp.ra.net/routing.arbiter/radb/problems/radb.noorigin.gz If you have any questions regarding this, please send them to DB-admin(a)ra.net -Brian

1 0

subscribe
by Abir Hnidi 09 Jun '95

09 Jun '95

subscribe ahnidi(a)ascend.com

1 0

subscribe
by zhouws＠ns.bta.net.cn 09 Jun '95

09 Jun '95

subscribe zhouws(a)ns.bta.net.cn

1 0

AS690 use of multiple routing registries
by Steve Heimlich 06 Jun '95

06 Jun '95

Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve

2 2

nanog notes for May 1995 meeting status
by sob＠academ.com 04 Jun '95

04 Jun '95

All the notes I took are now on line and available. I have not plugged in the speakers slides yet. That is next. Let me know if you find I have omitted something important in my notes that was not caputured on the slides. Let me know if I have something wrong. Thanks -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

more on nanog notes
by sob＠academ.com 04 Jun '95

04 Jun '95

The notes on Bill's talk that he sent to the list are now html-ized on the notes page at http://www.academ.com/nanog/may1995/index.html -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

NANOG notes
by sob＠academ.com 02 Jun '95

02 Jun '95

The agenda page with all the mailto's is up at the URL: http://www.academ.com/nanog/may1995 More to come!

1 0

Re: AS690 use of multiple routing registries
by Vadim Antonov 27 May '95

27 May '95

How about just doing like all other ISPs do? I.e. do policy at as-path level w/o the benefit of RADB. You don't need any new software to do that, and can do that right tomorrow. As it is now the ANS's policy to use RADB data to filter incoming routing updates generates about 60% of our trouble tickets, which is particularly aggravated by the fact that in most cases the resolution is completely outside of our control (like in case of AS 1800). IMO RADB already created more troubles than it will ever help to fix. I see no particluar reason for Sprint to spend any resources on keeping ANS's exterior routing sane. So do not expect "advisory: AS690" from us. Of course, (as ICM _has_ AUP) we can always start demanding NACRs from ANS. Just to make people who make decisions there to wake up. --vadim To: nanog(a)merit.edu Subject: AS690 use of multiple routing registries Date: Fri, 26 May 1995 16:44:47 -0400 From: Steve Heimlich <heimlich(a)ans.net> Status: R Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve

1 0