- Test - lists.nanog.org

CERT Vendor-Initiated Bulletin VB-95:07 - lsof
by CERT Bulletin 28 Sep '95

28 Sep '95

====================================================================== CERT Vendor-Initiated Bulletin VB-95:07 September 28, 1995 Topic: Directory and file vulnerability from lsof 3.18 through 3.43 Source: Vic Abell (abe(a)cc.purdue.edu) To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Vic Abell, who urges you to act on this information as soon as possible. Please contact Vic Abell if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ It may be possible to write lsof's private device cache file to system locations that are normally inaccessible to the lsof user, depending on the UNIX dialect where lsof is installed and how that dialect grants permission to access kernel memory information. The vulnerability affects lsof revisions 3.18 through 3.43, installed on these UNIX dialects: AIX 3.2.4, 3.2.5, 4.1, the IBM RISC/System 6000 4.1.1, and 4.1.2 EP/IX 2.1.1 the CDC 4680 FreeBSD 1.1.5.1, 2.0, and Intel-based systems 2.0.5 HP-UX 8.x, 9.x, and 10 HP systems (some combinations) IRIX 4.0.5H, 5.2, 5.3, SGI systems 6.0, and 6.1 Linux through 1.3.0 Intel-based systems Motorola V/88 R32V3, M88K systems R40V4.[123] NetBSD 1.0 and 1.0A Intel and SPARC-based systems NEXTSTEP 2.1 and 3.[0123] all NEXTSTEP architectures OSF/1 1.3, 2.0, 3.0, and the DEC Alpha 3.2 RISC/os 4.52 MIPS R2000-based systems SCO OpenDesktop or Intel-based systems OpenServer 1.1, 3.0, and 5.0 Sequent Dynix 3.0.12 the Sequent Symmetry Sequent PTX 2.1.[156] and Sequent systems 4.0.[23] Solaris 2.[1234] and 2.5 Sun 4 and i86pc systems BETA SunOS 4.1.[1234] Sun 3 and 4 Ultrix 2.2, 4.2, 4.3, DEC RISC and VAX and 4.4 I recommend that users of the affected revisions of lsof on these dialects install lsof revision 3.44, 3.45 or later. Section III describes its location and some appropriate installation considerations. ----------------------------------------------------------------------------- I. Description A private device cache file feature was introduced at lsof revision 3.18 to speed up subsequent calls to lsof by reducing the need for a full scan of the nodes in /dev (or /devices). Accompanying the feature was an option (-D) that allowed the lsof user to specify where the device cache file was to be recorded. Since lsof normally runs with effective group ID permission set to the group that can read kernel memory devices, the -D option might allow lsof to write its device cache file to a location not normally accessible to the real user or group owning the lsof process. The locations where the lsof device cache file might be inappropriately recorded depend on the group that owns the memory devices and to what other files and directories the group has write permission. Here are two examples: 1) IBM's distribution of AIX sets group ownership of /dev/kmem and /etc to the "system" group and enables group write permission in /etc; and 2) Sun's Solaris distribution does the same thing, using the "sys" group. (Security conscious installations often create a new group -- e.g., "kmem" or "mem" -- that owns no files and is used solely for enabling read access to kernel memory devices.) A fix for this group ID vulnerability may be found in lsof revisions 3.44, 3.45, and above. A more serious vulnerability exists when lsof must run setuid to the root user and also has device cache file support. This happens for the lsof implementation that runs under Motorola's V/88 UNIX dialects R40V4.1, R40V4.2, and R40V4.3. This gives the lsof user an unlimited choice of places to record the device cache file. A partial fix for this vulnerability was introduced in lsof revision 3.43. The complete fix may be found in lsof revisions 3.44, 3.45, and above. II. Impact Unauthorized users may be able to write the lsof device cache file to normally-restricted locations, possibly in place of important system files. The vulnerability can be exploited only by users with a valid account. It cannot be exploited by arbitrary remote users. The vulnerability affects all lsof revisions 3.18 through 3.43 on UNIX dialects where device cache file support has been implemented. III. Solution Retrieve lsof revision 3.44, 3.45, or later and install it. Compressed tar archive: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/lsof.tar.Z Gzip'd tar archive: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/lsof.tar.gz Lsof 3.44 eliminates the vulnerability for all relevant UNIX dialects. However, its overly zealous restrictions for Solaris and SunOS and are relaxed in revision 3.45. Both tar archives are wrappers that contain authentication information (MD5 checksums and PGP certificates) and a tar archive of the lsof sources. 1. Retrieve the wrapper archive, extract its three files -- README.lsof_<revision>, lsof_<revision>.tar, and lsof_<revision>.tar.asc -- and verify its authentication information. (<revision> should be 3.44 or greater.) 2. Unpack the lsof source archive from lsof_<revision>.tar and read its documentation files. Pay particular attention to the 00DCACHE file that describes options for specifying the location of the device cache, and the security section in the 00README file. 3. Having selected the lsof options appropriate to the UNIX dialect where you want to install it, run the Configure script, use make to build lsof, and install the resulting lsof executable. ----------------------------------------------------------------------------- Vic Abell appreciates the advice and comments provided by members of the bugtraq mailing list that led him to realize this vulnerability existed. He thanks Katherine T. Fithen and Linda Hutz Pesante of the CERT Coordination Center for their help in preparing this bulletin. =========================FORWARDED TEXT ENDS HERE============================= CERT publications, 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

Operational declaration of route servers at AADS and Washington-DC NAPs
by Jake Khuon 28 Sep '95

28 Sep '95

The Routing Arbiter Service is pleased to announce it is fully in production at both the AADS and Washington-DC (MAE-East) NAPs. Two route servers are installed at each NAP to provide redundancy, and the route servers are reconfigured every 4 hours. The route server configurations are based on the routing policy information stored in the Internet Routing Registry. The IRR contains the full set of data from five databases: Routing Arbiter Database, RIPE Routing Registry, internetMCI Routing Registry, CA*net Routing Registry, and ANSnet Database. For more information about the RA Service, please refer to: http://www.ra.net/routing.arbiter/RA/ To use the RA Service at the AADS and Washington-DC NAPs, send mail to: ra-peer(a)ra.net -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (313) 763-4907 Fax: (313) 747-3185 / |/ |[_|\| | Incorporated | +====[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105 ]====*/

1 0

Re: Peering in the LA region?!?
by Peter Kline 28 Sep '95

28 Sep '95

Hello All, AGIS would be happy to/interested in exchanging customer routes in LA. We're in the SMDS cloud. Further, I think that in less than 60 seconds I could convince my management to purchase a switching hub for our space with WilTel on the 14th Floor of the 1 Wilshire Building. Anyone within/nearby that space (I remember seeing BBN/Planet and UUNet for instance) would be welcome to drag a cat5 connection to that hub for the exchange of customer routes with AGIS and other attachees. I see no reason to charge anything for the connection. If there's enough interest, mebbe bmanning could provide/administer an ep.net class C. Peter At 09:21 AM 9/26/95 -0700, Pushpendra Mohta wrote: > >CERFnet has a POP in One Wilshire with 2 T3s, soon to be 4. > >CERFnet and Los Nettos/CSUnet have a private peering arrangement at two >locations. Other than that, I am not aware of large peering >arrangements in LA, but would welcome such a move. > > >--pushpendra > >Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 >Director, CERFnet http://www.cerf.net +1 800 876 2373 > >Marcos Della writes: >> >> Just curious, but after looking around at several sites in LA, I was curious >> if ANYONE was actually doing any significant peering in the LA basin? >> Currently >> we are looking for multiple interconnects down there in the 10mbps/T3 range, >> however we can't find anyone... >> >> We currently have a little >1000sq ft in the One Wilshire building. Is >> there anyone else in that building? *SIGH* I was meaning to ask this while >> I was at nanog, but other events caused me to forget to ask... >> >> Marcos >> >> -- >> >> ''' >> (o o) >> --------------------------oOO--(_)--OOo-------------------------- >> Marcos R. Della Email: mdella(a)InterNex.Net >> Director, Network Engineering InterNex Information Services >> Phone: 408/496-5466 http://www.internex.net/~mdella >> >> > > > ___________________________________________________________________ Peter Kline | pots 313-730-1130 AGIS - Internet Backbone Services | Pager 800-823-7118 22015 West Outer Drive | "Sister, I don't mind shootin' Dearborn, MI 48124 | 'em for ya', but I sure as hell peter(a)agis.net | won't sweat over them" - Clint =================================================================== AGIS - Net99 | pots 602-249-0957 4810 N. Black Canyon Road | fax 602-249-1161 Phoenix, AZ 85017 | peter(a)net99.net

1 0

Re: 204.82.160.0/22 invisible
by Kai 27 Sep '95

27 Sep '95

Argh ! and I only did this typo ONCE over the last 10 emails. ultimate clarification: BelCom has: 204.97.218.0/219.0 (old, Sprint-owned, aggregated) 206.82.160.0/22 <- this was the point of discussion. Sorry for the noise this has caused by now. bye,Kai >> OK. What about 206.82.160.0/22? >> >> Thanks, Elliot. >> >> <markd> >> >oh hell, i should've seen this coming.. check this out: >ealbytraceroute belcom.net >traceroute to belcom.net (204.97.218.2), 30 hops max, 40 byte packets > 1 sl-hrn-1-E5 (199.0.55.1) 3 ms 2 ms 2 ms > 2 sl-dc-1-S3-T1 (144.228.0.225) 11 ms 9 ms 6 ms > 3 sl-dc-6-F0/0 (144.228.20.6) 8 ms 7 ms 5 ms > 4 sl-pen-1-H2/0-T3 (144.228.10.34) 8 ms 9 ms 8 ms > 5 sl-pen-4-F0/0 (144.228.60.4) 9 ms 32 ms 9 ms > 6 sl-computel-1-S0-T1 (144.228.64.74) 15 ms 15 ms 15 ms > 7 gate.belcom.net (204.97.218.1) 19 ms 18 ms 19 ms > 8 belcom.net (204.97.218.2) 29 ms 19 ms 21 ms >ealby >204.etc, right? >ealbywhois 206.82.160 >BelCom, Inc. (NETBLK-BELCOM-NET) > 515 Madison Ave Suite 2100 > New York, NY 10022 > Netname: BELCOM-NET > Netblock: 206.82.160.0 - 206.82.163.0 > Coordinator: > Schlichting, Kai H. (KHS) kai(a)BELCOM.NET kai(a)COMPUTEL.COM > (212) 705-9500 > Domain System inverse mapping provided by: > NS.BELCOM.NET 204.97.218.2 > CNS.COMPUTEL.COM 204.97.91.2 > Record last updated on 12-Sep-95. >The InterNIC Registration Services Host contains ONLY Internet Information >(Networks, ASN's, Domains, and POC's). >Please use the whois server at nic.ddn.mil for MILNET Information. >ealby >belcom, you need to straighten out your records at the internic asap. >someone typo'd your class c's when you were swip'd from computel. also, >why is the 204.82 block registered at the nic to 'nd dept of edu'? >is that who originally allocated computel's class c's? >- elliot/sprint >ealbywhois 204.82.160 >NB Department of Education (NETBLK-NB-SCHOOLS) > P.O. Box 6000 > Fredericton, NB > E3B 5H1 > CA > Netname: nbed-nb-ca > Netblock: 204.81.0.0 - 204.82.255.0 > Coordinator: > Lee, Jean (JL154) jeanl(a)GOV.NB.CA > +1 (506) 453-7153 > Domain System inverse mapping provided by: > ALPHA.NBED.NB.CA 204.81.0.10 > OMEGA.NBED.NB.CA 204.81.0.99 > Record last updated on 27-Dec-94. >The InterNIC Registration Services Host contains ONLY Internet Information >(Networks, ASN's, Domains, and POC's). >Please use the whois server at nic.ddn.mil for MILNET Information. >ealby '~e

1 0

Re: 204.82.160.0/22 invisible
by asp＠uunet.uu.net 27 Sep '95

27 Sep '95

Poking at this futher, Sprint is announcing 204.82.160/22; Digex is behind ANS; this route is not in the RADB; and since ANS insists on all routes being in the RADB, they are not accepting it, so Digex is not seeing it. Fix: Either get ANS to not insist on all routes being in the RADB or submit an update to the RADB & wait for ANS to regenerate their configs. Kai: Please don't widly accuse folks before poking into the facts. --asp(a)uunet.uu.net (Andrew Partan)

4 6

Re: 204.82.160.0/22 invisible
by Elliot Alby 27 Sep '95

27 Sep '95

> OK. What about 206.82.160.0/22? > > Thanks, Elliot. > > <markd> > oh hell, i should've seen this coming.. check this out: ealbytraceroute belcom.net traceroute to belcom.net (204.97.218.2), 30 hops max, 40 byte packets 1 sl-hrn-1-E5 (199.0.55.1) 3 ms 2 ms 2 ms 2 sl-dc-1-S3-T1 (144.228.0.225) 11 ms 9 ms 6 ms 3 sl-dc-6-F0/0 (144.228.20.6) 8 ms 7 ms 5 ms 4 sl-pen-1-H2/0-T3 (144.228.10.34) 8 ms 9 ms 8 ms 5 sl-pen-4-F0/0 (144.228.60.4) 9 ms 32 ms 9 ms 6 sl-computel-1-S0-T1 (144.228.64.74) 15 ms 15 ms 15 ms 7 gate.belcom.net (204.97.218.1) 19 ms 18 ms 19 ms 8 belcom.net (204.97.218.2) 29 ms 19 ms 21 ms ealby 204.etc, right? ealbywhois 206.82.160 BelCom, Inc. (NETBLK-BELCOM-NET) 515 Madison Ave Suite 2100 New York, NY 10022 Netname: BELCOM-NET Netblock: 206.82.160.0 - 206.82.163.0 Coordinator: Schlichting, Kai H. (KHS) kai(a)BELCOM.NET kai(a)COMPUTEL.COM (212) 705-9500 Domain System inverse mapping provided by: NS.BELCOM.NET 204.97.218.2 CNS.COMPUTEL.COM 204.97.91.2 Record last updated on 12-Sep-95. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. ealby belcom, you need to straighten out your records at the internic asap. someone typo'd your class c's when you were swip'd from computel. also, why is the 204.82 block registered at the nic to 'nd dept of edu'? is that who originally allocated computel's class c's? - elliot/sprint ealbywhois 204.82.160 NB Department of Education (NETBLK-NB-SCHOOLS) P.O. Box 6000 Fredericton, NB E3B 5H1 CA Netname: nbed-nb-ca Netblock: 204.81.0.0 - 204.82.255.0 Coordinator: Lee, Jean (JL154) jeanl(a)GOV.NB.CA +1 (506) 453-7153 Domain System inverse mapping provided by: ALPHA.NBED.NB.CA 204.81.0.10 OMEGA.NBED.NB.CA 204.81.0.99 Record last updated on 27-Dec-94. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. ealby

1 0

Treno Server is available...
by Jamshid Mahdavi 27 Sep '95

27 Sep '95

As we discussed at the NANOG and IPPM meetings, Matt and I have put together a Treno Server which will run Treno from a well connected (T3 attached) machine. The URL is http://www.psc.edu/~pscnoc/treno.html --Jamshid and Matt

1 0

Re: Request for Comments on a topological address block for N. Calif.
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: asp(a)uunet.uu.net (Andrew Partan) Lets assume that everyone on the Boston area has a geographic address and that AlterNet and some other ISP (SmallGuy) have some customers in this area, and that AlterNet and SmallGuy peer at some Boston area exchange point. ... Now if I peer with some other ISP in some other area (say someone in San Francisco) ... I have now suddenly offered transit for SmallGuy between San Francisco and Boston. Well, there is a "fix", but this whole topic of traffic is a major can of worms. I assume the basic concept is similar to the existing US 'phone system, in that each provider should do the long-haul for their own customers only (unless some suitable peering arrangement is in place), to prevent "dumping" the long-haul load (i.e. provider P gets the traffic, immediately hands it to Q, who has the carry the bits across the globe...)? (This, of course, does lead to asmmetric routes. I thought I recalled a message from Curtis that talked about that, as part of a longer discussion of this whole topic, but can't find it now....) One fix to do this is for a provider not to accept traffic from another provider unless that traffic is destined to an "appropriate" customer (exact definition varies) of the first provider (or a customer of a peer provider of the first provider, one which has a transit agreement with the first provider). The definition of "appropriate" is tricky; does this mean any customer (which still leaves you vulnerable to "dumping" of long-haul load to customers of the dumpee), or just "local" customers? If the latter, would you rather the customer not get the traffic at all (if the traffic source is attached to a provider which doesn't have an attachment to the destination's provider, near the destination - we'll call this source's provider a minimal-connect provider)? If not, how do you prevent "dumping"? In geographic addressing this means that you don't accept traffic for another metro from a provider unless you have a peering arrangement with them, otherwise you wind up doing the long-haul. This stops "dumping", true, but still leaves your customer not getting traffic from minimal-connect customer. You can do more or less the same thing in connecvity-based addressing, and you have the same cut-off-minimal-connect-guys/allow-long-haul-dumping choice... (Just out of interest, does anyone know how the phone companies did it? I.e. if I'm a new inter-lATA carrier, and I don't yet serve all LATA's, how does it work if I'm one of their customers and I try and call one of those LATA's?) If SmallGuy is not paying me for transit, then I am not going to do this. Ah, there's the rub! What you really want, it seems, is traffic settlements (since I don't think we can adopt/enforce a simplistic you-always-carry-your- customers-traffic-pretty-much-to-the-destination model, which would get rid of any need for settlements) but right now the Internet doesn't have them, for a whole host of good reasons. For one, let's go back to the case of two large providers, P and Q. Right now, P could "dump" its long-haul traffic on Q, knowing Q will give it back sooner or later (unless they each try to dump on the other, which will get them into a routign loop :-). However, what about customers of R, which isn't connected to P, but is to Q? The Internet currently assumes that traffic takes something close to the best path, so we assume that P->R traffic will in fact transit Q, without explicit arrangements between P and Q about it. So Q does have to accept traffic from P which is not to customers of P ("appropriate" or not). There's an interesting analogy here between traffic settlements and routing setllements; the Internet will work fine with no administrative overhead if everyone is reasonable. However, if people try and take advantage of the system, to a point where administrative controls are needed, the overhead of those controls will be substanial, to the point where the cure might be as bad as the disease. Hmm.... Noel

3 2

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: David Conrad <davidc(a)apnic.net> there will be a cost associated with requesting address space: US $10,000/year for Large ISPs ... US $2,500/year for Small ISPs ... >> The category is self-determined by the organization. Everyone's going to classify themselves as the smallest, then... Such an approach is perhaps not as clean as charging for IP address space directly, but it does seem to be a reasonable compromise given political and theological constraints. ... Note that you should stress charging for registration services as opposed to charing for address space. The latter is a political minefield that will simply muddy the waters. If you vary your charge based on the size of the organization, how do you justify that in terms of what it takes you in internal resources? Surely a registration of a small ISP takes as much time/etc as a large one? I understand your hesitancy about the "charging for addresses" issue, but trying to effectively charge for addresses based on something nebulous like a varying registration fee based on organization size just isn't going to pass the "quack" test. People will see right through it... Heck, I don't mind charging for addresses, they are a limited resource. Use the money to fund IETF work. Noel

3 2

CERT Summary CS-95:02
by CERT Advisory 26 Sep '95

26 Sep '95

--------------------------------------------------------------------------- CERT Summary CS-95:02 September 26, 1995 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. Starting with this summary, we will also list new or updated files that are available for anonymous FTP from ftp://info.cert.org Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries --------------------------------------------------------------------------- Recent Activity --------------- Since the July CERT Summary, we have seen these continuing trends in incidents reported to us: 1. Sendmail Attacks We receive several reports each week of attacks through sendmail, with intruders using a variety of techniques. Most of the attacks are aimed at gaining privileged access to the victim machine. To combat these threats, we encourage sites to take the appropriate steps outlined in the following: ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README A number of sites have reported some confusion on the need to continue using the sendmail restricted shell program (smrsh). You need to run the smrsh tool in conjunction with the most recently patched version of sendmail for your system. Information on the smrsh tool can be obtained from these places in ftp://info.cert.org/pub/ tools/sendmail/smrsh/ cert_advisories/CA-93:16.sendmail.vulnerability cert_advisories/CA-93:16a.sendmail.vulnerability.supplement cert_advisories/CA-93:16a.README cert_advisories/CA-95:11.sun.sendmail-oR.vul cert_advisories/CA-95:11.README The smrsh program can be obtained from ftp://info.cert.org/pub/tools/smrsh/ It is included in the sendmail 8.7 distribution. 2. Network Scanning Several incidents have recently been reported in which intruders scan a large address range using the Internet Security Scanner (ISS). As described in CERT advisory CA-93:14, this tool interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders have used the information gathered from these scans to compromise sites. We are aware of many systems that have suffered a root compromise as a result of information intruders obtained from ISS scans. You may wish to run ISS against your own site in accordance with your organization's policies and procedures. ISS is available from ftp://info.cert.org/pub/tools/iss/iss13.tar We encourage you to take relevant steps outlined in these documents: ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner ftp://info.cert.org/pub/cert_advisories/CA-93:14.README ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/packet_filtering 3. Exploitation of rlogin and rsh We have received some reports about the continued exploitation of a vulnerability in rlogin and rsh affecting IBM AIX 3 systems and Linux systems. This is not a new vulnerability, but it continues to exist. Sites have reported encountering some Linux distributions that contain this vulnerability. Information on this vulnerability and available solutions can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-94:09.bin.login.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-94:09.README 4. Packet Sniffers We continue to receive new incident reports daily about sniffers on compromised hosts. These sniffers, used to collect account names and passwords, are frequently installed using a kit. In some cases, the packet sniffer was found to have been running for months. Occasionally, sites had been explicitly warned of the possibility of such a compromise, but the sniffer activity continued because the site did not address the problem in the comprehensive manner that we suggest in our security documents. Further information on packet sniffers is available from ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README Information about detecting sniffers using cpm is in the CA-94:01.README file. What's New in the CERT FTP Archive ---------------------------------- We have made the following changes since June 1, 1995. * New Additions: ftp://info.cert.org/pub/ incident.reporting.form (the form you should fill out when reporting an incident to our staff) ftp://info.cert.org/pub/cert_advisories/ CA-95:08.sendmail.v.5.vulnerability CA-95:09.Solaris.ps.vul CA-95:10.ghostscript CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_bulletins/ VB-95:05.osf (OSF/DCE security hole) VB-95:06.cisco (vulnerability in Cisco's IOS software) ftp://info.cert.org/pub/tech_tips/ AUSCERT_checklist_1.0 (UNIX checklist developed by the Australian Emergency Response Team) * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-93:14.README (Internet Security Scanner) CA-94:01.README (network monitoring) CA-94:02.README (SunOS rpc mountd vulnerability) CA-94:05.README (md5) CA-94:11.README (majordomo) CA-95:01.README (IP spoofing and hijacked terminal connections) CA-95:02.README (binmail vulnerabilities) CA-95:05.README (sendmail - several vulnerabilities) CA-95:08.README (sendmail version 5 and IDA sendmail) CA-95:09.README (Solaris ps) CA-95:11.README (Sun sendmail -oR vulnerability) We have begun adding a note to advisory README files reminding readers to check with vendors for current checksum values. After we publish checksums in advisories and READMEs, files and checksums are sometimes updated at individual locations. * Other Changes: As we will no longer be keeping the lsof directory current, the directory and its files have been removed from our FTP site. The current version of lsof is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof --------------------------------------------------------------------------- How to Contact the CERT Coordination Center Email cert(a)cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request(a)cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details). Location of CERT PGP key ftp://info.cert.org/pub/CERT.PGP_key --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University.

1 0