The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for November 1988 (686 messages, 404409 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/11.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 00:16:10 GMT
From:      net1.ucsd.edu!ple@ucsd.edu  (Paul Evans)
To:        tcp-ip@sri-nic.arpa
Subject:   VAX/VMS TCP/IP
I am interested in getting information regarding a university version of
TCP/IP for VAX/VMS machines.

Please reply directly.

Thanks.
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 02:30:32 GMT
From:      jtn@potomac.ads.com (John T. Nelson)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   GATED sources?


Could someone please direct me to the nearest GATED sources?  Specific
machine names from which I can anonymously FTP them over?  Please
reply by mail.




-- 

John T. Nelson			UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems	Internet:  jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401		(703) 243-1611

Shar and Enjoy!

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 02:38:30 GMT
From:      smiddy@SPAM.ISTC.SRI.COM (Richard Smith, smiddy@spam.istc.sri.com)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

People who want to know how it works should visit Milstone, N.J...(:-).
Smiddy

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 04:40:55 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  copyrights

Joel:

The technical requirement of filing is satisfied by the inclusion of the
copyright statement in the text.  It is not essential to hire an attorney
to perform the filing of a formal copyright.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 05:33:34 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: 4BSD TCP Ethernet Throughput

Regarding copyrighting your missives to avoid being misquoted by
the "press" (or anyone else), I think you are misguided.  In fact,
I think you are sadly mistaken (and "taken") by the copyright protection
you are seeking.  Just taking a sentence or two out of your "article"
is permissible.  And that is waht I think you are trying to avoid.

Heck,  if you speak out, others will quote you.  

Sigh,
Dan
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 06:48:28 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip
Subject:   What actually happens

Would appreciate if someone could briefly summarize the sequence of
outbound and inbound messages thru the interface to/fm ethernet for
ping, finger, ftp and telnet.  Where ping or finger ( and the tables,
hosts, etc .. ) just know host.do.main or 123.34.45.67 ( internet ) is
ARP the solution on private ethernets to findout host.do.main's ether?

Some simplified enlightenment would be well apreciated here.  I am trying
to troubleshoot an interface without knowing what to expect, event or time
wise.  Thanks .. /Ev/
-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
    efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 06:57:50 GMT
From:      daveb@gonzo.UUCP (Dave Brower)
To:        comp.protocols.tcp-ip
Subject:   back to ping, and icmp support

In my question of a week or so ago, I asked about running ping on a
machine that did not support access to the icmp layer.  This spawned
an interesting revisit to the swamp of "what is tcp/ip, really?".

The best answers I got said essentially use the udp echo instead of the
icmp echo, and that is what I'll do if I ever have the time to get back
to it.

Others asked me to name names of the horrible icmp-less vendor, which I
won't do for reasons having to do with my employment :-)  I just don't
see the point.  Here are some hints, though.

The problem is NOT that the machine does not support icmp.  It is that
it doesn't provide the programming access to let me, joe root, get at
the icmp layer.  That is, the /etc/protocols file has the icmp entry
commented out, and the icmp related headers in /usr/include/netinet
don't exist.  But there is clearly an icmpd daemon doing stuff, and  you
can ping it from another machine quite happily.  You just can't take
ping.c and make it work.

(I got the missing headers, made an executable, and put icmp back in the
protocols file.  Running ping provoked the "unsupported protocol" error.
*sigh*  This was when I sent the first question.)

Now, is what I describe a "valid" tcp/ip implementation?  I am
resignedly inclined to say "yes."

-dB

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 08:36:49 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: Copyrighted messages

Dave & Dan -

You're right.  I was stupid to put a copyright notice in a mail
message and I'm grateful to you guys for pointing it out.  I
realized I'd made a mistake shortly after sending the message
(as usual, just a few minutes too late).  I was composing that
message shortly after seeing an extract from an earlier message
in "the media".  It had been taken out of context and appeared
to say the opposite of what I had actually said.  The
surrounding text gave the impression that the quote was taken
from an interview (which, of course, it wasn't).  When I called
to complain about the misrepresentation, I was told that
attributing public statements to an "interview" was a standard
journalistic practise as was excerpting uncopyrighted statements
made in a public forum.  I guess the "uncopyrighted" stuck in my
mind.

So, my apologies to all & never again (I hope -- there's this
problem that the only time it's easy to write is when I'm
steamed -- If I wasn't distracted by some annoyance, I'd be
working on something new rather than writing about something
old.  I guess that's why the guidelines say "let it sit for a
day before sending".)

Thanks again for pointing out the problem.

 - Van

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 1988 17:03:17 EST
From:      James Tontonoz <tontonoz@EDN-UNIX.ARPA>
To:        pgg@gateway.miyre.orgt
Cc:        tcp-ip@sri-nic.arpa,tontonoz
Subject:   TCP/IP Test Suite
For your info, the DCEC of DCA has a DoD protocol test system working
on a Vax machine that allows protocol implementations of TCP/IP running on
native machines to be tested  against the DoD standards.  More details
can be had by contacting Mr. Martin Gross of DCEC at 703-437-2165 or
gross@edn-unix.dca.mil


-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 13:20:14 GMT
From:      keith@tarantula.spider.co.UK (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Telnet, Rlogin, and Terminal Servers



From the correspondence on this subject, people appear to prefer the average
Rlogin implementation over the average Telnet one because:

1) It passes terminal type
2) It bypasses the need for username/password to be entered
3) No newline etc processing is applied to data transferred
4) It has better out-of-band data handling
5) It has better flow-control handling
6) It has window-size negotiation

A full (as opposed to average) Telnet implementation can provide (1), (3),
(4), and (6), and the Telnet standard is sufficently general that extensions
to cover (2) and (5) are certainly possible. I still feel Telnet is the
protocol to go with - networking is about connecting heterogenous systems,
not just Unix ones, and achieving the goal of universal connectivity/
interoperability is never going to be accomplished with non-documented
standards.

The problem is that although Telnet defines a general functionality, most
implementations only provide a subset of this. Rlogin implements a
different subset of this functionality (It has no definition distinct
from the implementation). What is really wanted is an
implementation which provides a more general union of both these subsets.

I think the approach implementors should take therefore, is to provide both
Rlogin and Telnet, but concentrate on extending Telnet so it can meet all
peoples' needs. We need both in the meantime, not least because the whole
situation is very much "horses for courses". (The Telnet vs Rlogin arguments
strike me as very similar to those for NFS vs RFS.)

The discussion on this subject has been very useful, and I will make
sure it is input to the next phase of SpiderPort development.

Keith Mitchell

Spider Systems Ltd.		Spider Systems Inc.
65 Bonnington Road		12 New England Executive Park
Edinburgh, Scotland		Burlington, MA 01803
+44 31-554 9424			+1 (617) 270-3510

keith@spider.co.uk		keith%spider.co.uk@uunet.uu.net
keith@uk.co.spider		...!uunet!ukc!spider!keith

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1 Nov 88 21:52:24 PST
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        tcp-ip@sri-nic.ARPA
Subject:   Throughput limits on 82586: real or imaginary?
Drawing conclusions about the relative capabilities of the Intel 82586
vs. Lance based on two different controller subsystem designs doesn't
truly indicate the limits or lack thereof in these chips. 

Whether the 82586 is able to keep up with high traffic rates depends on the
surrounding hardware design (to minimize bus latency and wait states) and
on the driver software;  there is nothing inherent in the design of the
chip itself that prevents indefinite reception of back-to-back packets.  We
do it in the Sniffer (at least in highspeed mode), but it does require a
fair degree of heroics and a careful reading  of the latest bugsheet from
Intel;  some modes will generate "dma overrun" regardless of how fast the
memory bus is.

On the transmit side, though, we have not been able to generate
back-to-back packets;  the minimum interframe spacing that a single 82586
can manage seems to be about 40 usec instead of 9.6.  For us that's no big
deal since we're just trying to generate traffic to load the network, and
1500-byte packets separated by 40 usec is about 97% of maximum rate anyway.

It might be true (and this is speculation as to what might have resulted
in the measurements reported by Van) that designing a high performance
controller and writing the drivers is a tougher job for the 82586
than for the Lance. However this is something you do just once, so
there is no excuse not to squeeze the most out of the chip's capabilities.







-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 14:48:22 GMT
From:      jmvogtle@ICARUS.CNS.SYR.EDU (John M. Vogtle)
To:        comp.protocols.tcp-ip
Subject:   Anonymous ftp at brl


I've been trying to obtain copies of mdqs and Ping with the record
route option from vgr.brl.mil.  Yesterday I could connect but my
connection would drop because of network congestion.  Today when I
try, I get a message that anonymous ftp has been removed from vgr.

Does anyone know where I CAN get these utilities.  Thanks in advance.
  ___
 (   >      /                   John M. Vogtle
  \_/______/_  ____             Systems Programmer
 / /  (_) / /_/ / <_            Syracuse University
<_/				Internet:   jmvogtle@icarus.cns.syr.EDU
                                AT&T Net:   (315) 443-5772
"One planet is all you get."    Snail Net:  221 Machinery Hall
                                            Syracuse University
                                            Syracuse, New York 13244-1260

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 17:02:26 GMT
From:      wrl@FORD-COS2.ARPA (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   Copyrights

Joel,
On copyrights,
No, you do not have to register them with anyone that I know
of. By marking a paper or E-Mail message you sent as 'copyright',
only the creator or his agents can give permission to re-produce
or distribute the copyrighted material.

In theory, an E-Mail user can send a copyrighted e-mail to
the tcp-ip distribution list and have his copyright intact because 
the author knowingly sent it to a distribution list.

The copyright does though forbid any one who receives the message
from giving it or copying it. (Automatic distribution is ok as
long as it is part of the sending it the mailing list even if the
distribution is not done by SRI-NIC because we all know that this
list is far reaching). A receiver could not manually forward it though.

DISCLAMER: I'm not a lawyer but thats the way it was explained
to me.

P.S.	I agree with Dave Mills though, I don't think this forum
should be for copyrighted or registered materials.

Bill

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 18:36:33 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   previous discussions

All,

Seems like my comments on copyrights generated whole bunches of mail items
both public and private.   Like Van, I would like to appologize to anyone
inconvienced.  I also feel that this forum is not the place for sideline
discussions.  Instead of complaining about it though, I was actually trying
to politely terminate it by pointing out copyrighting wouldn't do what
they were discussing.

I suppose it is just better to either be rude about such topics or just
ignore them in the future.  Humor just doesn't seem to be the right approach...
seems like everyone reads something a little different into it.

Again, applogies to any who may be offended.
Joel

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 19:10:38 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Output Flushing Guidelines (long)

I appreciate your detailed description of output buffer flushing in
telnet.  I'd like to point out to other readers that your work
apparently did not involve any extensions to the protocols.  I feel it
necessary to make this comment because the last few days have been
filled with various proposals for inventing new mechanisms to do
something for which there is an existing one.  So we need to make it
clear to people that your posting is not another such proposal: it
describes correct implementation of the existing telnet sync
mechanism.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 20:11:44 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip
Subject:   Re: re NetBIOS/TCP (UDP)

I hope and doubt the readers of this group don't really need to be convinced
of the value of network file systems versus network file transfer and network
login, although a couple of the messages made it sound that way.  If the
argument is rather that NetBIOS in a DOS address space consumes an intolerable
amount of additional RAM, I suggest that in my experience (with Excelan and
UB stuff) is that it doesn't.

I think what is happening is that some people have a prejudice, somewhat
deserved, against NetBIOS, and that subverts all other rational thinking.
We do it, and I'm glad we do, because there are a lot of people out there on
IBM PC Networks, Token Rings, and other MS-Nets that want to share data, file
system space, and/or printers with Unix users, and we give them that
capability.  We also provide NFS, in case people would rather use that.
Why consciously segment network users from network resources?

-bc
-- 
Bill Crews                        bc@halley.UUCP
(512) 244-8350                    ..!rutgers!cs.utexas.edu!halley!bc

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 21:14:45 GMT
From:      torek@OKEEFFE.BERKELEY.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  4.3bsd imp going down crash?

Most likely you ran into the bug fixed below.  This (and others) are
fixed in the 4.3BSD-tahoe networking code, and probably in the upgrade
for 4.3BSD that is (was?) on ucbarpa.

Chris

*** if_imphost.c.7.3	Tue Nov  1 13:10:09 1988
--- if_imphost.c.7.4	Tue Nov  1 13:10:18 1988
***************
*** 10,14 ****
   * is provided ``as is'' without express or implied warranty.
   *
!  *	@(#)if_imphost.c	7.3 (Berkeley) 2/8/88
   */
  
--- 10,14 ----
   * is provided ``as is'' without express or implied warranty.
   *
!  *	@(#)if_imphost.c	7.4 (Berkeley) 2/8/88
   */
  
***************
*** 201,204 ****
--- 201,205 ----
  	register struct mbuf *m;
  	register struct host *hp, *lp;
+ 	struct imp_softc *sc;
  	struct hmbuf *hm;
  	int s = splimp(), unit, any;
***************
*** 206,210 ****
  	for (unit = 0; unit < NIMP; unit++) {
  	    any = 0;
! 	    for (m = imp_softc[unit].imp_hosts; m; m = m->m_next) {
  		hm = mtod(m, struct hmbuf *);
  		hp = hm->hm_hosts; 
--- 207,212 ----
  	for (unit = 0; unit < NIMP; unit++) {
  	    any = 0;
! 	    sc = &imp_softc[unit];
! 	    for (m = sc->imp_hosts; m; m = m->m_next) {
  		hm = mtod(m, struct hmbuf *);
  		hp = hm->hm_hosts; 
***************
*** 221,224 ****
--- 223,228 ----
  				any = 1;
  				hostrelease(hp);
+ 				if (sc->imp_hostq == m)
+ 					sc->imp_hostq = 0;
  			}
  		    }
***************
*** 225,230 ****
  		}
  	    }
! 	    if (any)
  		hostcompress(unit);
  	}
  	splx(s);
--- 229,235 ----
  		}
  	    }
! 	    if (any) {
  		hostcompress(unit);
+ 	    }
  	}
  	splx(s);

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 21:18:24 GMT
From:      joel@VAX.FTP.COM (Joel Gartland)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: ftp PASV command; a one shot deal or for rest of session?


I put forth a very simple question:

	Should a ftp server, after receiving the PASV command, remain in
passive mode for the rest of the ftp session, or just for the next transfer?
It doesn't seem to be stated either way in the RFC (959).
	Of the people I've queried about this, the ratio of opinions is about 
50-50. Has it never been formally set??

					Joel Gartland
					FTP Software

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 22:03:17 GMT
From:      tontonoz@EDN-UNIX.DCA.MIL (James Tontonoz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Test Suite

For your info, the DCEC of DCA has a DoD protocol test system working
on a Vax machine that allows protocol implementations of TCP/IP running on
native machines to be tested  against the DoD standards.  More details
can be had by contacting Mr. Martin Gross of DCEC at 703-437-2165 or
gross@edn-unix.dca.mil

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 22:57:04 GMT
From:      larry@tapa.UUCP (Larry Pajakowski)
To:        comp.protocols.tcp-ip
Subject:   Re: re NetBIOS/TCP (UDP)

We use Netbios/UDP from Excelan and love it.  We use Xenix on the host which
allows us to develop both DOS and Xenix/Unix applications.  Also since rsh is
supported we use SCCS for source code control for the DOS applications.

Total memory usage is about 70k on a 286 box and 7k on a 386 box thanks to
QEMM from Quaterdeck.

We use it and love it.  

A very happy Netbios over UDP user (TCP/IP stuff also).

Larry
larry@tapa.UUCP

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 23:01:27 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

Thanks to everyone who responded and informed me the function of ^O; however,
the question was more specifically "why?".  In a rhetorical vein, why does
EMACS, in general, use standard control characters as application dependent
function characters?  Why would any application?

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 88 23:26:42 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)

Unless I'm misreading him, Chris is saying that telnetd can't tell
when you've cleared the output buffer on the pty.  This can't be true.
Rlogin can tell, by using the funny packet mode pty with select.  Our
telnetd does the same thing.  As far as I can tell, we do find out
when the output buffer has been cleared, and we do issue the
urgent/sync at that time.  At least I see a SYNC whenever I type ^C.
On the Pyramid, I do the "inner loop" of telnet and rlogind inside the
kernel.  There of course there's no trouble getting access to the
information, so things may work a bit better.  (I understand that
Pyramid is going to be distributing that code sometime after the
release of OSx 4.4.)

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 00:17:17 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Please help us archeologists

Folks,

During the brief, but fiery lifetime of the NSFNET Phase-I Backbone
Network Doug Elias and his many friends at Cornell, U Michigan and
U Delaware stashed many megabytes of statistics and performance data
away in archival files. At one time the data collected ranged from
September 1986 through June 1988 and represented an immensely
valuable resource students from all over could trammel over and use
in simulators and so forth.

While collecting and organizing these data Mike Davis discovered an
oxide plow had mysteriously excavated the period from March 87 through
September 87 right off the archive platters both here and at Cornell.
This note is to ask each of you whether you have copies of that data,
which covers a period in which major changes and upgrades were being
made to the software, stashed on your own archives. Speaking for Cornell,
U Michigan, NSF and ourselves on this matter, we would dearly like to
recover the lost bits.

We will reward the swampthing that slithers up with some or all of the
wayward bits with a "I Love an Amphibophile" button.

Dave

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 00:42:48 GMT
From:      joshua@athertn.Atherton.COM (Sleaze Hack)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC talking OSI?

In article <6200010@hpindda.HP.COM> kmont@hpindda.HP.COM (Kevin Montgomery) writes:
>
>	Has anyone seen a copy of RPC that speaks an OSI protocol
>instead of using UDP?  Anyone at TWG (or anyone else) have anything 
>like this available either now or in the works?
>

Yep!  The company you're looking for is called Netwise.  It is at
4745 Walnut St. Boulder, CO 80301; 303-442-8280.  They gave me an email
address of "hao!isis!1com!wldrdg!PERSON", but that is on the ass-end of
nowhere, and I've never been able to use it.

I HAVE NOT USED THEIR PRODUCT.  THE FOLLOWING COMES FROM TALKING WITH THEM
AND READING THEIR LITERATURE.  MY KNOWLEDGE OF OSI STANDARDS IS ALSO LOW.

The product is called RPC TOOL.  It compiles something like C (or maybe
C itself) into server and client stubs.  There is a data transmission
protocol called PDU.  The protocol is "DIS/ISO 8825" according to their
literature.  When I talked to them they said it was "ASN.1". 
They claim to support MS-DOS, VMS (no matter who you bought your
TCP/IP from), UNIX, OS/2, VM, and MVS.  They have an impressive
list of networks on which they run: TCP/IP, OS/2 LAN Manager, NOVELL,
DECnet, OSI?MAP, and SNA/APPC.  They also claim to be "About as fast as
Sun's RPC."  Stubs in ADA are also supported.

It is likely that I will be evaluating (read: writing test programs with)
RPC TOOL in the next month or so.  If you want to hear what I think of it
then, send me email.

Josh
--------                Quote: "If you haven't ported your program, it's not
Addresses:                      a portable program.  No exceptions."  
joshua@atherton.com OR         
sun!athertn!joshua  OR                 
{backbone}!{decwrl!hpda}!athertn!joshua  work:(408)734-9822 home:(415)968-3718

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 03:41:36 GMT
From:      efb@suned1.UUCP (Everett F. Batey II)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: CMU and WIN .. now talking .. thnx Twg

In article <848@suned1.UUCP> suned1!efb@elroy.JPL.Nasa.Gov I wrote:
>Just incorporated TCP/IP packages on two VMS 4.6 MicroVAX IIs.  They are now
>  ...  but ...  CMU 6.3 and WIN_TCP 3.2 complain of timeout.

I AM REALLY IMPRESSED .. following this posting I got some really good AND
thorough .. until resolved ... followup from the Wollongong Group expert.

Never heard about what about the product on the other end of the pipe .. TWG
person proceeded straight to what was amiss and given login access, set me 
straight in a very brief period.  [ The failure was my inattention to detail,
not the product.]

I congratulate TWG on their excellent attitude toward their customers.  My
sole interest in TWG is as a VERY satisfied customer.  Good going Jerry.

/Ev/
-- 
           The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
    efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
      Statements, Opinions ... MINE ... NOT those of my US Employer  

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 04:08:51 GMT
From:      oleary@GODOT.PSC.EDU (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re:  Please help us archeologists

Dave,
I have the stat files from march through august on disk, also two of the
weekly reports from september.  I may also have the monthly september
report somewhere, if no on else has the complete collection I will
be glad to fire these off to you - 

							dave

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 04:16:31 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: is there a need for class A addresses?


      Barry,

   There is a good reason for arguing against a cluster of class B (or C)
addresses over one A (or B).  When one is in a situation where there is
one portal (or just a few portals) into a cluster of networks, and those
networks are richly interconnected, then subnetting is a win.  For
networks outside the portal, only the underlying network needs to be
known to make routing decisions.  With clusters of non-subnetted networks,
each network needs to be known outside the portal.  Adding one address
to the routing mess is vastly preferrable to adding many.

				Later,
				    Bob 
   --------
Phone:  (301)278-6678   AV: 298-6678    FTS: 939-6678
Arpa:   reschly@BRL.MIL (or BRL.ARPA)   UUCP: ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
        Advanced Computer Systems Team
        Systems Engineering and Concepts Analysis Division
        U.S. Army Ballistic Research Laboratory
        ATTN: SLCBR-SE  (Reschly)
        APG, MD  21005-5066             (Hey, *I* don't make 'em up!)

****  For a good time, call: (303) 499-7111.   Seriously!  ****

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 05:52:24 GMT
From:      hjs@LINDY.STANFORD.EDU (Harry Saal)
To:        comp.protocols.tcp-ip
Subject:   Throughput limits on 82586: real or imaginary?

Drawing conclusions about the relative capabilities of the Intel 82586
vs. Lance based on two different controller subsystem designs doesn't
truly indicate the limits or lack thereof in these chips. 

Whether the 82586 is able to keep up with high traffic rates depends on the
surrounding hardware design (to minimize bus latency and wait states) and
on the driver software;  there is nothing inherent in the design of the
chip itself that prevents indefinite reception of back-to-back packets.  We
do it in the Sniffer (at least in highspeed mode), but it does require a
fair degree of heroics and a careful reading  of the latest bugsheet from
Intel;  some modes will generate "dma overrun" regardless of how fast the
memory bus is.

On the transmit side, though, we have not been able to generate
back-to-back packets;  the minimum interframe spacing that a single 82586
can manage seems to be about 40 usec instead of 9.6.  For us that's no big
deal since we're just trying to generate traffic to load the network, and
1500-byte packets separated by 40 usec is about 97% of maximum rate anyway.

It might be true (and this is speculation as to what might have resulted
in the measurements reported by Van) that designing a high performance
controller and writing the drivers is a tougher job for the 82586
than for the Lance. However this is something you do just once, so
there is no excuse not to squeeze the most out of the chip's capabilities.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 06:54:06 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Rlogin vs Telnet in terminal servers

While this discussion on telnet has been most interesting, I don't
think that its entirely relevant to the original question, which
related to rlogin support in terminal servers.

The most likely reason for wanting "rlogin support" in a terminal
server is 100% unrelated to protocols, automatic login (which is
typically not applicable anyway) , terminal type negotiation, or
any of the rest of all of this "can telnet really do ...?" stuff.

The real reason is that users have become trained that the way
one connects to a destination host is by using

	rlogin host

and that after that everything that is typed is sent to the remote
end, until the sequence

	<cr>~.

after which the connection is broken, or until

	<cr>~^Z

which returns to the originating node, without breaking the connection.

If the terminal server implements that functionality, the actual protocol
that's used underneath will be irrelevant for 99% or users.

So, terminal server vendors, please do implement "rlogin", however, by
all means, if you want to, simply make it a front end to your telnet
client, which disables the return to telnet command mode magic character,
and implements the '~' sequences above.  Just don't advertise it as
supporting "rlogin" unless you really do.

This is also likely to be the way that Berkeley can really get rid
of "rlogin" once the telnet client/server support all the required
functionality, the rlogin client can just become a modified telnet,
which does suitable negotiation to appear to be rlogin to the user.

Getting rid of the other r* commands will be rather harder (I suspect
rcp would need several ftp extensions before rcp could be seen as
an ftp alias, and rsh has no real alternative at all that I know of).

kre

ps: while discussion differences between telnet and rlogin, its useful
to remember that telnet client implements a virtual terminal for the
server, whereas rlogin implements a virtual DB25 socket... (or did
when it was created, its a little fancier now).

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 06:56:25 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Output Flushing Guidelines (long)

Mitch,  Thanks for the excellent treatise on Telnet flushing.  While your
"netnote" is great reading, you are right about putting in in the record
with an RFC.  We are only as good as our experiences and their "recording"
so others can benefit from themn.

Dan
-------

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 14:03:36 GMT
From:      ykluger@HAWK.ULOWELL.EDU (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   Questions about SNMP

I have some questions about SNMP. Who can help me ???
I thought of Jeff Case, but I don't know his address.
Is there anybody else?

Your prompt answer will be well appreciated!!!

Yoav Kluger.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 14:19:13 GMT
From:      jose@MCL.UNISYS.COM (Jose Rodriguez)
To:        comp.protocols.tcp-ip
Subject:   The DCA TCP/IP Protocol Test Suite


RE: The TCP/IP Protocol testing suite from DCA:

The bottom line is that it is is available from the National Technical
Information Service for (somewhat) nominal fee in object code form
for (yes) Ultrix 1.1 systems.

At Interop88 I gave a session on the protocol suite that covered
a number of things related to the lab like installation, why install one,
what is needed, etc. It was supposed to be more on the tools the lab
has that support the testing of protocols but people weren't interested
in that. I do recommend finding out how the lab works - its architecture -
before anything else. The NTIS has a document on this, and an article by
Bob Jones published on the Connexions newsletter issue on protocol
testing covers the architecture too.

Anyway I have a package of info that you might find useful (it
includes the letter from OSD on the future of the lab). Send me a US 
mail address. 

Jose Rodriguez
Unisys McLean R&D
jose@kauai.mcl.unisys.com

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 14:27:05 GMT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   ^O in EMACS

Thanks for the information.  Unlike a preacher in an electronic ministry, I
will not request that you keep those cards and letters coming.  This discussion
has reminded me of a song that was popular in my father's youth:

		"If You Knew What the Gnu Knew"

As I recall there were several key changes in that ditty.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 15:43:50 GMT
From:      dab@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   SUPDUP (was: telnet vs rlogin)

SUPDUP, besides having a more reasonable virtual terminal, also provides a
local editing capability for those people who are worried about packet per
keystroke inefficiency.

						David Bridgham

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 18:04:10 GMT
From:      mrose@TWG.COM (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC talking OSI?

Of course, there's also the rpc facility in the ISODE, which implements
the International Standards for Remote Operations over both TCP (using
the method defined in RFC1006) and over pure OSI networks (e.g., SunLink
OSI and Wollongong's OSI stack).  I haven't seen the Netwise software,
but I do know that the ISODE is running world-wide, has interoperated
against other OSI implementations, and is openly available, source code
and all, for a modest handling fee.  Drop a note to Bug-ISODE@TWG.COM to
find out how to get a copy.

/mtr

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 18:24:37 GMT
From:      welch@tut.cis.ohio-state.edu (Arun Welch)
To:        comp.protocols.tcp-ip
Subject:   Host Requirements RFC

I've seen references to the RFC on this list, but can't find it in the
RFC-index.  Is it still a draft?  Is it possible to get a copy of it
anyway?


...arun


----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 18:50:44 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   security problem in ftpd.

Subject: security problem in ftpd.
Index: etc/ftpd 4.3BSD,4.3BSD-tahoe

Description:
	There's a security problem associated with anonymous ftp in all
	systems with Berkeley derived networking.  If your site doesn't
	permit anonymous ftp logins, you're not affected.
Fix:
	The attached shar has three fixes.  The file context.diff.4.3
	is for 4.3BSD systems, context.diff.4.3-tahoe is for 4.3BSD-tahoe
	systems.  The rest of the files are complete source for the
	ftpd(8) program, in case you're a binary site.

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	Makefile
#	context.diff.4.3
#	context.diff.4.3-tahoe
#	ftpcmd.y
#	ftpd.c
#	glob.c
#	logwtmp.c
#	newvers.sh
#	popen.c
#	vers.c
#	version
#
echo x - Makefile
sed 's/^X//' >Makefile << 'END-of-Makefile'
X#
X# Copyright (c) 1988 Regents of the University of California.
X# All rights reserved.
X#
X# Redistribution and use in source and binary forms are permitted
X# provided that the above copyright notice and this paragraph are
X# duplicated in all such forms and that any documentation,
X# advertising materials, and other materials related to such
X# distribution and use acknowledge that the software was developed
X# by the University of California, Berkeley.  The name of the
X# University may not be used to endorse or promote products derived
X# from this software without specific prior written permission.
X# THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X# IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X# WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X#
X#	@(#)Makefile	5.8 (Berkeley) 9/22/88
X#
XCFLAGS=	-O
XLIBC=	/lib/libc.a
XSRCS=	ftpd.c ftpcmd.c glob.c logwtmp.c popen.c vers.c
XOBJS=	ftpd.o ftpcmd.o glob.o logwtmp.o popen.o vers.o
XMAN=	ftpd.0
X
Xall: ftpd
X
Xftpd: ${OBJS} ${LIBC}
X	${CC} -o $@ ${OBJS}
X
Xvers.o: ftpd.c ftpcmd.y
X	sh newvers.sh
X	${CC} ${CFLAGS} -c vers.c
X
Xclean:
X	rm -f ${OBJS} ftpd core ftpcmd.c
X
Xcleandir: clean
X	rm -f ${MAN} tags .depend
X
Xdepend: ${SRCS}
X	mkdep ${CFLAGS} ${SRCS}
X
Xinstall:
X	install -s -o bin -g bin -m 755 ftpd ${DESTDIR}/etc/ftpd
X
Xlint: ${SRCS}
X	lint ${CFLAGS} ${SRCS}
X
Xtags: ${SRCS}
X	ctags ${SRCS}
END-of-Makefile
echo x - context.diff.4.3
sed 's/^X//' >context.diff.4.3 << 'END-of-context.diff.4.3'
XRCS file: RCS/ftpcmd.y,v
Xretrieving revision 1.2
Xdiff -c2 -r1.2 ftpcmd.y
X*** /tmp/,RCSt1026617	Sat Oct 29 23:52:42 1988
X--- ftpcmd.y	Sat Oct 29 23:16:59 1988
X***************
X*** 87,91 ****
X  cmd:		USER SP username CRLF
X  		= {
X! 			extern struct passwd *getpwnam();
X  
X  			logged_in = 0;
X--- 87,91 ----
X  cmd:		USER SP username CRLF
X  		= {
X! 			extern struct passwd *sgetpwnam();
X  
X  			logged_in = 0;
X***************
X*** 92,96 ****
X  			if (strcmp((char *) $3, "ftp") == 0 ||
X  			  strcmp((char *) $3, "anonymous") == 0) {
X! 				if ((pw = getpwnam("ftp")) != NULL) {
X  					guest = 1;
X  					reply(331,
X--- 92,96 ----
X  			if (strcmp((char *) $3, "ftp") == 0 ||
X  			  strcmp((char *) $3, "anonymous") == 0) {
X! 				if ((pw = sgetpwnam("ftp")) != NULL) {
X  					guest = 1;
X  					reply(331,
X***************
X*** 102,106 ****
X  			} else if (checkuser((char *) $3)) {
X  				guest = 0;
X! 				pw = getpwnam((char *) $3);
X  				if (pw == NULL) {
X  					reply(530, "User %s unknown.", $3);
X--- 102,106 ----
X  			} else if (checkuser((char *) $3)) {
X  				guest = 0;
X! 				pw = sgetpwnam((char *) $3);
X  				if (pw == NULL) {
X  					reply(530, "User %s unknown.", $3);
X
X*** ftpd.c.orig	Mon Oct 31 12:13:20 1988
X--- ftpd.c	Mon Oct 31 12:36:14 1988
X***************
X*** 191,201 ****
X  	dologout(-1);
X  }
X  
X  pass(passwd)
X  	char *passwd;
X  {
X! 	char *xpasswd, *savestr();
X! 	static struct passwd save;
X  
X  	if (logged_in || pw == NULL) {
X  		reply(503, "Login with USER first.");
X--- 191,257 ----
X  	dologout(-1);
X  }
X  
X+ /*
X+  * Helper function for sgetpwnam().
X+  */
X+ char *
X+ sgetsave(s)
X+ 	char *s;
X+ {
X+ #ifdef notdef
X+ 	char *new = strdup(s);
X+ #else
X+ 	char *malloc();
X+ 	char *new = malloc((unsigned) strlen(s) + 1);
X+ #endif
X+ 	
X+ 	if (new == NULL) {
X+ 		reply(553, "Local resource failure");	/* ??? */
X+ 		dologout(1);
X+ 	}
X+ #ifndef notdef
X+ 	(void) strcpy(new, s);
X+ #endif
X+ 	return (new);
X+ }
X+ 
X+ /*
X+  * Save the result of a getpwnam.  Used for USER command, since
X+  * the data returned must not be clobbered by any other command
X+  * (e.g., globbing).
X+  */
X+ struct passwd *
X+ sgetpwnam(name)
X+ 	char *name;
X+ {
X+ 	static struct passwd save;
X+ 	register struct passwd *p;
X+ 	char *sgetsave();
X+ 
X+ 	if ((p = getpwnam(name)) == NULL)
X+ 		return (p);
X+ 	if (save.pw_name) {
X+ 		free(save.pw_name);
X+ 		free(save.pw_passwd);
X+ 		free(save.pw_comment);
X+ 		free(save.pw_gecos);
X+ 		free(save.pw_dir);
X+ 		free(save.pw_shell);
X+ 	}
X+ 	save = *p;
X+ 	save.pw_name = sgetsave(p->pw_name);
X+ 	save.pw_passwd = sgetsave(p->pw_passwd);
X+ 	save.pw_comment = sgetsave(p->pw_comment);
X+ 	save.pw_gecos = sgetsave(p->pw_gecos);
X+ 	save.pw_dir = sgetsave(p->pw_dir);
X+ 	save.pw_shell = sgetsave(p->pw_shell);
X+ 	return (&save);
X+ }
X+ 
X  pass(passwd)
X  	char *passwd;
X  {
X! 	char *xpasswd;
X  
X  	if (logged_in || pw == NULL) {
X  		reply(503, "Login with USER first.");
X***************
X*** 235,252 ****
X  	logged_in = 1;
X  	dologin(pw);
X  	seteuid(pw->pw_uid);
X- 	/*
X- 	 * Save everything so globbing doesn't
X- 	 * clobber the fields.
X- 	 */
X- 	save = *pw;
X- 	save.pw_name = savestr(pw->pw_name);
X- 	save.pw_passwd = savestr(pw->pw_passwd);
X- 	save.pw_comment = savestr(pw->pw_comment);
X- 	save.pw_gecos = savestr(pw->pw_gecos);
X- 	save.pw_dir = savestr(pw->pw_dir);
X- 	save.pw_shell = savestr(pw->pw_shell);
X- 	pw = &save;
X  	home = pw->pw_dir;		/* home dir for globbing */
X  	return;
X  bad:
X--- 291,296 ----
X***************
X*** 254,271 ****
X  	pw = NULL;
X  }
X  
X- char *
X- savestr(s)
X- 	char *s;
X- {
X- 	char *malloc();
X- 	char *new = malloc((unsigned) strlen(s) + 1);
X- 	
X- 	if (new != NULL)
X- 		(void) strcpy(new, s);
X- 	return (new);
X- }
X- 
X  retrieve(cmd, name)
X  	char *cmd, *name;
X  {
X--- 298,303 ----
X***************
X*** 771,778 ****
X  /*
X   * Record login in wtmp file.
X   */
X! dologin(pw)
X! 	struct passwd *pw;
X  {
X  	char line[32];
X  
X--- 803,810 ----
X  /*
X   * Record login in wtmp file.
X   */
X! dologin(p)
X! 	struct passwd *p;
X  {
X  	char line[32];
X  
X***************
X*** 780,786 ****
X  		/* hack, but must be unique and no tty line */
X  		(void) sprintf(line, "ftp%d", getpid());
X  		SCPYN(utmp.ut_line, line);
X! 		SCPYN(utmp.ut_name, pw->pw_name);
X  		SCPYN(utmp.ut_host, remotehost);
X  		utmp.ut_time = (long) time((time_t *) 0);
X  		(void) write(wtmp, (char *)&utmp, sizeof (utmp));
X--- 812,818 ----
X  		/* hack, but must be unique and no tty line */
X  		(void) sprintf(line, "ftp%d", getpid());
X  		SCPYN(utmp.ut_line, line);
X! 		SCPYN(utmp.ut_name, p->pw_name);
X  		SCPYN(utmp.ut_host, remotehost);
X  		utmp.ut_time = (long) time((time_t *) 0);
X  		(void) write(wtmp, (char *)&utmp, sizeof (utmp));
X***************
X*** 934,960 ****
X  	register char *name;
X  {
X  	register char *cp;
X- 	char line[BUFSIZ], *index(), *getusershell();
X  	FILE *fd;
X! 	struct passwd *pw;
X  	int found = 0;
X  
X! 	pw = getpwnam(name);
X! 	if (pw == NULL)
X  		return (0);
X  	while ((cp = getusershell()) != NULL)
X! 		if (strcmp(cp, pw->pw_shell) == 0)
X  			break;
X  	endpwent();
X  	endusershell();
X  	if (cp == NULL)
X  		return (0);
X! 	fd = fopen(FTPUSERS, "r");
X! 	if (fd == NULL)
X  		return (1);
X  	while (fgets(line, sizeof (line), fd) != NULL) {
X! 		cp = index(line, '\n');
X! 		if (cp)
X  			*cp = '\0';
X  		if (strcmp(line, name) == 0) {
X  			found++;
X--- 966,992 ----
X  	register char *name;
X  {
X  	register char *cp;
X  	FILE *fd;
X! 	struct passwd *p;
X! 	char *shell;
X  	int found = 0;
X+ 	char line[BUFSIZ], *index(), *getusershell();
X  
X! 	if ((p = getpwnam(name)) == NULL)
X  		return (0);
X+ 	if ((shell = p->pw_shell) == NULL || *shell == 0)
X+ 		shell = "/bin/sh";
X  	while ((cp = getusershell()) != NULL)
X! 		if (strcmp(cp, shell) == 0)
X  			break;
X  	endpwent();
X  	endusershell();
X  	if (cp == NULL)
X  		return (0);
X! 	if ((fd = fopen(FTPUSERS, "r")) == NULL)
X  		return (1);
X  	while (fgets(line, sizeof (line), fd) != NULL) {
X! 		if ((cp = index(line, '\n')) != NULL)
X  			*cp = '\0';
X  		if (strcmp(line, name) == 0) {
X  			found++;
END-of-context.diff.4.3
echo x - context.diff.4.3-tahoe
sed 's/^X//' >context.diff.4.3-tahoe << 'END-of-context.diff.4.3-tahoe'
XRCS file: RCS/ftpcmd.y,v
Xretrieving revision 1.2
Xdiff -c2 -r1.2 ftpcmd.y
X*** /tmp/,RCSt1026617	Sat Oct 29 23:52:42 1988
X--- ftpcmd.y	Sat Oct 29 23:16:59 1988
X***************
X*** 87,91 ****
X  cmd:		USER SP username CRLF
X  		= {
X! 			extern struct passwd *getpwnam();
X  
X  			logged_in = 0;
X--- 87,91 ----
X  cmd:		USER SP username CRLF
X  		= {
X! 			extern struct passwd *sgetpwnam();
X  
X  			logged_in = 0;
X***************
X*** 92,96 ****
X  			if (strcmp((char *) $3, "ftp") == 0 ||
X  			  strcmp((char *) $3, "anonymous") == 0) {
X! 				if ((pw = getpwnam("ftp")) != NULL) {
X  					guest = 1;
X  					reply(331,
X--- 92,96 ----
X  			if (strcmp((char *) $3, "ftp") == 0 ||
X  			  strcmp((char *) $3, "anonymous") == 0) {
X! 				if ((pw = sgetpwnam("ftp")) != NULL) {
X  					guest = 1;
X  					reply(331,
X***************
X*** 102,106 ****
X  			} else if (checkuser((char *) $3)) {
X  				guest = 0;
X! 				pw = getpwnam((char *) $3);
X  				if (pw == NULL) {
X  					reply(530, "User %s unknown.", $3);
X--- 102,106 ----
X  			} else if (checkuser((char *) $3)) {
X  				guest = 0;
X! 				pw = sgetpwnam((char *) $3);
X  				if (pw == NULL) {
X  					reply(530, "User %s unknown.", $3);
X
X
XRCS file: RCS/ftpd.c,v
Xretrieving revision 1.3
Xdiff -c2 -r1.3 ftpd.c
X*** /tmp/,RCSt1026617	Sat Oct 29 23:52:48 1988
X--- ftpd.c	Sat Oct 29 23:49:01 1988
X***************
X*** 194,202 ****
X  }
X  
X  pass(passwd)
X  	char *passwd;
X  {
X! 	char *xpasswd, *savestr();
X! 	static struct passwd save;
X  
X  	if (logged_in || pw == NULL) {
X--- 194,258 ----
X  }
X  
X+ /*
X+  * Helper function for sgetpwnam().
X+  */
X+ char *
X+ sgetsave(s)
X+ 	char *s;
X+ {
X+ #ifdef notdef
X+ 	char *new = strdup(s);
X+ #else
X+ 	char *malloc();
X+ 	char *new = malloc((unsigned) strlen(s) + 1);
X+ #endif
X+ 	
X+ 	if (new == NULL) {
X+ 		reply(553, "Local resource failure");	/* ??? */
X+ 		dologout(1);
X+ 	}
X+ #ifndef notdef
X+ 	(void) strcpy(new, s);
X+ #endif
X+ 	return (new);
X+ }
X+ 
X+ /*
X+  * Save the result of a getpwnam.  Used for USER command, since
X+  * the data returned must not be clobbered by any other command
X+  * (e.g., globbing).
X+  */
X+ struct passwd *
X+ sgetpwnam(name)
X+ 	char *name;
X+ {
X+ 	static struct passwd save;
X+ 	register struct passwd *p;
X+ 	char *sgetsave();
X+ 
X+ 	if ((p = getpwnam(name)) == NULL)
X+ 		return (p);
X+ 	if (save.pw_name) {
X+ 		free(save.pw_name);
X+ 		free(save.pw_passwd);
X+ 		free(save.pw_comment);
X+ 		free(save.pw_gecos);
X+ 		free(save.pw_dir);
X+ 		free(save.pw_shell);
X+ 	}
X+ 	save = *p;
X+ 	save.pw_name = sgetsave(p->pw_name);
X+ 	save.pw_passwd = sgetsave(p->pw_passwd);
X+ 	save.pw_comment = sgetsave(p->pw_comment);
X+ 	save.pw_gecos = sgetsave(p->pw_gecos);
X+ 	save.pw_dir = sgetsave(p->pw_dir);
X+ 	save.pw_shell = sgetsave(p->pw_shell);
X+ 	return (&save);
X+ }
X+ 
X  pass(passwd)
X  	char *passwd;
X  {
X! 	char *xpasswd;
X  
X  	if (logged_in || pw == NULL) {
X***************
X*** 238,253 ****
X  	dologin(pw);
X  	seteuid(pw->pw_uid);
X- 	/*
X- 	 * Save everything so globbing doesn't
X- 	 * clobber the fields.
X- 	 */
X- 	save = *pw;
X- 	save.pw_name = savestr(pw->pw_name);
X- 	save.pw_passwd = savestr(pw->pw_passwd);
X- 	save.pw_comment = savestr(pw->pw_comment);
X- 	save.pw_gecos = savestr(pw->pw_gecos);
X- 	save.pw_dir = savestr(pw->pw_dir);
X- 	save.pw_shell = savestr(pw->pw_shell);
X- 	pw = &save;
X  	home = pw->pw_dir;		/* home dir for globbing */
X  	return;
X--- 294,297 ----
X***************
X*** 257,272 ****
X  }
X  
X- char *
X- savestr(s)
X- 	char *s;
X- {
X- 	char *malloc();
X- 	char *new = malloc((unsigned) strlen(s) + 1);
X- 	
X- 	if (new != NULL)
X- 		(void) strcpy(new, s);
X- 	return (new);
X- }
X- 
X  retrieve(cmd, name)
X  	char *cmd, *name;
X--- 301,304 ----
X***************
X*** 785,790 ****
X   * Record login in wtmp file.
X   */
X! dologin(pw)
X! 	struct passwd *pw;
X  {
X  	char line[32];
X--- 817,822 ----
X   * Record login in wtmp file.
X   */
X! dologin(p)
X! 	struct passwd *p;
X  {
X  	char line[32];
X***************
X*** 794,798 ****
X  		(void) sprintf(line, "ftp%d", getpid());
X  		SCPYN(utmp.ut_line, line);
X! 		SCPYN(utmp.ut_name, pw->pw_name);
X  		SCPYN(utmp.ut_host, remotehost);
X  		utmp.ut_time = (long) time((time_t *) 0);
X--- 826,830 ----
X  		(void) sprintf(line, "ftp%d", getpid());
X  		SCPYN(utmp.ut_line, line);
X! 		SCPYN(utmp.ut_name, p->pw_name);
X  		SCPYN(utmp.ut_host, remotehost);
X  		utmp.ut_time = (long) time((time_t *) 0);
X***************
X*** 948,963 ****
X  {
X  	register char *cp;
X- 	char line[BUFSIZ], *index(), *getusershell();
X  	FILE *fd;
X! 	struct passwd *pw;
X  	int found = 0;
X  
X! 	pw = getpwnam(name);
X! 	if (pw == NULL)
X  		return (0);
X! 	if (pw ->pw_shell == NULL || pw->pw_shell[0] == NULL)
X! 		pw->pw_shell = "/bin/sh";
X  	while ((cp = getusershell()) != NULL)
X! 		if (strcmp(cp, pw->pw_shell) == 0)
X  			break;
X  	endusershell();
X--- 980,995 ----
X  {
X  	register char *cp;
X  	FILE *fd;
X! 	struct passwd *p;
X! 	char *shell;
X  	int found = 0;
X+ 	char line[BUFSIZ], *index(), *getusershell();
X  
X! 	if ((p = getpwnam(name)) == NULL)
X  		return (0);
X! 	if ((shell = p->pw_shell) == NULL || *shell == 0)
X! 		shell = "/bin/sh";
X  	while ((cp = getusershell()) != NULL)
X! 		if (strcmp(cp, shell) == 0)
X  			break;
X  	endusershell();
X***************
X*** 964,973 ****
X  	if (cp == NULL)
X  		return (0);
X! 	fd = fopen(FTPUSERS, "r");
X! 	if (fd == NULL)
X  		return (1);
X  	while (fgets(line, sizeof (line), fd) != NULL) {
X! 		cp = index(line, '\n');
X! 		if (cp)
X  			*cp = '\0';
X  		if (strcmp(line, name) == 0) {
X--- 996,1003 ----
X  	if (cp == NULL)
X  		return (0);
X! 	if ((fd = fopen(FTPUSERS, "r")) == NULL)
X  		return (1);
X  	while (fgets(line, sizeof (line), fd) != NULL) {
X! 		if ((cp = index(line, '\n')) != NULL)
X  			*cp = '\0';
X  		if (strcmp(line, name) == 0) {
X
END-of-context.diff.4.3-tahoe
echo x - ftpcmd.y
sed 's/^X//' >ftpcmd.y << 'END-of-ftpcmd.y'
X/*
X * Copyright (c) 1985 Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X *
X *	@(#)ftpcmd.y	5.12 (Berkeley) 10/30/88
X */
X
X/*
X * Grammar for FTP commands.
X * See RFC 765.
X */
X
X%{
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)ftpcmd.y	5.12 (Berkeley) 10/30/88";
X#endif /* not lint */
X
X#include <sys/types.h>
X#include <sys/socket.h>
X
X#include <netinet/in.h>
X
X#include <arpa/ftp.h>
X
X#include <stdio.h>
X#include <signal.h>
X#include <ctype.h>
X#include <pwd.h>
X#include <setjmp.h>
X#include <syslog.h>
X
Xextern	struct sockaddr_in data_dest;
Xextern	int logged_in;
Xextern	struct passwd *pw;
Xextern	int guest;
Xextern	int logging;
Xextern	int type;
Xextern	int form;
Xextern	int debug;
Xextern	int timeout;
Xextern  int pdata;
Xextern	char hostname[];
Xextern	char *globerr;
Xextern	int usedefault;
Xextern	int unique;
Xextern  int transflag;
Xextern  char tmpline[];
Xchar	**glob();
X
Xstatic	int cmd_type;
Xstatic	int cmd_form;
Xstatic	int cmd_bytesz;
Xchar cbuf[512];
Xchar *fromname;
X
Xchar	*index();
X%}
X
X%token
X	A	B	C	E	F	I
X	L	N	P	R	S	T
X
X	SP	CRLF	COMMA	STRING	NUMBER
X
X	USER	PASS	ACCT	REIN	QUIT	PORT
X	PASV	TYPE	STRU	MODE	RETR	STOR
X	APPE	MLFL	MAIL	MSND	MSOM	MSAM
X	MRSQ	MRCP	ALLO	REST	RNFR	RNTO
X	ABOR	DELE	CWD	LIST	NLST	SITE
X	STAT	HELP	NOOP	XMKD	XRMD	XPWD
X	XCUP	STOU
X
X	LEXERR
X
X%start	cmd_list
X
X%%
X
Xcmd_list:	/* empty */
X	|	cmd_list cmd
X		= {
X			fromname = (char *) 0;
X		}
X	|	cmd_list rcmd
X	;
X
Xcmd:		USER SP username CRLF
X		= {
X			extern struct passwd *sgetpwnam();
X
X			logged_in = 0;
X			if (strcmp((char *) $3, "ftp") == 0 ||
X			  strcmp((char *) $3, "anonymous") == 0) {
X				if ((pw = sgetpwnam("ftp")) != NULL) {
X					guest = 1;
X					reply(331,
X				  "Guest login ok, send ident as password.");
X				}
X				else {
X					reply(530, "User %s unknown.", $3);
X				}
X			} else if (checkuser((char *) $3)) {
X				guest = 0;
X				pw = sgetpwnam((char *) $3);
X				if (pw == NULL) {
X					reply(530, "User %s unknown.", $3);
X				}
X				else {
X				    reply(331, "Password required for %s.", $3);
X				}
X			} else {
X				reply(530, "User %s access denied.", $3);
X			}
X			free((char *) $3);
X		}
X	|	PASS SP password CRLF
X		= {
X			pass((char *) $3);
X			free((char *) $3);
X		}
X	|	PORT SP host_port CRLF
X		= {
X			usedefault = 0;
X			if (pdata > 0) {
X				(void) close(pdata);
X			}
X			pdata = -1;
X			reply(200, "PORT command successful.");
X		}
X	|	PASV CRLF
X		= {
X			passive();
X		}
X	|	TYPE SP type_code CRLF
X		= {
X			switch (cmd_type) {
X
X			case TYPE_A:
X				if (cmd_form == FORM_N) {
X					reply(200, "Type set to A.");
X					type = cmd_type;
X					form = cmd_form;
X				} else
X					reply(504, "Form must be N.");
X				break;
X
X			case TYPE_E:
X				reply(504, "Type E not implemented.");
X				break;
X
X			case TYPE_I:
X				reply(200, "Type set to I.");
X				type = cmd_type;
X				break;
X
X			case TYPE_L:
X				if (cmd_bytesz == 8) {
X					reply(200,
X					    "Type set to L (byte size 8).");
X					type = cmd_type;
X				} else
X					reply(504, "Byte size must be 8.");
X			}
X		}
X	|	STRU SP struct_code CRLF
X		= {
X			switch ($3) {
X
X			case STRU_F:
X				reply(200, "STRU F ok.");
X				break;
X
X			default:
X				reply(504, "Unimplemented STRU type.");
X			}
X		}
X	|	MODE SP mode_code CRLF
X		= {
X			switch ($3) {
X
X			case MODE_S:
X				reply(200, "MODE S ok.");
X				break;
X
X			default:
X				reply(502, "Unimplemented MODE type.");
X			}
X		}
X	|	ALLO SP NUMBER CRLF
X		= {
X			reply(202, "ALLO command ignored.");
X		}
X	|	RETR check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				retrieve((char *) 0, (char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	STOR check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				store((char *) $4, "w");
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	APPE check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				store((char *) $4, "a");
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	NLST check_login CRLF
X		= {
X			if ($2)
X				retrieve("/bin/ls", "");
X		}
X	|	NLST check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				retrieve("/bin/ls %s", (char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	LIST check_login CRLF
X		= {
X			if ($2)
X				retrieve("/bin/ls -lg", "");
X		}
X	|	LIST check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				retrieve("/bin/ls -lg %s", (char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	DELE check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				delete((char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	RNTO SP pathname CRLF
X		= {
X			if (fromname) {
X				renamecmd(fromname, (char *) $3);
X				free(fromname);
X				fromname = (char *) 0;
X			} else {
X				reply(503, "Bad sequence of commands.");
X			}
X			free((char *) $3);
X		}
X	|	ABOR CRLF
X		= {
X			reply(225, "ABOR command successful.");
X		}
X	|	CWD check_login CRLF
X		= {
X			if ($2)
X				cwd(pw->pw_dir);
X		}
X	|	CWD check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				cwd((char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	HELP CRLF
X		= {
X			help((char *) 0);
X		}
X	|	HELP SP STRING CRLF
X		= {
X			help((char *) $3);
X		}
X	|	NOOP CRLF
X		= {
X			reply(200, "NOOP command successful.");
X		}
X	|	XMKD check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				makedir((char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	XRMD check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL)
X				removedir((char *) $4);
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	XPWD check_login CRLF
X		= {
X			if ($2)
X				pwd();
X		}
X	|	XCUP check_login CRLF
X		= {
X			if ($2)
X				cwd("..");
X		}
X	|	STOU check_login SP pathname CRLF
X		= {
X			if ($2 && $4 != NULL) {
X				unique++;
X				store((char *) $4, "w");
X				unique = 0;
X			}
X			if ($4 != NULL)
X				free((char *) $4);
X		}
X	|	QUIT CRLF
X		= {
X			reply(221, "Goodbye.");
X			dologout(0);
X		}
X	|	error CRLF
X		= {
X			yyerrok;
X		}
X	;
X
Xrcmd:		RNFR check_login SP pathname CRLF
X		= {
X			char *renamefrom();
X
X			if ($2 && $4) {
X				fromname = renamefrom((char *) $4);
X				if (fromname == (char *) 0 && $4) {
X					free((char *) $4);
X				}
X			}
X		}
X	;
X		
Xusername:	STRING
X	;
X
Xpassword:	STRING
X	;
X
Xbyte_size:	NUMBER
X	;
X
Xhost_port:	NUMBER COMMA NUMBER COMMA NUMBER COMMA NUMBER COMMA 
X		NUMBER COMMA NUMBER
X		= {
X			register char *a, *p;
X
X			a = (char *)&data_dest.sin_addr;
X			a[0] = $1; a[1] = $3; a[2] = $5; a[3] = $7;
X			p = (char *)&data_dest.sin_port;
X			p[0] = $9; p[1] = $11;
X			data_dest.sin_family = AF_INET;
X		}
X	;
X
Xform_code:	N
X	= {
X		$$ = FORM_N;
X	}
X	|	T
X	= {
X		$$ = FORM_T;
X	}
X	|	C
X	= {
X		$$ = FORM_C;
X	}
X	;
X
Xtype_code:	A
X	= {
X		cmd_type = TYPE_A;
X		cmd_form = FORM_N;
X	}
X	|	A SP form_code
X	= {
X		cmd_type = TYPE_A;
X		cmd_form = $3;
X	}
X	|	E
X	= {
X		cmd_type = TYPE_E;
X		cmd_form = FORM_N;
X	}
X	|	E SP form_code
X	= {
X		cmd_type = TYPE_E;
X		cmd_form = $3;
X	}
X	|	I
X	= {
X		cmd_type = TYPE_I;
X	}
X	|	L
X	= {
X		cmd_type = TYPE_L;
X		cmd_bytesz = 8;
X	}
X	|	L SP byte_size
X	= {
X		cmd_type = TYPE_L;
X		cmd_bytesz = $3;
X	}
X	/* this is for a bug in the BBN ftp */
X	|	L byte_size
X	= {
X		cmd_type = TYPE_L;
X		cmd_bytesz = $2;
X	}
X	;
X
Xstruct_code:	F
X	= {
X		$$ = STRU_F;
X	}
X	|	R
X	= {
X		$$ = STRU_R;
X	}
X	|	P
X	= {
X		$$ = STRU_P;
X	}
X	;
X
Xmode_code:	S
X	= {
X		$$ = MODE_S;
X	}
X	|	B
X	= {
X		$$ = MODE_B;
X	}
X	|	C
X	= {
X		$$ = MODE_C;
X	}
X	;
X
Xpathname:	pathstring
X	= {
X		/*
X		 * Problem: this production is used for all pathname
X		 * processing, but only gives a 550 error reply.
X		 * This is a valid reply in some cases but not in others.
X		 */
X		if ($1 && strncmp((char *) $1, "~", 1) == 0) {
X			$$ = (int)*glob((char *) $1);
X			if (globerr != NULL) {
X				reply(550, globerr);
X				$$ = NULL;
X			}
X			free((char *) $1);
X		} else
X			$$ = $1;
X	}
X	;
X
Xpathstring:	STRING
X	;
X
Xcheck_login:	/* empty */
X	= {
X		if (logged_in)
X			$$ = 1;
X		else {
X			reply(530, "Please login with USER and PASS.");
X			$$ = 0;
X		}
X	}
X	;
X
X%%
X
Xextern jmp_buf errcatch;
X
X#define	CMD	0	/* beginning of command */
X#define	ARGS	1	/* expect miscellaneous arguments */
X#define	STR1	2	/* expect SP followed by STRING */
X#define	STR2	3	/* expect STRING */
X#define	OSTR	4	/* optional STRING */
X
Xstruct tab {
X	char	*name;
X	short	token;
X	short	state;
X	short	implemented;	/* 1 if command is implemented */
X	char	*help;
X};
X
Xstruct tab cmdtab[] = {		/* In order defined in RFC 765 */
X	{ "USER", USER, STR1, 1,	"<sp> username" },
X	{ "PASS", PASS, STR1, 1,	"<sp> password" },
X	{ "ACCT", ACCT, STR1, 0,	"(specify account)" },
X	{ "REIN", REIN, ARGS, 0,	"(reinitialize server state)" },
X	{ "QUIT", QUIT, ARGS, 1,	"(terminate service)", },
X	{ "PORT", PORT, ARGS, 1,	"<sp> b0, b1, b2, b3, b4" },
X	{ "PASV", PASV, ARGS, 1,	"(set server in passive mode)" },
X	{ "TYPE", TYPE, ARGS, 1,	"<sp> [ A | E | I | L ]" },
X	{ "STRU", STRU, ARGS, 1,	"(specify file structure)" },
X	{ "MODE", MODE, ARGS, 1,	"(specify transfer mode)" },
X	{ "RETR", RETR, STR1, 1,	"<sp> file-name" },
X	{ "STOR", STOR, STR1, 1,	"<sp> file-name" },
X	{ "APPE", APPE, STR1, 1,	"<sp> file-name" },
X	{ "MLFL", MLFL, OSTR, 0,	"(mail file)" },
X	{ "MAIL", MAIL, OSTR, 0,	"(mail to user)" },
X	{ "MSND", MSND, OSTR, 0,	"(mail send to terminal)" },
X	{ "MSOM", MSOM, OSTR, 0,	"(mail send to terminal or mailbox)" },
X	{ "MSAM", MSAM, OSTR, 0,	"(mail send to terminal and mailbox)" },
X	{ "MRSQ", MRSQ, OSTR, 0,	"(mail recipient scheme question)" },
X	{ "MRCP", MRCP, STR1, 0,	"(mail recipient)" },
X	{ "ALLO", ALLO, ARGS, 1,	"allocate storage (vacuously)" },
X	{ "REST", REST, STR1, 0,	"(restart command)" },
X	{ "RNFR", RNFR, STR1, 1,	"<sp> file-name" },
X	{ "RNTO", RNTO, STR1, 1,	"<sp> file-name" },
X	{ "ABOR", ABOR, ARGS, 1,	"(abort operation)" },
X	{ "DELE", DELE, STR1, 1,	"<sp> file-name" },
X	{ "CWD",  CWD,  OSTR, 1,	"[ <sp> directory-name]" },
X	{ "XCWD", CWD,	OSTR, 1,	"[ <sp> directory-name ]" },
X	{ "LIST", LIST, OSTR, 1,	"[ <sp> path-name ]" },
X	{ "NLST", NLST, OSTR, 1,	"[ <sp> path-name ]" },
X	{ "SITE", SITE, STR1, 0,	"(get site parameters)" },
X	{ "STAT", STAT, OSTR, 0,	"(get server status)" },
X	{ "HELP", HELP, OSTR, 1,	"[ <sp> <string> ]" },
X	{ "NOOP", NOOP, ARGS, 1,	"" },
X	{ "MKD",  XMKD, STR1, 1,	"<sp> path-name" },
X	{ "XMKD", XMKD, STR1, 1,	"<sp> path-name" },
X	{ "RMD",  XRMD, STR1, 1,	"<sp> path-name" },
X	{ "XRMD", XRMD, STR1, 1,	"<sp> path-name" },
X	{ "PWD",  XPWD, ARGS, 1,	"(return current directory)" },
X	{ "XPWD", XPWD, ARGS, 1,	"(return current directory)" },
X	{ "CDUP", XCUP, ARGS, 1,	"(change to parent directory)" },
X	{ "XCUP", XCUP, ARGS, 1,	"(change to parent directory)" },
X	{ "STOU", STOU, STR1, 1,	"<sp> file-name" },
X	{ NULL,   0,    0,    0,	0 }
X};
X
Xstruct tab *
Xlookup(cmd)
X	char *cmd;
X{
X	register struct tab *p;
X
X	for (p = cmdtab; p->name != NULL; p++)
X		if (strcmp(cmd, p->name) == 0)
X			return (p);
X	return (0);
X}
X
X#include <arpa/telnet.h>
X
X/*
X * getline - a hacked up version of fgets to ignore TELNET escape codes.
X */
Xchar *
Xgetline(s, n, iop)
X	char *s;
X	register FILE *iop;
X{
X	register c;
X	register char *cs;
X
X	cs = s;
X/* tmpline may contain saved command from urgent mode interruption */
X	for (c = 0; tmpline[c] != '\0' && --n > 0; ++c) {
X		*cs++ = tmpline[c];
X		if (tmpline[c] == '\n') {
X			*cs++ = '\0';
X			if (debug) {
X				syslog(LOG_DEBUG, "FTPD: command: %s", s);
X			}
X			tmpline[0] = '\0';
X			return(s);
X		}
X		if (c == 0) {
X			tmpline[0] = '\0';
X		}
X	}
X	while (--n > 0 && (c = getc(iop)) != EOF) {
X		c = 0377 & c;
X		while (c == IAC) {
X			switch (c = 0377 & getc(iop)) {
X			case WILL:
X			case WONT:
X				c = 0377 & getc(iop);
X				printf("%c%c%c", IAC, WONT, c);
X				(void) fflush(stdout);
X				break;
X			case DO:
X			case DONT:
X				c = 0377 & getc(iop);
X				printf("%c%c%c", IAC, DONT, c);
X				(void) fflush(stdout);
X				break;
X			default:
X				break;
X			}
X			c = 0377 & getc(iop); /* try next character */
X		}
X		*cs++ = c;
X		if (c=='\n')
X			break;
X	}
X	if (c == EOF && cs == s)
X		return (NULL);
X	*cs++ = '\0';
X	if (debug) {
X		syslog(LOG_DEBUG, "FTPD: command: %s", s);
X	}
X	return (s);
X}
X
Xstatic int
Xtoolong()
X{
X	time_t now;
X	extern char *ctime();
X	extern time_t time();
X
X	reply(421,
X	  "Timeout (%d seconds): closing control connection.", timeout);
X	(void) time(&now);
X	if (logging) {
X		syslog(LOG_INFO,
X			"FTPD: User %s timed out after %d seconds at %s",
X			(pw ? pw -> pw_name : "unknown"), timeout, ctime(&now));
X	}
X	dologout(1);
X}
X
Xyylex()
X{
X	static int cpos, state;
X	register char *cp;
X	register struct tab *p;
X	int n;
X	char c;
X
X	for (;;) {
X		switch (state) {
X
X		case CMD:
X			(void) signal(SIGALRM, toolong);
X			(void) alarm((unsigned) timeout);
X			if (getline(cbuf, sizeof(cbuf)-1, stdin) == NULL) {
X				reply(221, "You could at least say goodbye.");
X				dologout(0);
X			}
X			(void) alarm(0);
X			if (index(cbuf, '\r')) {
X				cp = index(cbuf, '\r');
X				cp[0] = '\n'; cp[1] = 0;
X			}
X			if (index(cbuf, ' '))
X				cpos = index(cbuf, ' ') - cbuf;
X			else
X				cpos = index(cbuf, '\n') - cbuf;
X			if (cpos == 0) {
X				cpos = 4;
X			}
X			c = cbuf[cpos];
X			cbuf[cpos] = '\0';
X			upper(cbuf);
X			p = lookup(cbuf);
X			cbuf[cpos] = c;
X			if (p != 0) {
X				if (p->implemented == 0) {
X					nack(p->name);
X					longjmp(errcatch,0);
X					/* NOTREACHED */
X				}
X				state = p->state;
X				yylval = (int) p->name;
X				return (p->token);
X			}
X			break;
X
X		case OSTR:
X			if (cbuf[cpos] == '\n') {
X				state = CMD;
X				return (CRLF);
X			}
X			/* FALL THRU */
X
X		case STR1:
X			if (cbuf[cpos] == ' ') {
X				cpos++;
X				state = STR2;
X				return (SP);
X			}
X			break;
X
X		case STR2:
X			cp = &cbuf[cpos];
X			n = strlen(cp);
X			cpos += n - 1;
X			/*
X			 * Make sure the string is nonempty and \n terminated.
X			 */
X			if (n > 1 && cbuf[cpos] == '\n') {
X				cbuf[cpos] = '\0';
X				yylval = copy(cp);
X				cbuf[cpos] = '\n';
X				state = ARGS;
X				return (STRING);
X			}
X			break;
X
X		case ARGS:
X			if (isdigit(cbuf[cpos])) {
X				cp = &cbuf[cpos];
X				while (isdigit(cbuf[++cpos]))
X					;
X				c = cbuf[cpos];
X				cbuf[cpos] = '\0';
X				yylval = atoi(cp);
X				cbuf[cpos] = c;
X				return (NUMBER);
X			}
X			switch (cbuf[cpos++]) {
X
X			case '\n':
X				state = CMD;
X				return (CRLF);
X
X			case ' ':
X				return (SP);
X
X			case ',':
X				return (COMMA);
X
X			case 'A':
X			case 'a':
X				return (A);
X
X			case 'B':
X			case 'b':
X				return (B);
X
X			case 'C':
X			case 'c':
X				return (C);
X
X			case 'E':
X			case 'e':
X				return (E);
X
X			case 'F':
X			case 'f':
X				return (F);
X
X			case 'I':
X			case 'i':
X				return (I);
X
X			case 'L':
X			case 'l':
X				return (L);
X
X			case 'N':
X			case 'n':
X				return (N);
X
X			case 'P':
X			case 'p':
X				return (P);
X
X			case 'R':
X			case 'r':
X				return (R);
X
X			case 'S':
X			case 's':
X				return (S);
X
X			case 'T':
X			case 't':
X				return (T);
X
X			}
X			break;
X
X		default:
X			fatal("Unknown state in scanner.");
X		}
X		yyerror((char *) 0);
X		state = CMD;
X		longjmp(errcatch,0);
X	}
X}
X
Xupper(s)
X	char *s;
X{
X	while (*s != '\0') {
X		if (islower(*s))
X			*s = toupper(*s);
X		s++;
X	}
X}
X
Xcopy(s)
X	char *s;
X{
X	char *p;
X	extern char *malloc(), *strcpy();
X
X	p = malloc((unsigned) strlen(s) + 1);
X	if (p == NULL)
X		fatal("Ran out of memory.");
X	(void) strcpy(p, s);
X	return ((int)p);
X}
X
Xhelp(s)
X	char *s;
X{
X	register struct tab *c;
X	register int width, NCMDS;
X
X	width = 0, NCMDS = 0;
X	for (c = cmdtab; c->name != NULL; c++) {
X		int len = strlen(c->name) + 1;
X
X		if (len > width)
X			width = len;
X		NCMDS++;
X	}
X	width = (width + 8) &~ 7;
X	if (s == 0) {
X		register int i, j, w;
X		int columns, lines;
X
X		lreply(214,
X	  "The following commands are recognized (* =>'s unimplemented).");
X		columns = 76 / width;
X		if (columns == 0)
X			columns = 1;
X		lines = (NCMDS + columns - 1) / columns;
X		for (i = 0; i < lines; i++) {
X			printf("   ");
X			for (j = 0; j < columns; j++) {
X				c = cmdtab + j * lines + i;
X				printf("%s%c", c->name,
X					c->implemented ? ' ' : '*');
X				if (c + lines >= &cmdtab[NCMDS])
X					break;
X				w = strlen(c->name) + 1;
X				while (w < width) {
X					putchar(' ');
X					w++;
X				}
X			}
X			printf("\r\n");
X		}
X		(void) fflush(stdout);
X		reply(214, "Direct comments to ftp-bugs@%s.", hostname);
X		return;
X	}
X	upper(s);
X	c = lookup(s);
X	if (c == (struct tab *)0) {
X		reply(502, "Unknown command %s.", s);
X		return;
X	}
X	if (c->implemented)
X		reply(214, "Syntax: %s %s", c->name, c->help);
X	else
X		reply(214, "%-*s\t%s; unimplemented.", width, c->name, c->help);
X}
END-of-ftpcmd.y
echo x - ftpd.c
sed 's/^X//' >ftpd.c << 'END-of-ftpd.c'
X/*
X * Copyright (c) 1985 Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xchar copyright[] =
X"@(#) Copyright (c) 1985 Regents of the University of California.\n\
X All rights reserved.\n";
X#endif /* not lint */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)ftpd.c	5.16 (Berkeley) 10/30/88";
X#endif /* not lint */
X
X/*
X * FTP server.
X */
X#include <sys/param.h>
X#include <sys/stat.h>
X#include <sys/ioctl.h>
X#include <sys/socket.h>
X#include <sys/file.h>
X#include <sys/wait.h>
X
X#include <netinet/in.h>
X
X#include <arpa/ftp.h>
X#include <arpa/inet.h>
X#include <arpa/telnet.h>
X
X#include <stdio.h>
X#include <signal.h>
X#include <pwd.h>
X#include <setjmp.h>
X#include <netdb.h>
X#include <errno.h>
X#include <strings.h>
X#include <syslog.h>
X
X/*
X * File containing login names
X * NOT to be used on this machine.
X * Commonly used to disallow uucp.
X */
X#define	FTPUSERS	"/etc/ftpusers"
X
Xextern	int errno;
Xextern	char *sys_errlist[];
Xextern	char *crypt();
Xextern	char version[];
Xextern	char *home;		/* pointer to home directory for glob */
Xextern	FILE *popen(), *fopen(), *freopen();
Xextern	int  pclose(), fclose();
Xextern	char *getline();
Xextern	char cbuf[];
X
Xstruct	sockaddr_in ctrl_addr;
Xstruct	sockaddr_in data_source;
Xstruct	sockaddr_in data_dest;
Xstruct	sockaddr_in his_addr;
X
Xint	data;
Xjmp_buf	errcatch, urgcatch;
Xint	logged_in;
Xstruct	passwd *pw;
Xint	debug;
Xint	timeout = 900;    /* timeout after 15 minutes of inactivity */
Xint	logging;
Xint	guest;
Xint	wtmp;
Xint	type;
Xint	form;
Xint	stru;			/* avoid C keyword */
Xint	mode;
Xint	usedefault = 1;		/* for data transfers */
Xint	pdata;			/* for passive mode */
Xint	unique;
Xint	transflag;
Xchar	tmpline[7];
Xchar	hostname[32];
Xchar	remotehost[32];
X
X/*
X * Timeout intervals for retrying connections
X * to hosts that don't accept PORT cmds.  This
X * is a kludge, but given the problems with TCP...
X */
X#define	SWAITMAX	90	/* wait at most 90 seconds */
X#define	SWAITINT	5	/* interval between retries */
X
Xint	swaitmax = SWAITMAX;
Xint	swaitint = SWAITINT;
X
Xint	lostconn();
Xint	myoob();
XFILE	*getdatasock(), *dataconn();
X
Xmain(argc, argv)
X	int argc;
X	char *argv[];
X{
X	int addrlen, on = 1;
X	long pgid;
X	char *cp;
X
X	addrlen = sizeof (his_addr);
X	if (getpeername(0, &his_addr, &addrlen) < 0) {
X		syslog(LOG_ERR, "getpeername (%s): %m",argv[0]);
X		exit(1);
X	}
X	addrlen = sizeof (ctrl_addr);
X	if (getsockname(0, (char *) &ctrl_addr, &addrlen) < 0) {
X		syslog(LOG_ERR, "getsockname (%s): %m",argv[0]);
X		exit(1);
X	}
X	data_source.sin_port = htons(ntohs(ctrl_addr.sin_port) - 1);
X	debug = 0;
X	openlog("ftpd", LOG_PID, LOG_DAEMON);
X	argc--, argv++;
X	while (argc > 0 && *argv[0] == '-') {
X		for (cp = &argv[0][1]; *cp; cp++) switch (*cp) {
X
X		case 'v':
X			debug = 1;
X			break;
X
X		case 'd':
X			debug = 1;
X			break;
X
X		case 'l':
X			logging = 1;
X			break;
X
X		case 't':
X			timeout = atoi(++cp);
X			goto nextopt;
X			break;
X
X		default:
X			fprintf(stderr, "ftpd: Unknown flag -%c ignored.\n",
X			     *cp);
X			break;
X		}
Xnextopt:
X		argc--, argv++;
X	}
X	(void) freopen("/dev/null", "w", stderr);
X	(void) signal(SIGPIPE, lostconn);
X	(void) signal(SIGCHLD, SIG_IGN);
X	if ((int)signal(SIGURG, myoob) < 0)
X		syslog(LOG_ERR, "signal: %m");
X
X	/* handle urgent data inline */
X#ifdef SO_OOBINLINE
X	if (setsockopt(0, SOL_SOCKET, SO_OOBINLINE, (char *)&on, sizeof(on)) < 0) {
X		syslog(LOG_ERR, "setsockopt: %m");
X	}
X#endif SO_OOBINLINE
X	pgid = getpid();
X	if (ioctl(fileno(stdin), SIOCSPGRP, (char *) &pgid) < 0) {
X		syslog(LOG_ERR, "ioctl: %m");
X	}
X	dolog(&his_addr);
X	/* do telnet option negotiation here */
X	/*
X	 * Set up default state
X	 */
X	logged_in = 0;
X	data = -1;
X	type = TYPE_A;
X	form = FORM_N;
X	stru = STRU_F;
X	mode = MODE_S;
X	tmpline[0] = '\0';
X	(void) gethostname(hostname, sizeof (hostname));
X	reply(220, "%s FTP server (%s) ready.",
X		hostname, version);
X	for (;;) {
X		(void) setjmp(errcatch);
X		(void) yyparse();
X	}
X}
X
Xlostconn()
X{
X
X	if (debug)
X		syslog(LOG_DEBUG, "lost connection");
X	dologout(-1);
X}
X
Xstatic char ttyline[20];
X
X/*
X * Helper function for sgetpwnam().
X */
Xchar *
Xsgetsave(s)
X	char *s;
X{
X#ifdef notdef
X	char *new = strdup(s);
X#else
X	char *malloc();
X	char *new = malloc((unsigned) strlen(s) + 1);
X#endif
X	
X	if (new == NULL) {
X		reply(553, "Local resource failure");
X		dologout(1);
X	}
X#ifndef notdef
X	(void) strcpy(new, s);
X#endif
X	return (new);
X}
X
X/*
X * Save the result of a getpwnam.  Used for USER command, since
X * the data returned must not be clobbered by any other command
X * (e.g., globbing).
X */
Xstruct passwd *
Xsgetpwnam(name)
X	char *name;
X{
X	static struct passwd save;
X	register struct passwd *p;
X	char *sgetsave();
X
X	if ((p = getpwnam(name)) == NULL)
X		return (p);
X	if (save.pw_name) {
X		free(save.pw_name);
X		free(save.pw_passwd);
X		free(save.pw_comment);
X		free(save.pw_gecos);
X		free(save.pw_dir);
X		free(save.pw_shell);
X	}
X	save = *p;
X	save.pw_name = sgetsave(p->pw_name);
X	save.pw_passwd = sgetsave(p->pw_passwd);
X	save.pw_comment = sgetsave(p->pw_comment);
X	save.pw_gecos = sgetsave(p->pw_gecos);
X	save.pw_dir = sgetsave(p->pw_dir);
X	save.pw_shell = sgetsave(p->pw_shell);
X	return (&save);
X}
X
Xpass(passwd)
X	char *passwd;
X{
X	char *xpasswd;
X
X	if (logged_in || pw == NULL) {
X		reply(503, "Login with USER first.");
X		return;
X	}
X	if (!guest) {		/* "ftp" is only account allowed no password */
X		xpasswd = crypt(passwd, pw->pw_passwd);
X		/* The strcmp does not catch null passwords! */
X		if (*pw->pw_passwd == '\0' || strcmp(xpasswd, pw->pw_passwd)) {
X			reply(530, "Login incorrect.");
X			pw = NULL;
X			return;
X		}
X	}
X	setegid(pw->pw_gid);
X	initgroups(pw->pw_name, pw->pw_gid);
X	if (chdir(pw->pw_dir)) {
X		reply(530, "User %s: can't change directory to %s.",
X			pw->pw_name, pw->pw_dir);
X		goto bad;
X	}
X
X	/* grab wtmp before chroot */
X	wtmp = open("/usr/adm/wtmp", O_WRONLY|O_APPEND);
X	if (guest && chroot(pw->pw_dir) < 0) {
X		reply(550, "Can't set guest privileges.");
X		if (wtmp >= 0) {
X			(void) close(wtmp);
X			wtmp = -1;
X		}
X		goto bad;
X	}
X	if (!guest)
X		reply(230, "User %s logged in.", pw->pw_name);
X	else
X		reply(230, "Guest login ok, access restrictions apply.");
X	logged_in = 1;
X	(void)sprintf(ttyline, "ftp%d", getpid());
X	logwtmp(ttyline, pw->pw_name, remotehost);
X	seteuid(pw->pw_uid);
X	home = pw->pw_dir;		/* home dir for globbing */
X	return;
Xbad:
X	seteuid(0);
X	pw = NULL;
X}
X
Xretrieve(cmd, name)
X	char *cmd, *name;
X{
X	FILE *fin, *dout;
X	struct stat st;
X	int (*closefunc)(), tmp;
X
X	if (cmd == 0) {
X#ifdef notdef
X		/* no remote command execution -- it's a security hole */
X		if (*name == '|')
X			fin = popen(name + 1, "r"), closefunc = pclose;
X		else
X#endif
X			fin = fopen(name, "r"), closefunc = fclose;
X	} else {
X		char line[BUFSIZ];
X
X		(void) sprintf(line, cmd, name), name = line;
X		fin = popen(line, "r"), closefunc = pclose;
X	}
X	if (fin == NULL) {
X		if (errno != 0)
X			reply(550, "%s: %s.", name, sys_errlist[errno]);
X		return;
X	}
X	st.st_size = 0;
X	if (cmd == 0 &&
X	    (stat(name, &st) < 0 || (st.st_mode&S_IFMT) != S_IFREG)) {
X		reply(550, "%s: not a plain file.", name);
X		goto done;
X	}
X	dout = dataconn(name, st.st_size, "w");
X	if (dout == NULL)
X		goto done;
X	if ((tmp = send_data(fin, dout)) > 0 || ferror(dout) > 0) {
X		reply(550, "%s: %s.", name, sys_errlist[errno]);
X	}
X	else if (tmp == 0) {
X		reply(226, "Transfer complete.");
X	}
X	(void) fclose(dout);
X	data = -1;
X	pdata = -1;
Xdone:
X	(*closefunc)(fin);
X}
X
Xstore(name, mode)
X	char *name, *mode;
X{
X	FILE *fout, *din;
X	int (*closefunc)(), dochown = 0, tmp;
X	char *gunique(), *local;
X
X#ifdef notdef
X	/* no remote command execution -- it's a security hole */
X	if (name[0] == '|')
X		fout = popen(&name[1], "w"), closefunc = pclose;
X	else
X#endif
X	{
X		struct stat st;
X
X		local = name;
X		if (stat(name, &st) < 0) {
X			dochown++;
X		}
X		else if (unique) {
X			if ((local = gunique(name)) == NULL) {
X				return;
X			}
X			dochown++;
X		}
X		fout = fopen(local, mode), closefunc = fclose;
X	}
X	if (fout == NULL) {
X		reply(553, "%s: %s.", local, sys_errlist[errno]);
X		return;
X	}
X	din = dataconn(local, (off_t)-1, "r");
X	if (din == NULL)
X		goto done;
X	if ((tmp = receive_data(din, fout)) > 0 || ferror(fout) > 0) {
X		reply(552, "%s: %s.", local, sys_errlist[errno]);
X	}
X	else if (tmp == 0 && !unique) {
X		reply(226, "Transfer complete.");
X	}
X	else if (tmp == 0 && unique) {
X		reply(226, "Transfer complete (unique file name:%s).", local);
X	}
X	(void) fclose(din);
X	data = -1;
X	pdata = -1;
Xdone:
X	if (dochown)
X		(void) chown(local, pw->pw_uid, -1);
X	(*closefunc)(fout);
X}
X
XFILE *
Xgetdatasock(mode)
X	char *mode;
X{
X	int s, on = 1;
X
X	if (data >= 0)
X		return (fdopen(data, mode));
X	s = socket(AF_INET, SOCK_STREAM, 0);
X	if (s < 0)
X		return (NULL);
X	seteuid(0);
X	if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *) &on, sizeof (on)) < 0)
X		goto bad;
X	/* anchor socket to avoid multi-homing problems */
X	data_source.sin_family = AF_INET;
X	data_source.sin_addr = ctrl_addr.sin_addr;
X	if (bind(s, &data_source, sizeof (data_source)) < 0)
X		goto bad;
X	seteuid(pw->pw_uid);
X	return (fdopen(s, mode));
Xbad:
X	seteuid(pw->pw_uid);
X	(void) close(s);
X	return (NULL);
X}
X
XFILE *
Xdataconn(name, size, mode)
X	char *name;
X	off_t size;
X	char *mode;
X{
X	char sizebuf[32];
X	FILE *file;
X	int retry = 0;
X
X	if (size >= 0)
X		(void) sprintf (sizebuf, " (%ld bytes)", size);
X	else
X		(void) strcpy(sizebuf, "");
X	if (pdata > 0) {
X		struct sockaddr_in from;
X		int s, fromlen = sizeof(from);
X
X		s = accept(pdata, &from, &fromlen);
X		if (s < 0) {
X			reply(425, "Can't open data connection.");
X			(void) close(pdata);
X			pdata = -1;
X			return(NULL);
X		}
X		(void) close(pdata);
X		pdata = s;
X		reply(150, "Opening data connection for %s (%s mode)%s.",
X		     name, type == TYPE_A ? "ascii" : "binary", sizebuf);
X		return(fdopen(pdata, mode));
X	}
X	if (data >= 0) {
X		reply(125, "Using existing data connection for %s%s.",
X		    name, sizebuf);
X		usedefault = 1;
X		return (fdopen(data, mode));
X	}
X	if (usedefault)
X		data_dest = his_addr;
X	usedefault = 1;
X	file = getdatasock(mode);
X	if (file == NULL) {
X		reply(425, "Can't create data socket (%s,%d): %s.",
X		    inet_ntoa(data_source.sin_addr),
X		    ntohs(data_source.sin_port),
X		    sys_errlist[errno]);
X		return (NULL);
X	}
X	data = fileno(file);
X	while (connect(data, &data_dest, sizeof (data_dest)) < 0) {
X		if (errno == EADDRINUSE && retry < swaitmax) {
X			sleep((unsigned) swaitint);
X			retry += swaitint;
X			continue;
X		}
X		reply(425, "Can't build data connection: %s.",
X		    sys_errlist[errno]);
X		(void) fclose(file);
X		data = -1;
X		return (NULL);
X	}
X	reply(150, "Opening data connection for %s (%s mode)%s.",
X	    name, type == TYPE_A ? "ascii" : "binary", sizebuf);
X	return (file);
X}
X
X/*
X * Tranfer the contents of "instr" to
X * "outstr" peer using the appropriate
X * encapulation of the date subject
X * to Mode, Structure, and Type.
X *
X * NB: Form isn't handled.
X */
Xsend_data(instr, outstr)
X	FILE *instr, *outstr;
X{
X	register int c;
X	int netfd, filefd, cnt;
X	char buf[BUFSIZ];
X
X	transflag++;
X	if (setjmp(urgcatch)) {
X		transflag = 0;
X		return(-1);
X	}
X	switch (type) {
X
X	case TYPE_A:
X		while ((c = getc(instr)) != EOF) {
X			if (c == '\n') {
X				if (ferror (outstr)) {
X					transflag = 0;
X					return (1);
X				}
X				(void) putc('\r', outstr);
X			}
X			(void) putc(c, outstr);
X		/*	if (c == '\r')			*/
X		/*		putc ('\0', outstr);	*/
X		}
X		transflag = 0;
X		if (ferror (instr) || ferror (outstr)) {
X			return (1);
X		}
X		return (0);
X		
X	case TYPE_I:
X	case TYPE_L:
X		netfd = fileno(outstr);
X		filefd = fileno(instr);
X
X		while ((cnt = read(filefd, buf, sizeof (buf))) > 0) {
X			if (write(netfd, buf, cnt) < 0) {
X				transflag = 0;
X				return (1);
X			}
X		}
X		transflag = 0;
X		return (cnt < 0);
X	}
X	reply(550, "Unimplemented TYPE %d in send_data", type);
X	transflag = 0;
X	return (-1);
X}
X
X/*
X * Transfer data from peer to
X * "outstr" using the appropriate
X * encapulation of the data subject
X * to Mode, Structure, and Type.
X *
X * N.B.: Form isn't handled.
X */
Xreceive_data(instr, outstr)
X	FILE *instr, *outstr;
X{
X	register int c;
X	int cnt;
X	char buf[BUFSIZ];
X
X
X	transflag++;
X	if (setjmp(urgcatch)) {
X		transflag = 0;
X		return(-1);
X	}
X	switch (type) {
X
X	case TYPE_I:
X	case TYPE_L:
X		while ((cnt = read(fileno(instr), buf, sizeof buf)) > 0) {
X			if (write(fileno(outstr), buf, cnt) < 0) {
X				transflag = 0;
X				return (1);
X			}
X		}
X		transflag = 0;
X		return (cnt < 0);
X
X	case TYPE_E:
X		reply(553, "TYPE E not implemented.");
X		transflag = 0;
X		return (-1);
X
X	case TYPE_A:
X		while ((c = getc(instr)) != EOF) {
X			while (c == '\r') {
X				if (ferror (outstr)) {
X					transflag = 0;
X					return (1);
X				}
X				if ((c = getc(instr)) != '\n')
X					(void) putc ('\r', outstr);
X			/*	if (c == '\0')			*/
X			/*		continue;		*/
X			}
X			(void) putc (c, outstr);
X		}
X		transflag = 0;
X		if (ferror (instr) || ferror (outstr))
X			return (1);
X		return (0);
X	}
X	transflag = 0;
X	fatal("Unknown type in receive_data.");
X	/*NOTREACHED*/
X}
X
Xfatal(s)
X	char *s;
X{
X	reply(451, "Error in server: %s\n", s);
X	reply(221, "Closing connection due to server error.");
X	dologout(0);
X}
X
Xreply(n, s, p0, p1, p2, p3, p4)
X	int n;
X	char *s;
X{
X
X	printf("%d ", n);
X	printf(s, p0, p1, p2, p3, p4);
X	printf("\r\n");
X	(void) fflush(stdout);
X	if (debug) {
X		syslog(LOG_DEBUG, "<--- %d ", n);
X		syslog(LOG_DEBUG, s, p0, p1, p2, p3, p4);
X	}
X}
X
Xlreply(n, s, p0, p1, p2, p3, p4)
X	int n;
X	char *s;
X{
X	printf("%d-", n);
X	printf(s, p0, p1, p2, p3, p4);
X	printf("\r\n");
X	(void) fflush(stdout);
X	if (debug) {
X		syslog(LOG_DEBUG, "<--- %d- ", n);
X		syslog(LOG_DEBUG, s, p0, p1, p2, p3, p4);
X	}
X}
X
Xack(s)
X	char *s;
X{
X	reply(250, "%s command successful.", s);
X}
X
Xnack(s)
X	char *s;
X{
X	reply(502, "%s command not implemented.", s);
X}
X
Xyyerror(s)
X	char *s;
X{
X	char *cp;
X
X	cp = index(cbuf,'\n');
X	*cp = '\0';
X	reply(500, "'%s': command not understood.",cbuf);
X}
X
Xdelete(name)
X	char *name;
X{
X	struct stat st;
X
X	if (stat(name, &st) < 0) {
X		reply(550, "%s: %s.", name, sys_errlist[errno]);
X		return;
X	}
X	if ((st.st_mode&S_IFMT) == S_IFDIR) {
X		if (rmdir(name) < 0) {
X			reply(550, "%s: %s.", name, sys_errlist[errno]);
X			return;
X		}
X		goto done;
X	}
X	if (unlink(name) < 0) {
X		reply(550, "%s: %s.", name, sys_errlist[errno]);
X		return;
X	}
Xdone:
X	ack("DELE");
X}
X
Xcwd(path)
X	char *path;
X{
X
X	if (chdir(path) < 0) {
X		reply(550, "%s: %s.", path, sys_errlist[errno]);
X		return;
X	}
X	ack("CWD");
X}
X
Xmakedir(name)
X	char *name;
X{
X	struct stat st;
X	int dochown = stat(name, &st) < 0;
X	
X	if (mkdir(name, 0777) < 0) {
X		reply(550, "%s: %s.", name, sys_errlist[errno]);
X		return;
X	}
X	if (dochown)
X		(void) chown(name, pw->pw_uid, -1);
X	reply(257, "MKD command successful.");
X}
X
Xremovedir(name)
X	char *name;
X{
X
X	if (rmdir(name) < 0) {
X		reply(550, "%s: %s.", name, sys_errlist[errno]);
X		return;
X	}
X	ack("RMD");
X}
X
Xpwd()
X{
X	char path[MAXPATHLEN + 1];
X
X	if (getwd(path) == NULL) {
X		reply(550, "%s.", path);
X		return;
X	}
X	reply(257, "\"%s\" is current directory.", path);
X}
X
Xchar *
Xrenamefrom(name)
X	char *name;
X{
X	struct stat st;
X
X	if (stat(name, &st) < 0) {
X		reply(550, "%s: %s.", name, sys_errlist[errno]);
X		return ((char *)0);
X	}
X	reply(350, "File exists, ready for destination name");
X	return (name);
X}
X
Xrenamecmd(from, to)
X	char *from, *to;
X{
X
X	if (rename(from, to) < 0) {
X		reply(550, "rename: %s.", sys_errlist[errno]);
X		return;
X	}
X	ack("RNTO");
X}
X
Xdolog(sin)
X	struct sockaddr_in *sin;
X{
X	struct hostent *hp = gethostbyaddr(&sin->sin_addr,
X		sizeof (struct in_addr), AF_INET);
X	time_t t;
X	extern char *ctime();
X
X	if (hp) {
X		(void) strncpy(remotehost, hp->h_name, sizeof (remotehost));
X		endhostent();
X	} else
X		(void) strncpy(remotehost, inet_ntoa(sin->sin_addr),
X		    sizeof (remotehost));
X	if (!logging)
X		return;
X	t = time((time_t *) 0);
X	syslog(LOG_INFO,"FTPD: connection from %s at %s", remotehost, ctime(&t));
X}
X
X/*
X * Record logout in wtmp file
X * and exit with supplied status.
X */
Xdologout(status)
X	int status;
X{
X	if (logged_in) {
X		(void) seteuid(0);
X		logwtmp(ttyline, "", "");
X	}
X	/* beware of flushing buffers after a SIGPIPE */
X	_exit(status);
X}
X
X/*
X * Check user requesting login priviledges.
X * Disallow anyone who does not have a standard
X * shell returned by getusershell() (/etc/shells).
X * Disallow anyone mentioned in the file FTPUSERS
X * to allow people such as uucp to be avoided.
X */
Xcheckuser(name)
X	register char *name;
X{
X	register char *cp;
X	FILE *fd;
X	struct passwd *p;
X	char *shell;
X	int found = 0;
X	char line[BUFSIZ], *index(), *getusershell();
X
X	if ((p = getpwnam(name)) == NULL)
X		return (0);
X	if ((shell = p->pw_shell) == NULL || *shell == 0)
X		shell = "/bin/sh";
X	while ((cp = getusershell()) != NULL)
X		if (strcmp(cp, shell) == 0)
X			break;
X	endusershell();
X	if (cp == NULL)
X		return (0);
X	if ((fd = fopen(FTPUSERS, "r")) == NULL)
X		return (1);
X	while (fgets(line, sizeof (line), fd) != NULL) {
X		if ((cp = index(line, '\n')) != NULL)
X			*cp = '\0';
X		if (strcmp(line, name) == 0) {
X			found++;
X			break;
X		}
X	}
X	(void) fclose(fd);
X	return (!found);
X}
X
Xmyoob()
X{
X	char *cp;
X
X	/* only process if transfer occurring */
X	if (!transflag) {
X		return;
X	}
X	cp = tmpline;
X	if (getline(cp, 7, stdin) == NULL) {
X		reply(221, "You could at least say goodby.");
X		dologout(0);
X	}
X	upper(cp);
X	if (strcmp(cp, "ABOR\r\n"))
X		return;
X	tmpline[0] = '\0';
X	reply(426,"Transfer aborted. Data connection closed.");
X	reply(226,"Abort successful");
X	longjmp(urgcatch, 1);
X}
X
X/*
X * Note: The 530 reply codes could be 4xx codes, except nothing is
X * given in the state tables except 421 which implies an exit.  (RFC959)
X */
Xpassive()
X{
X	int len;
X	struct sockaddr_in tmp;
X	register char *p, *a;
X
X	pdata = socket(AF_INET, SOCK_STREAM, 0);
X	if (pdata < 0) {
X		reply(530, "Can't open passive connection");
X		return;
X	}
X	tmp = ctrl_addr;
X	tmp.sin_port = 0;
X	seteuid(0);
X	if (bind(pdata, (struct sockaddr *) &tmp, sizeof(tmp)) < 0) {
X		seteuid(pw->pw_uid);
X		(void) close(pdata);
X		pdata = -1;
X		reply(530, "Can't open passive connection");
X		return;
X	}
X	seteuid(pw->pw_uid);
X	len = sizeof(tmp);
X	if (getsockname(pdata, (char *) &tmp, &len) < 0) {
X		(void) close(pdata);
X		pdata = -1;
X		reply(530, "Can't open passive connection");
X		return;
X	}
X	if (listen(pdata, 1) < 0) {
X		(void) close(pdata);
X		pdata = -1;
X		reply(530, "Can't open passive connection");
X		return;
X	}
X	a = (char *) &tmp.sin_addr;
X	p = (char *) &tmp.sin_port;
X
X#define UC(b) (((int) b) & 0xff)
X
X	reply(227, "Entering Passive Mode (%d,%d,%d,%d,%d,%d)", UC(a[0]),
X		UC(a[1]), UC(a[2]), UC(a[3]), UC(p[0]), UC(p[1]));
X}
X
Xchar *
Xgunique(local)
X	char *local;
X{
X	static char new[MAXPATHLEN];
X	char *cp = rindex(local, '/');
X	int d, count=0;
X	char ext = '1';
X
X	if (cp) {
X		*cp = '\0';
X	}
X	d = access(cp ? local : ".", 2);
X	if (cp) {
X		*cp = '/';
X	}
X	if (d < 0) {
X		syslog(LOG_ERR, "%s: %m", local);
X		return((char *) 0);
X	}
X	(void) strcpy(new, local);
X	cp = new + strlen(new);
X	*cp++ = '.';
X	while (!d) {
X		if (++count == 100) {
X			reply(452, "Unique file name not cannot be created.");
X			return((char *) 0);
X		}
X		*cp++ = ext;
X		*cp = '\0';
X		if (ext == '9') {
X			ext = '0';
X		}
X		else {
X			ext++;
X		}
X		if ((d = access(new, 0)) < 0) {
X			break;
X		}
X		if (ext != '0') {
X			cp--;
X		}
X		else if (*(cp - 2) == '.') {
X			*(cp - 1) = '1';
X		}
X		else {
X			*(cp - 2) = *(cp - 2) + 1;
X			cp--;
X		}
X	}
X	return(new);
X}
END-of-ftpd.c
echo x - glob.c
sed 's/^X//' >glob.c << 'END-of-glob.c'
X/*
X * Copyright (c) 1980 Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)glob.c	5.4 (Berkeley) 6/29/88";
X#endif /* not lint */
X
X/*
X * C-shell glob for random programs.
X */
X
X#include <sys/param.h>
X#include <sys/stat.h>
X#include <sys/dir.h>
X
X#include <stdio.h>
X#include <errno.h>
X#include <pwd.h>
X
X#define	QUOTE 0200
X#define	TRIM 0177
X#define	eq(a,b)		(strcmp(a, b)==0)
X#define	GAVSIZ		(NCARGS/6)
X#define	isdir(d)	((d.st_mode & S_IFMT) == S_IFDIR)
X
Xstatic	char **gargv;		/* Pointer to the (stack) arglist */
Xstatic	short gargc;		/* Number args in gargv */
Xstatic	short gnleft;
Xstatic	short gflag;
Xstatic	int tglob();
Xchar	**glob();
Xchar	*globerr;
Xchar	*home;
Xstruct	passwd *getpwnam();
Xextern	int errno;
Xstatic	char *strspl(), *strend();
Xchar	*malloc(), *strcpy(), *strcat();
Xchar	**copyblk();
X
Xstatic	int globcnt;
X
Xchar	*globchars = "`{[*?";
X
Xstatic	char *gpath, *gpathp, *lastgpathp;
Xstatic	int globbed;
Xstatic	char *entp;
Xstatic	char **sortbas;
X
Xchar **
Xglob(v)
X	register char *v;
X{
X	char agpath[BUFSIZ];
X	char *agargv[GAVSIZ];
X	char *vv[2];
X	vv[0] = v;
X	vv[1] = 0;
X	gflag = 0;
X	rscan(vv, tglob);
X	if (gflag == 0)
X		return (copyblk(vv));
X
X	globerr = 0;
X	gpath = agpath; gpathp = gpath; *gpathp = 0;
X	lastgpathp = &gpath[sizeof agpath - 2];
X	ginit(agargv); globcnt = 0;
X	collect(v);
X	if (globcnt == 0 && (gflag&1)) {
X		blkfree(gargv), gargv = 0;
X		return (0);
X	} else
X		return (gargv = copyblk(gargv));
X}
X
Xstatic
Xginit(agargv)
X	char **agargv;
X{
X
X	agargv[0] = 0; gargv = agargv; sortbas = agargv; gargc = 0;
X	gnleft = NCARGS - 4;
X}
X
Xstatic
Xcollect(as)
X	register char *as;
X{
X	if (eq(as, "{") || eq(as, "{}")) {
X		Gcat(as, "");
X		sort();
X	} else
X		acollect(as);
X}
X
Xstatic
Xacollect(as)
X	register char *as;
X{
X	register int ogargc = gargc;
X
X	gpathp = gpath; *gpathp = 0; globbed = 0;
X	expand(as);
X	if (gargc != ogargc)
X		sort();
X}
X
Xstatic
Xsort()
X{
X	register char **p1, **p2, *c;
X	char **Gvp = &gargv[gargc];
X
X	p1 = sortbas;
X	while (p1 < Gvp-1) {
X		p2 = p1;
X		while (++p2 < Gvp)
X			if (strcmp(*p1, *p2) > 0)
X				c = *p1, *p1 = *p2, *p2 = c;
X		p1++;
X	}
X	sortbas = Gvp;
X}
X
Xstatic
Xexpand(as)
X	char *as;
X{
X	register char *cs;
X	register char *sgpathp, *oldcs;
X	struct stat stb;
X
X	sgpathp = gpathp;
X	cs = as;
X	if (*cs == '~' && gpathp == gpath) {
X		addpath('~');
X		for (cs++; letter(*cs) || digit(*cs) || *cs == '-';)
X			addpath(*cs++);
X		if (!*cs || *cs == '/') {
X			if (gpathp != gpath + 1) {
X				*gpathp = 0;
X				if (gethdir(gpath + 1))
X					globerr = "Unknown user name after ~";
X				(void) strcpy(gpath, gpath + 1);
X			} else
X				(void) strcpy(gpath, home);
X			gpathp = strend(gpath);
X		}
X	}
X	while (!any(*cs, globchars)) {
X		if (*cs == 0) {
X			if (!globbed)
X				Gcat(gpath, "");
X			else if (stat(gpath, &stb) >= 0) {
X				Gcat(gpath, "");
X				globcnt++;
X			}
X			goto endit;
X		}
X		addpath(*cs++);
X	}
X	oldcs = cs;
X	while (cs > as && *cs != '/')
X		cs--, gpathp--;
X	if (*cs == '/')
X		cs++, gpathp++;
X	*gpathp = 0;
X	if (*oldcs == '{') {
X		(void) execbrc(cs, ((char *)0));
X		return;
X	}
X	matchdir(cs);
Xendit:
X	gpathp = sgpathp;
X	*gpathp = 0;
X}
X
Xstatic
Xmatchdir(pattern)
X	char *pattern;
X{
X	struct stat stb;
X	register struct direct *dp;
X	DIR *dirp;
X
X	dirp = opendir(gpath);
X	if (dirp == NULL) {
X		if (globbed)
X			return;
X		goto patherr2;
X	}
X	if (fstat(dirp->dd_fd, &stb) < 0)
X		goto patherr1;
X	if (!isdir(stb)) {
X		errno = ENOTDIR;
X		goto patherr1;
X	}
X	while ((dp = readdir(dirp)) != NULL) {
X		if (dp->d_ino == 0)
X			continue;
X		if (match(dp->d_name, pattern)) {
X			Gcat(gpath, dp->d_name);
X			globcnt++;
X		}
X	}
X	closedir(dirp);
X	return;
X
Xpatherr1:
X	closedir(dirp);
Xpatherr2:
X	globerr = "Bad directory components";
X}
X
Xstatic
Xexecbrc(p, s)
X	char *p, *s;
X{
X	char restbuf[BUFSIZ + 2];
X	register char *pe, *pm, *pl;
X	int brclev = 0;
X	char *lm, savec, *sgpathp;
X
X	for (lm = restbuf; *p != '{'; *lm++ = *p++)
X		continue;
X	for (pe = ++p; *pe; pe++)
X	switch (*pe) {
X
X	case '{':
X		brclev++;
X		continue;
X
X	case '}':
X		if (brclev == 0)
X			goto pend;
X		brclev--;
X		continue;
X
X	case '[':
X		for (pe++; *pe && *pe != ']'; pe++)
X			continue;
X		continue;
X	}
Xpend:
X	brclev = 0;
X	for (pl = pm = p; pm <= pe; pm++)
X	switch (*pm & (QUOTE|TRIM)) {
X
X	case '{':
X		brclev++;
X		continue;
X
X	case '}':
X		if (brclev) {
X			brclev--;
X			continue;
X		}
X		goto doit;
X
X	case ','|QUOTE:
X	case ',':
X		if (brclev)
X			continue;
Xdoit:
X		savec = *pm;
X		*pm = 0;
X		(void) strcpy(lm, pl);
X		(void) strcat(restbuf, pe + 1);
X		*pm = savec;
X		if (s == 0) {
X			sgpathp = gpathp;
X			expand(restbuf);
X			gpathp = sgpathp;
X			*gpathp = 0;
X		} else if (amatch(s, restbuf))
X			return (1);
X		sort();
X		pl = pm + 1;
X		if (brclev)
X			return (0);
X		continue;
X
X	case '[':
X		for (pm++; *pm && *pm != ']'; pm++)
X			continue;
X		if (!*pm)
X			pm--;
X		continue;
X	}
X	if (brclev)
X		goto doit;
X	return (0);
X}
X
Xstatic
Xmatch(s, p)
X	char *s, *p;
X{
X	register int c;
X	register char *sentp;
X	char sglobbed = globbed;
X
X	if (*s == '.' && *p != '.')
X		return (0);
X	sentp = entp;
X	entp = s;
X	c = amatch(s, p);
X	entp = sentp;
X	globbed = sglobbed;
X	return (c);
X}
X
Xstatic
Xamatch(s, p)
X	register char *s, *p;
X{
X	register int scc;
X	int ok, lc;
X	char *sgpathp;
X	struct stat stb;
X	int c, cc;
X
X	globbed = 1;
X	for (;;) {
X		scc = *s++ & TRIM;
X		switch (c = *p++) {
X
X		case '{':
X			return (execbrc(p - 1, s - 1));
X
X		case '[':
X			ok = 0;
X			lc = 077777;
X			while (cc = *p++) {
X				if (cc == ']') {
X					if (ok)
X						break;
X					return (0);
X				}
X				if (cc == '-') {
X					if (lc <= scc && scc <= *p++)
X						ok++;
X				} else
X					if (scc == (lc = cc))
X						ok++;
X			}
X			if (cc == 0)
X				if (ok)
X					p--;
X				else
X					return 0;
X			continue;
X
X		case '*':
X			if (!*p)
X				return (1);
X			if (*p == '/') {
X				p++;
X				goto slash;
X			}
X			s--;
X			do {
X				if (amatch(s, p))
X					return (1);
X			} while (*s++);
X			return (0);
X
X		case 0:
X			return (scc == 0);
X
X		default:
X			if (c != scc)
X				return (0);
X			continue;
X
X		case '?':
X			if (scc == 0)
X				return (0);
X			continue;
X
X		case '/':
X			if (scc)
X				return (0);
Xslash:
X			s = entp;
X			sgpathp = gpathp;
X			while (*s)
X				addpath(*s++);
X			addpath('/');
X			if (stat(gpath, &stb) == 0 && isdir(stb))
X				if (*p == 0) {
X					Gcat(gpath, "");
X					globcnt++;
X				} else
X					expand(p);
X			gpathp = sgpathp;
X			*gpathp = 0;
X			return (0);
X		}
X	}
X}
X
Xstatic
XGmatch(s, p)
X	register char *s, *p;
X{
X	register int scc;
X	int ok, lc;
X	int c, cc;
X
X	for (;;) {
X		scc = *s++ & TRIM;
X		switch (c = *p++) {
X
X		case '[':
X			ok = 0;
X			lc = 077777;
X			while (cc = *p++) {
X				if (cc == ']') {
X					if (ok)
X						break;
X					return (0);
X				}
X				if (cc == '-') {
X					if (lc <= scc && scc <= *p++)
X						ok++;
X				} else
X					if (scc == (lc = cc))
X						ok++;
X			}
X			if (cc == 0)
X				if (ok)
X					p--;
X				else
X					return 0;
X			continue;
X
X		case '*':
X			if (!*p)
X				return (1);
X			for (s--; *s; s++)
X				if (Gmatch(s, p))
X					return (1);
X			return (0);
X
X		case 0:
X			return (scc == 0);
X
X		default:
X			if ((c & TRIM) != scc)
X				return (0);
X			continue;
X
X		case '?':
X			if (scc == 0)
X				return (0);
X			continue;
X
X		}
X	}
X}
X
Xstatic
XGcat(s1, s2)
X	register char *s1, *s2;
X{
X	register int len = strlen(s1) + strlen(s2) + 1;
X
X	if (len >= gnleft || gargc >= GAVSIZ - 1)
X		globerr = "Arguments too long";
X	else {
X		gargc++;
X		gnleft -= len;
X		gargv[gargc] = 0;
X		gargv[gargc - 1] = strspl(s1, s2);
X	}
X}
X
Xstatic
Xaddpath(c)
X	char c;
X{
X
X	if (gpathp >= lastgpathp)
X		globerr = "Pathname too long";
X	else {
X		*gpathp++ = c;
X		*gpathp = 0;
X	}
X}
X
Xstatic
Xrscan(t, f)
X	register char **t;
X	int (*f)();
X{
X	register char *p, c;
X
X	while (p = *t++) {
X		if (f == tglob)
X			if (*p == '~')
X				gflag |= 2;
X			else if (eq(p, "{") || eq(p, "{}"))
X				continue;
X		while (c = *p++)
X			(*f)(c);
X	}
X}
X/*
Xstatic
Xscan(t, f)
X	register char **t;
X	int (*f)();
X{
X	register char *p, c;
X
X	while (p = *t++)
X		while (c = *p)
X			*p++ = (*f)(c);
X} */
X
Xstatic
Xtglob(c)
X	register char c;
X{
X
X	if (any(c, globchars))
X		gflag |= c == '{' ? 2 : 1;
X	return (c);
X}
X/*
Xstatic
Xtrim(c)
X	char c;
X{
X
X	return (c & TRIM);
X} */
X
X
Xletter(c)
X	register char c;
X{
X
X	return (c >= 'a' && c <= 'z' || c >= 'A' && c <= 'Z' || c == '_');
X}
X
Xdigit(c)
X	register char c;
X{
X
X	return (c >= '0' && c <= '9');
X}
X
Xany(c, s)
X	register int c;
X	register char *s;
X{
X
X	while (*s)
X		if (*s++ == c)
X			return(1);
X	return(0);
X}
Xblklen(av)
X	register char **av;
X{
X	register int i = 0;
X
X	while (*av++)
X		i++;
X	return (i);
X}
X
Xchar **
Xblkcpy(oav, bv)
X	char **oav;
X	register char **bv;
X{
X	register char **av = oav;
X
X	while (*av++ = *bv++)
X		continue;
X	return (oav);
X}
X
Xblkfree(av0)
X	char **av0;
X{
X	register char **av = av0;
X
X	while (*av)
X		free(*av++);
X	free((char *)av0);
X}
X
Xstatic
Xchar *
Xstrspl(cp, dp)
X	register char *cp, *dp;
X{
X	register char *ep = malloc((unsigned)(strlen(cp) + strlen(dp) + 1));
X
X	if (ep == (char *)0)
X		fatal("Out of memory");
X	(void) strcpy(ep, cp);
X	(void) strcat(ep, dp);
X	return (ep);
X}
X
Xchar **
Xcopyblk(v)
X	register char **v;
X{
X	register char **nv = (char **)malloc((unsigned)((blklen(v) + 1) *
X						sizeof(char **)));
X	if (nv == (char **)0)
X		fatal("Out of memory");
X
X	return (blkcpy(nv, v));
X}
X
Xstatic
Xchar *
Xstrend(cp)
X	register char *cp;
X{
X
X	while (*cp)
X		cp++;
X	return (cp);
X}
X/*
X * Extract a home directory from the password file
X * The argument points to a buffer where the name of the
X * user whose home directory is sought is currently.
X * We write the home directory of the user back there.
X */
Xgethdir(home)
X	char *home;
X{
X	register struct passwd *pp = getpwnam(home);
X
X	if (pp == 0)
X		return (1);
X	(void) strcpy(home, pp->pw_dir);
X	return (0);
X}
END-of-glob.c
echo x - logwtmp.c
sed 's/^X//' >logwtmp.c << 'END-of-logwtmp.c'
X/*
X * Copyright (c) 1988 The Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X *
X * static char sccsid[] = "@(#)logwtmp.c	5.2 (Berkeley) 9/20/88";
X */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)logwtmp.c	5.2 (Berkeley) 9/22/88";
X#endif /* not lint */
X
X#include <sys/types.h>
X#include <sys/file.h>
X#include <sys/time.h>
X#include <sys/stat.h>
X#include <utmp.h>
X
X#define	WTMPFILE	"/usr/adm/wtmp"
X
Xstatic int fd;
X
Xlogwtmp(line, name, host)
X	char *line, *name, *host;
X{
X	struct utmp ut;
X	struct stat buf;
X	time_t time();
X	char *strncpy();
X
X	if (!fd && (fd = open(WTMPFILE, O_WRONLY|O_APPEND, 0)) < 0)
X		return;
X	if (!fstat(fd, &buf)) {
X		(void)strncpy(ut.ut_line, line, sizeof(ut.ut_line));
X		(void)strncpy(ut.ut_name, name, sizeof(ut.ut_name));
X		(void)strncpy(ut.ut_host, host, sizeof(ut.ut_host));
X		(void)time(&ut.ut_time);
X		if (write(fd, (char *)&ut, sizeof(struct utmp)) !=
X		    sizeof(struct utmp))
X			(void)ftruncate(fd, buf.st_size);
X	}
X}
END-of-logwtmp.c
echo x - newvers.sh
sed 's/^X//' >newvers.sh << 'END-of-newvers.sh'
X#!/bin/sh -
X#
X# Copyright (c) 1983 The Regents of the University of California.
X# All rights reserved.
X#
X# Redistribution and use in source and binary forms are permitted
X# provided that the above copyright notice and this paragraph are
X# duplicated in all such forms and that any documentation,
X# advertising materials, and other materials related to such
X# distribution and use acknowledge that the software was developed
X# by the University of California, Berkeley.  The name of the
X# University may not be used to endorse or promote products derived
X# from this software without specific prior written permission.
X# THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X# IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X# WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X#
X#	@(#)newvers.sh	5.3 (Berkeley) 10/31/88
X#
Xif [ ! -r version ]; then echo 0 > version; fi
Xtouch version
Xawk '	{	version = $1 + 1; }\
XEND	{	printf "char version[] = \"Version 4.%d ", version > "vers.c";\
X		printf "%d\n", version > "version"; }' < version
Xecho `date`'";' >> vers.c
END-of-newvers.sh
echo x - popen.c
sed 's/^X//' >popen.c << 'END-of-popen.c'
X/*
X * Copyright (c) 1988 The Regents of the University of California.
X * All rights reserved.
X *
X * This code is derived from software written by Ken Arnold and
X * published in UNIX Review, Vol. 6, No. 8.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X *
X * static char sccsid[] = "@(#)popen.c	5.7 (Berkeley) 9/1/88";
X */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)popen.c	5.2 (Berkeley) 9/22/88";
X#endif /* not lint */
X
X#include <sys/types.h>
X#include <sys/signal.h>
X#include <stdio.h>
X
X/*
X * Special version of popen which avoids call to shell.  This insures noone
X * may create a pipe to a hidden program as a side effect of a list or dir
X * command.
X */
Xstatic uid_t *pids;
Xstatic int fds;
X
XFILE *
Xpopen(program, type)
X	char *program, *type;
X{
X	register char *cp;
X	FILE *iop;
X	int argc, gargc, pdes[2], pid;
X	char **pop, *argv[100], *gargv[1000], *vv[2];
X	extern char **glob(), **copyblk(), *strtok();
X
X	if (*type != 'r' && *type != 'w' || type[1])
X		return(NULL);
X
X	if (!pids) {
X		if ((fds = getdtablesize()) <= 0)
X			return(NULL);
X		if (!(pids =
X		    (uid_t *)malloc((u_int)(fds * sizeof(uid_t)))))
X			return(NULL);
X		bzero(pids, fds * sizeof(uid_t));
X	}
X	if (pipe(pdes) < 0)
X		return(NULL);
X
X	/* break up string into pieces */
X	for (argc = 0, cp = program;; cp = NULL)
X		if (!(argv[argc++] = strtok(cp, " \t\n")))
X			break;
X
X	/* glob each piece */
X	gargv[0] = argv[0];
X	for (gargc = argc = 1; argv[argc]; argc++) {
X		if (!(pop = glob(argv[argc]))) {	/* globbing failed */
X			vv[0] = argv[argc];
X			vv[1] = NULL;
X			pop = copyblk(vv);
X		}
X		argv[argc] = (char *)pop;		/* save to free later */
X		while (*pop && gargc < 1000)
X			gargv[gargc++] = *pop++;
X	}
X	gargv[gargc] = NULL;
X
X	iop = NULL;
X	switch(pid = vfork()) {
X	case -1:			/* error */
X		(void)close(pdes[0]);
X		(void)close(pdes[1]);
X		goto free;
X		/* NOTREACHED */
X	case 0:				/* child */
X		if (*type == 'r') {
X			if (pdes[1] != 1) {
X				dup2(pdes[1], 1);
X				(void)close(pdes[1]);
X			}
X			(void)close(pdes[0]);
X		} else {
X			if (pdes[0] != 0) {
X				dup2(pdes[0], 0);
X				(void)close(pdes[0]);
X			}
X			(void)close(pdes[1]);
X		}
X		execv(gargv[0], gargv);
X		_exit(1);
X	}
X	/* parent; assume fdopen can't fail...  */
X	if (*type == 'r') {
X		iop = fdopen(pdes[0], type);
X		(void)close(pdes[1]);
X	} else {
X		iop = fdopen(pdes[1], type);
X		(void)close(pdes[0]);
X	}
X	pids[fileno(iop)] = pid;
X
Xfree:	for (argc = 1; argv[argc] != NULL; argc++)
X		blkfree((char **)argv[argc]);
X	return(iop);
X}
X
Xpclose(iop)
X	FILE *iop;
X{
X	register int fdes;
X	long omask;
X	int pid, stat_loc;
X	u_int waitpid();
X
X	/*
X	 * pclose returns -1 if stream is not associated with a
X	 * `popened' command, or, if already `pclosed'.
X	 */
X	if (pids[fdes = fileno(iop)] == 0)
X		return(-1);
X	(void)fclose(iop);
X	omask = sigblock(sigmask(SIGINT)|sigmask(SIGQUIT)|sigmask(SIGHUP));
X	while ((pid = wait(&stat_loc)) != pids[fdes] && pid != -1);
X	(void)sigsetmask(omask);
X	pids[fdes] = 0;
X	return(stat_loc);
X}
END-of-popen.c
echo x - vers.c
sed 's/^X//' >vers.c << 'END-of-vers.c'
Xchar version[] = "Version 4.160 Mon Oct 31 11:50:39 PST 1988";
END-of-vers.c
echo x - version
sed 's/^X//' >version << 'END-of-version'
X160
END-of-version
exit

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 19:59:11 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  4BSD TCP Ethernet Throughput

Dan,

If one writes well and has the patience
SOmeone will come from among the runners
And read what one has written quickly
And write out as much as he can remmeber
In the language of the highway

- Yeats

Dave

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 88 21:35:41 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .


*Heck,  if you speak out, others will quote you.  

*Sigh,
*Dan
*-------

that is "misquote", dan. (or are *you* misquoting?)(or should we just 
misquote you)   


it is bad enough that articles misquote someone, i would like to think
that most of them dont know they are mucking it up, rather than not caring
or trying to twist things to prove their point.


i would be saddened to see people stop posting here because they are scared
of being mis-quoted . . . . . . . . . 



stev knowles
ftp-software
stev@ftp.com

 

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 09:37:00 PDT
From:      Jerry Scott <jerry@TWG.COM>
To:        yee <yee@ames.arc.nasa.gov>
Cc:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE: Internet VIRUS alert
Peter,
	I guess I am not that familiar with the Unix mail systems
of the Sun and Vax.  Is this sendmail?  Does sendmail have the ability
of receiving mail for a process?  If so, this is the biggest security
hole I have heard about in a long time.

Jerry

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      03 Nov 88 09:16:35 EST
From:      JIM.H@TRNG-E.Prime.COM
To:        TCP-IP@SRI-NIC.ARPA
To:       Doug Brenner Data Base Admin, U of Iowa (TCP-IP@SRI-NIC.ARPA)
From:     Jim Herbeck (jim.h -on trng.e) (jim.h@trng-e.prime.com)
Date:     03 Nov 88  9:16 AM
Subject:  Re: Sigh...How much we love the "nets" ACK (BLECH)
-------------------------

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 04:37:22 GMT
From:      kmont@hpindda.HP.COM (Kevin Montgomery)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC talking OSI?

>	Has anyone seen a copy of RPC that speaks an OSI protocol
>instead of using UDP?  Anyone at TWG (or anyone else) have anything 
>like this available either now or in the works?

sorry- should have been more specific.  I was looking for a version
of SunRPC over ROSE (X.219).  Thanks to Marshall and Sleaze_Hack for
the info in general-  looks like I'll be checking out TWG's ISODE
for ROSY over ROSE (/mtr - is that the RPC mechanism you were referring 
to?)  

					thanks again,
					  kevin

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 04:55:07 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .


Stev,  The press does a mixed job, for sure.  But they fill a need for
many persons who want to get a feel of what is going on "out there".
I look upon it as "awareness training".  When I see enough articles
about something I am peripherally interested in, I then do something
more "serious" about gettin gthe next level of information.  I remember
having the follwoing three experiences in my life with the press:
1)  When I was 16 I got in a fender bender in my small town.  It got in the 
local paper, of course!  The article had me going north instead of south,
driving the other person's vehicle make, etc.  They did, however, get my name 
right.
2)  A few years ago there was a Datamation article about me and my efforts
to resolve theissue of whether there was going to be a big push to mandate
TCP/IP protocol testing.  The article had numerous "quotes" from me and
from at least a half dozen other persons.  Essentially every "fact" in
the article was wrong.  (All the numbers were off by a factor of at least
10 and in random directions!)  The "story" was, however, very accurate.
3)  A few months ago I had a long interview with some reporter about the
evolution of TCP/IP.  In our conversation I told the reporter about some
of my (dark) past and one item had to do with how I worked on managing the
transition from the old NCP protocols to the new TCP/IP protocols.  In the
ensuing printed article the reporter said that I led the conversion of
IBM's Network Control Program for the 360/370 architecture to Arpanet.
That poor reporter took my acronym, NCP, and translated it to something
quite normal in the "real world".  No harm.  No one called me up and
called me a charlatan because I actually know nothing about IBM's NCP!

In short, Stev, you are right!  Just say it the best way you know how
and take the "losses in translation".  That's the beauty of humans.
They can compensate for a lot of bogosity.  If, howsomever, they take
a tight, efficient, accurate algorithm from someone like Van Jacobson and
contort it in any way, it cannot be compiled by a computer, for sure.

Now that I've started and ended this with "Valley Speak",
Ciao,
Dan
-------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 07:28:00 GMT
From:      yee@AMES.ARC.NASA.GOV (Peter E. Yee)
To:        comp.protocols.tcp-ip
Subject:   Internet VIRUS alert

We are currently under attack from an Internet VIRUS.  It has hit UC Berkeley,
UC San Diego, Lawrence Livermore, Stanford, and NASA Ames.  The virus comes in
via SMTP, and then is able to attack all 4.3BSD and SUN (3.X?) machines.  It
sends a RCPT TO that requests that its data be piped through a shell.  It copies
in a program, compiles and executes it.  This program copies in VAX and SUN 
binaries that try to replicate the virus via connections to TELNETD, FTPD, 
FINGERD, RSHD, and SMTP.  The programs also appear to have DES tables in them.
They appear in /usr/tmp as files that start with the letter x.  Removing them
is not enough as they will come back in the next wave of attacks.  For now
turning off the above services seems to be the only help.  The virus is able
to take advantage of .rhosts files and hosts.equiv.  We are not certain what the
final result of the binaries is, hence the warning.

I can be contacted at (415) 642-7447.  Phil Lapsley and Kurt Pires at this
number are also conversant with the virus.  

							-Peter Yee
							yee@ames.arc.nasa.gov
							ames!yee

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 08:34:13 GMT
From:      foo@bar.arpa
To:        comp.protocols.tcp-ip
Subject:   (none)

A Possible virus report:

There may be a virus loose on the internet.

Here is the gist of a message Igot:

I'm sorry.

Here are some steps to prevent further transmission:

1) don't run fingerd, or fix it to not overrun its stack when reading
arguments.

2) recompile sendmail w/o DEBUG defined

3) don't run rexecd

Hope this helps, but more, I hope it is a hoax.
qui

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 10:56:25 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Virus fixes

Subject: Fixes for the virus
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
	There's a virus running around; the salient facts.  A bug in
	sendmail has been used to introduce a virus into a lot of
	Internet UNIX systems.  It has not been observed to damage the
	host system, however, it's incredibly virulent, attempting to
	introduce itself to every system it can find.  It appears to
	use rsh, broken passwords, and sendmail to introduce itself
	into the target systems.  It affects only VAXen and Suns, as
	far as we know.  

	There are three changes that we believe will immunize your
	system.  They are attached.

	Thanks to the Experimental Computing Facility, Center for
	Disease Control for their assistance.  (It's pretty late,
	and they certainly deserved some thanks, somewhere!)

Fix:
	First, either recompile or patch sendmail to disallow the `debug'
	option.  If you have source, recompile sendmail after first
	applying the following patch to the module svrsmtp.c:

		*** /tmp/d22039	Thu Nov  3 02:26:20 1988
		--- srvrsmtp.c	Thu Nov  3 01:21:04 1988
		***************
		*** 85,92 ****
		  	"onex",		CMDONEX,
		  # ifdef DEBUG
		  	"showq",	CMDDBGQSHOW,
		- 	"debug",	CMDDBGDEBUG,
		  # endif DEBUG
		  # ifdef WIZ
		  	"kill",		CMDDBGKILL,
		  # endif WIZ
		--- 85,94 ----
		  	"onex",		CMDONEX,
		  # ifdef DEBUG
		  	"showq",	CMDDBGQSHOW,
		  # endif DEBUG
		+ # ifdef notdef
		+ 	"debug",	CMDDBGDEBUG,
		+ # endif notdef
		  # ifdef WIZ
		  	"kill",		CMDDBGKILL,
		  # endif WIZ

	Then, reinstall sendmail, refreeze the configuration file,
	using the command "/usr/lib/sendmail -bz", kill any running
	sendmail's, using the ps(1) command and the kill(1) command,
	and restart your sendmail.  To find out how sendmail is 
	execed on your system, use grep(1) to find the sendmail start
	line in either the files /etc/rc or /etc/rc.local

	If you don't have source, apply the following patch to your
	sendmail binary.  SAVE A COPY OF IT FIRST, IN CASE YOU MESS
	UP!  This is mildly tricky -- note, some versions of strings(1),
	which we're going to use to find the offset of the string 
	"debug" in the binary print out the offsets in octal, not
	decimal.  Run the following shell line to decide how your
	version of strings(1) works:

		/bin/echo 'abcd' | /usr/ucb/strings -o 

	Note, make sure the eight control 'G's are preserved in this
	line.  If this command results in something like:

		0000008 abcd

	your strings(1) command prints out locations in decimal, else
	it's octal.

	The patch script for sendmail.  NOTE, YOUR OFFSETS MAY VARY!!
	This script assumes that your strings(1) command prints out
	the offsets in decimal.  

		Script started on Thu Nov  3 02:08:14 1988
		okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug
		0096972 debug
		okeeffe:tmp {3} adb -w /usr/lib/sendmail
		?m 0 0xffffffff 0
		0t10$d
		radix=10 base ten
		96972?s
		96972:		debug
		96972?w 0
		96972:		25701	=	0
		okeeffe:tmp {4} ^D
		script done on Thu Nov  3 02:09:31 1988

	If your strings(1) command prints out the offsets in octal,
	change the line "0t10$d" to "0t8$d".

	After you've fixed sendmail, move both /bin/cc and /bin/ld to
	something else.  (The virus uses the cc and the ld commands
	to rebuild itself to run on your system.)

	Finally, kill any processes on your system that don't belong there.
	Suspicious ones have "(sh)" or "xNNNNNNN" where the N's are random
	digits, as the command name on the ps(1) output line.

	One more thing, if you find files in /tmp or /usr/tmp that 
	have names like "xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or
	"xNNNNNNN,vax.o" where the N's are random digits, you've been
	infected.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 12:57:25 GMT
From:      sater@cs.vu.nl (Hans van Staveren)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Trailblazer detailed info wanted

Not too long ago there was an article in one of these groups
explaining in gory details the working of the Telebit Trailblazer.
How it subdivided the spectrum, how the encoding worked, what the line
turnaround time was, how much user data could be piggybacked on the
modems own communication etc..

At the time I read it quickly and forgot it, but of course now I
am asked for the data.

If anybody still has that article could they mail it to me?

Thanks in advance,
				Hans van Staveren
				Vrije Universiteit
				Amsterdam, Holland

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 13:52:31 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .

>In short, Stev, you are right!  Just say it the best way you know how
>and take the "losses in translation".  That's the beauty of humans.
>They can compensate for a lot of bogosity.  If, howsomever, they take
>a tight, efficient, accurate algorithm from someone like Van Jacobson and
>contort it in any way, it cannot be compiled by a computer, for sure.

In the tradition of getting the facts wrong but the story right:

The closing reference to Van Jacobson and a compiler reminds me of an
old story about someone who worked for Sperry.  For amusement, he would
submit the inter-office memos to a COBOL complier; about 1/4 of the 
memos would compile.  Regards - Craig

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 14:16:35 GMT
From:      JIM.H@TRNG-E.Prime.COM
To:        comp.protocols.tcp-ip
Subject:   (none)

To:       Doug Brenner Data Base Admin, U of Iowa (TCP-IP@SRI-NIC.ARPA)
From:     Jim Herbeck (jim.h -on trng.e) (jim.h@trng-e.prime.com)
Date:     03 Nov 88  9:16 AM
Subject:  Re: Sigh...How much we love the "nets" ACK (BLECH)
-------------------------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 15:59:11 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet VIRUS alert

Please install this patch from Berkeley if you are running sendmail.

---rick


From bostic@okeeffe.Berkeley.EDU Thu Nov  3 06:38:39 1988
Received: from okeeffe.Berkeley.EDU by beno.CSS.GOV (5.59/5.17)
	id AA03506; Thu, 3 Nov 88 06:38:26 EST
Received: by okeeffe.Berkeley.EDU (5.61/1.29)
	id AA22190; Thu, 3 Nov 88 02:58:55 PST
Date: Thu, 3 Nov 88 02:58:55 PST
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Message-Id: <8811031058.AA22190@okeeffe.Berkeley.EDU>
To: rick@beno.CSS.GOV, spaf@purdue.edu
Subject: Virus (READ THIS IMMEDIATELY)
Status: RO


Guys, if you could post this to whatever appropriate newsgroups,
as soon as possible, we'd appreciate it.

Thanks.

--keith

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subject: Fixes for the virus
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
	There's a virus running around; the salient facts.  A bug in
	sendmail has been used to introduce a virus into a lot of
	Internet UNIX systems.  It has not been observed to damage the
	host system, however, it's incredibly virulent, attempting to
	introduce itself to every system it can find.  It appears to
	use rsh, broken passwords, and sendmail to introduce itself
	into the target systems.  It affects only VAXen and Suns, as
	far as we know.  

	There are three changes that we believe will immunize your
	system.  They are attached.

	Thanks to the Experimental Computing Facility, Center for
	Disease Control for their assistance.  (It's pretty late,
	and they certainly deserved some thanks, somewhere!)

Fix:
	First, either recompile or patch sendmail to disallow the `debug'
	option.  If you have source, recompile sendmail after first
	applying the following patch to the module svrsmtp.c:

		*** /tmp/d22039	Thu Nov  3 02:26:20 1988
		--- srvrsmtp.c	Thu Nov  3 01:21:04 1988
		***************
		*** 85,92 ****
		  	"onex",		CMDONEX,
		  # ifdef DEBUG
		  	"showq",	CMDDBGQSHOW,
		- 	"debug",	CMDDBGDEBUG,
		  # endif DEBUG
		  # ifdef WIZ
		  	"kill",		CMDDBGKILL,
		  # endif WIZ
		--- 85,94 ----
		  	"onex",		CMDONEX,
		  # ifdef DEBUG
		  	"showq",	CMDDBGQSHOW,
		  # endif DEBUG
		+ # ifdef notdef
		+ 	"debug",	CMDDBGDEBUG,
		+ # endif notdef
		  # ifdef WIZ
		  	"kill",		CMDDBGKILL,
		  # endif WIZ

	Then, reinstall sendmail, refreeze the configuration file,
	using the command "/usr/lib/sendmail -bz", kill any running
	sendmail's, using the ps(1) command and the kill(1) command,
	and restart your sendmail.  To find out how sendmail is 
	execed on your system, use grep(1) to find the sendmail start
	line in either the files /etc/rc or /etc/rc.local

	If you don't have source, apply the following patch to your
	sendmail binary.  SAVE A COPY OF IT FIRST, IN CASE YOU MESS
	UP!  This is mildly tricky -- note, some versions of strings(1),
	which we're going to use to find the offset of the string 
	"debug" in the binary print out the offsets in octal, not
	decimal.  Run the following shell line to decide how your
	version of strings(1) works:

		/bin/echo 'abcd' | /usr/ucb/strings -o 

	Note, make sure the eight control 'G's are preserved in this
	line.  If this command results in something like:

		0000008 abcd

	your strings(1) command prints out locations in decimal, else
	it's octal.

	The patch script for sendmail.  NOTE, YOUR OFFSETS MAY VARY!!
	This script assumes that your strings(1) command prints out
	the offsets in decimal.  

		Script started on Thu Nov  3 02:08:14 1988
		okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug
		0096972 debug
		okeeffe:tmp {3} adb -w /usr/lib/sendmail
		?m 0 0xffffffff 0
		0t10$d
		radix=10 base ten
		96972?s
		96972:		debug
		96972?w 0
		96972:		25701	=	0
		okeeffe:tmp {4} ^D
		script done on Thu Nov  3 02:09:31 1988

	If your strings(1) command prints out the offsets in octal,
	change the line "0t10$d" to "0t8$d".

	After you've fixed sendmail, move both /bin/cc and /bin/ld to
	something else.  (The virus uses the cc and the ld commands
	to rebuild itself to run on your system.)

	Finally, kill any processes on your system that don't belong there.
	Suspicious ones have "(sh)" or "xNNNNNNN" where the N's are random
	digits, as the command name on the ps(1) output line.

	One more thing, if you find files in /tmp or /usr/tmp that 
	have names like "xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or
	"xNNNNNNN,vax.o" where the N's are random digits, you've been
	infected.

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 16:13:50 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Virus posting #2

Subject: Virus posting #2
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
	This is a followup message, to clear up two points.
	First off, a better value to use to PATCH your sendmail
	executable is 0xff; if you're using the patch script,
	change:
		96972?w 0
	to:
		96972?w 65535

	Secondly, note, if, when you run strings(1) on your sendmail
	executable, greping for ``debug'', you don't get any output,
	don't worry about the problem, your system is already (we
	think) safe.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 16:37:00 GMT
From:      jerry@TWG.COM (Jerry Scott)
To:        comp.protocols.tcp-ip
Subject:   RE: Internet VIRUS alert

Peter,
	I guess I am not that familiar with the Unix mail systems
of the Sun and Vax.  Is this sendmail?  Does sendmail have the ability
of receiving mail for a process?  If so, this is the biggest security
hole I have heard about in a long time.

Jerry

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 88 16:57:19 GMT
From:      sms@ETN-WLV.EATON.COM (Steven M. Schultz)
To:        comp.protocols.tcp-ip
Subject:   (none)

> From: Peter E. Yee <yee@ames.arc.nasa.gov>
> Message-Id: <8811030728.AA18199@ames.arc.nasa.gov>
> Subject: Internet VIRUS alert
> 
> We are currently under attack from an Internet VIRUS.  It has hit UC Berkeley,
> UC San Diego, Lawrence Livermore, Stanford, and NASA Ames.  The virus comes in
> via SMTP, and then is able to attack all 4.3BSD and SUN (3.X?) machines.  It
> sends a RCPT TO that requests that its data be piped through a shell.
> ...
> 							-Peter Yee
> 							yee@ames.arc.nasa.gov
> 							ames!yee

	Before turning off various services I logged attempts from
	these addresses:

		128.15.0.76
		26.7.0.102
		128.49.16.91
		and
		128.9.1.2

	I am still seeing SMTP attempts from 26.7.0.102, the lines in
	the sendmail logfile look like this:

Nov  3 08:26:28 from=</dev/null>, size=1676, class=0
Nov  3 08:26:35 to=<"| sed '1,/^$/d' | /bin/sh ; exit 0">, delay=00:00:19,
Nov  3 08:46:37 from: 26.7.0.102.49412
Nov  3 08:46:57 message-id=<8811031646.AA02609@ETN-WLV.EATON.COM>
Nov  3 08:46:57 from=</dev/null>, size=1677, class=0
Nov  3 08:47:04 to=<"| sed '1,/^$/d' | /bin/sh ; exit 0">, delay=00:00:23,
Nov  3 08:50:46 from: 26.0.0.58.49924
Nov  3 08:51:02 message-id=<8811031650.AA02625@ETN-WLV.EATON.COM>
Nov  3 08:51:02 from=</dev/null>, size=1675,
Nov  3 08:51:08 to=<"| sed '1,/^$/d' | /bin/sh ; exit 0">, delay=00:00:19,

	Hmmm, there'a new one here - 26.0.0.58.  Hadn't seen that one yet.

	Steven M. Schultz
	sms@etn-wlv.eaton.com

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3 Nov 88 21:32:10 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

In article <1988Oct31.215228.18443@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>...it seems that "the bog" is the obvious name for
>>the unit of measure...
>
>Best suggestion I've heard so far...

Problem (pointed out by Craig Partridge):  we really don't want to measure
bad network implementations with a unit that sounds too much like Dave
Boggs's last name.  He's one of the good guys.
-- 
The Earth is our mother.        |    Henry Spencer at U of Toronto Zoology
Our nine months are up.         |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 00:22:00 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   ^O in EMACS


    Date: Tuesday, 1 November 1988  18:01-EST
    From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)

    Thanks to everyone who responded and informed me the function of
    ^O; however, the question was more specifically "why?".  In a
    rhetorical vein, why does EMACS, in general, use standard control
    characters as application dependent function characters?  Why
    would any application?

Ancient history, mostly.

Keep in mind that the original EMACS was a set of TECO macros (hence
the name Editor MACroS) on the MIT Incompatible Timesharing System.
ITS has a long tradition of doing nonstandard things with control
characters, eg, to most ITS programs other than EMACS (which has so
many commands that RMS had to use every possible key combination):

    ^C = EOF;
    ^D = Discard (punt the line currently being entered);
    ^S = Shutup (stop tty output);
    ^Q = Quote (quote the next character).

You expect conformity on a system where the command processor is a
souped-up assembly language debugger?

--Rob

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 00:36:50 GMT
From:      terry@RAND.ORG (Terry West)
To:        comp.protocols.tcp-ip
Subject:   Virus detection and prevention

If you have been hit by the current Internet virus (grep for "sed" in your
syslog file), you will want to run the enclosed perl script to make sure
it won't find its way back in as easily the next time.

The enclosed shar file extracts two files: a perl script and a list of
proposed passwords.  The passwords were extracted from the object module
that the virus ships to each target site: they were lightly encrypted.
The perl script checks your /etc/passwd file to see whether any of your
users is using one of these passwords.

The virus is known to check (at least) whether the user is a "joe": i.e.
whether the user name is the same as the password; this perl script
checks that as well.

To use it, unpack the shar script (after reading it extremely carefully,
as you always do) and run "vircheck".

    Terry West
    <terry@rand.org>

p.s.
  Thanks to Jim Gillogly for *all* of this.


#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  vircheck virpasswords
# Wrapped by terry@ipsy on Thu Nov  3 16:10:32 1988
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'vircheck' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'vircheck'\"
else
echo shar: Extracting \"'vircheck'\" \(1021 characters\)
sed "s/^X//" >'vircheck' <<'END_OF_FILE'
X#!/usr/local/perl
X#
X# vircheck: brute force password from Internet virus password list
X#
X# 3 Nov 88, Jim Gillogly
X
X$pwfile = "/etc/passwd";
X
X$words = "virpasswords";        # Try all words out of the virus list
X
X$| = 1;                         # Flush the output
X
Xopen(pw, $pwfile);              # Get the password file
Xwhile (<pw>)                    # a line at a time
X{
X	($user, $pass) = split(/:/);    # Get the username and password
X	$usalt = substr($pass, 0, 2);   # 1st 2 chars are the salt
X	print "Trying $user\n";
X	$salt = substr($pass, 0, 2);    # Get the salt
X	open(w1, $words);               # Get the dictionary once
X	while (<w1>)                    # For each word from the dictionary
X	{       chop;                   # Ignore the newline
X		if (crypt($_, $salt) eq $pass)  # Check the word
X		{       print "  *****$user: $pass comes from password $_.\n";
X		}
X	}
X	if (crypt($user, $salt) eq $pass)       # Is this a "joe"?
X	{       print "  *****$user: $pass comes from password $user.\n";
X	}
X
X	close(w1);
X}
END_OF_FILE
if test 1021 -ne `wc -c <'vircheck'`; then
    echo shar: \"'vircheck'\" unpacked with wrong size!
fi
chmod +x 'vircheck'
# end of 'vircheck'
fi
if test -f 'virpasswords' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'virpasswords'\"
else
echo shar: Extracting \"'virpasswords'\" \(3278 characters\)
sed "s/^X//" >'virpasswords' <<'END_OF_FILE'
Xaaa
Xacademia
Xaerobics
Xairplane
Xalbany
Xalbatross
Xalbert
Xalex
Xalexander
Xalgebra
Xaliases
Xalphabet
Xama
Xamorphous
Xanalog
Xanchor
Xandromache
Xanimals
Xanswer
Xanthropogenic
Xanvils
Xanything
Xaria
Xariadne
Xarrow
Xarthur
Xathena
Xatmosphere
Xaztecs
Xazure
Xbacchus
Xbailey
Xbanana
Xbananas
Xbandit
Xbanks
Xbarber
Xbaritone
Xbass
Xbassoon
Xbatman
Xbeater
Xbeauty
Xbeethoven
Xbeloved
Xbenz
Xbeowulf
Xberkeley
Xberliner
Xberyl
Xbeverly
Xbicameral
Xbob
Xbrenda
Xbrian
Xbridget
Xbroadway
Xbumbling
Xburgess
Xcampanile
Xcantor
Xcardinal
Xcarmen
Xcarolina
Xcaroline
Xcascades
Xcastle
Xcat
Xcayuga
Xceltics
Xcerulean
Xchange
Xcharles
Xcharming
Xcharon
Xchester
Xcigar
Xclassic
Xclusters
Xcoffee
Xcoke
Xcollins
Xcommrades
Xcomputer
Xcondo
Xcookie
Xcooper
Xcornelius
Xcouscous
Xcreation
Xcreosote
Xcretin
Xdaemon
Xdancer
Xdaniel
Xdanny
Xdave
Xdecember
Xdefoe
Xdeluge
Xdesperate
Xdevelop
Xdieter
Xdigital
Xdiscovery
Xdisney
Xdog
Xdrought
Xduncan
Xeager
Xeasier
Xedges
Xedinburgh
Xedwin
Xedwina
Xegghead
Xeiderdown
Xeileen
Xeinstein
Xelephant
Xelizabeth
Xellen
Xemerald
Xengine
Xengineer
Xenterprise
Xenzyme
Xersatz
Xestablish
Xestate
Xeuclid
Xevelyn
Xextension
Xfairway
Xfelicia
Xfender
Xfermat
Xfidelity
Xfinite
Xfishers
Xflakes
Xfloat
Xflower
Xflowers
Xfoolproof
Xfootball
Xforesight
Xformat
Xforsythe
Xfourier
Xfred
Xfriend
Xfrighten
Xfun
Xfungible
Xgabriel
Xgardner
Xgarfield
Xgauss
Xgeorge
Xgertrude
Xginger
Xglacier
Xgnu
Xgolfer
Xgorgeous
Xgorges
Xgosling
Xgouge
Xgraham
Xgryphon
Xguest
Xguitar
Xgumption
Xguntis
Xhacker
Xhamlet
Xhandily
Xhappening
Xharmony
Xharold
Xharvey
Xhebrides
Xheinlein
Xhello
Xhelp
Xherbert
Xhiawatha
Xhibernia
Xhoney
Xhorse
Xhorus
Xhutchins
Ximbroglio
Ximperial
Xinclude
Xingres
Xinna
Xinnocuous
Xirishman
Xisis
Xjapan
Xjessica
Xjester
Xjixian
Xjohnny
Xjoseph
Xjoshua
Xjudith
Xjuggle
Xjulia
Xkathleen
Xkermit
Xkernel
Xkirkland
Xknight
Xladle
Xlambda
Xlamination
Xlarkin
Xlarry
Xlazarus
Xlebesgue
Xlee
Xleland
Xleroy
Xlewis
Xlight
Xlisa
Xlouis
Xlynne
Xmacintosh
Xmack
Xmaggot
Xmagic
Xmalcolm
Xmark
Xmarkus
Xmarty
Xmarvin
Xmaster
Xmaurice
Xmellon
Xmerlin
Xmets
Xmichael
Xmichelle
Xmike
Xminimum
Xminsky
Xmoguls
Xmoose
Xmorley
Xmozart
Xnancy
Xnapoleon
Xnepenthe
Xness
Xnetwork
Xnewton
Xnext
Xnoxious
Xnutrition
Xnyquist
Xoceanography
Xocelot
Xolivetti
Xolivia
Xoracle
Xorca
Xorwell
Xosiris
Xoutlaw
Xoxford
Xpacific
Xpainless
Xpakistan
Xpam
Xpapers
Xpassword
Xpatricia
Xpenguin
Xpeoria
Xpercolate
Xpersimmon
Xpersona
Xpete
Xpeter
Xphilip
Xphoenix
Xpierre
Xpizza
Xplover
Xplymouth
Xpolynomial
Xpondering
Xpork
Xposter
Xpraise
Xprecious
Xprelude
Xprince
Xprinceton
Xprotect
Xprotozoa
Xpumpkin
Xpuneet
Xpuppet
Xrabbit
Xrachmaninoff
Xrainbow
Xraindrop
Xraleigh
Xrandom
Xrascal
Xreally
Xrebecca
Xremote
Xrick
Xripple
Xrobotics
Xrochester
Xrolex
Xromano
Xronald
Xrosebud
Xrosemary
Xroses
Xruben
Xrules
Xruth
Xsal
Xsaxon
Xscamper
Xscheme
Xscott
Xscotty
Xsecret
Xsensor
Xserenity
Xsharks
Xsharon
Xsheffield
Xsheldon
Xshiva
Xshivers
Xshuttle
Xsignature
Xsimon
Xsimple
Xsinger
Xsingle
Xsmile
Xsmiles
Xsmooch
Xsmother
Xsnatch
Xsnoopy
Xsoap
Xsocrates
Xsossina
Xsparrows
Xspit
Xspring
Xspringer
Xsquires
Xstrangle
Xstratford
Xstuttgart
Xsubway
Xsuccess
Xsummer
Xsuper
Xsuperstage
Xsupport
Xsupported
Xsurfer
Xsuzanne
Xswearer
Xsymmetry
Xtangerine
Xtape
Xtarget
Xtarragon
Xtaylor
Xtelephone
Xtemptation
Xthailand
Xtiger
Xtoggle
Xtomato
Xtopography
Xtortoise
Xtoyota
Xtrails
Xtrivial
Xtrombone
Xtubas
Xtuttle
Xumesh
Xunhappy
Xunicorn
Xunknown
Xurchin
Xutility
Xvasant
Xvertigo
Xvicky
Xvillage
Xvirginia
Xwarren
Xwater
Xweenie
Xwhatnot
Xwhiting
Xwhitney
Xwill
Xwilliam
Xwilliamsburg
Xwillie
Xwinston
Xwisconsin
Xwizard
Xwombat
Xwoodwind
Xwormwood
Xyacov
Xyang
Xyellowstone
Xyosemite
Xzap
Xzimmerman
END_OF_FILE
if test 3278 -ne `wc -c <'virpasswords'`; then
    echo shar: \"'virpasswords'\" unpacked with wrong size!
fi
chmod +x 'virpasswords'
# end of 'virpasswords'
fi
echo shar: End of shell archive.
exit 0

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 03:19:23 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   Virus posting #3


Subject: Virus posting #3
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
	The recently reported worm appears to also be using the
	fingerd(8) daemon to enter systems.  Here's a fix.

	The previous patch for sendmail(8) on binary systems only
	prevented the current attacker.  The attached patch fixes
	the problem.
Fix:
	Re-patch sendmail.  Recompile and reinstall the attached
	source for fingerd(8).

	Here's a script to repatch sendmail.  Note, this only applies
	to binary systems, if you have source you should have recompiled
	and reinstalled it already.  You should start with the original
	sendmail binary, NOT the binary that you've already patched.
	AND, REMEMBER, ALWAYS SAVE AN EXTRA COPY IN CASE YOU MAKE A
	MISTAKE!!  Finally, if you don't find the string ``debug'' in
	your sendmail binary, you don't have a problem; ignore this patch.
	This patch essentially makes it impossible to set the debug flag.

	Note, your offsets as printed by adb may vary!  Comments are
	preceded by a hash mark, don't type them in, nor expect adb
	to print them out.  Also, we're again using strings(1) to find
	the decimal offset in the file of certain strings.  To find 
	out if your strings(1) command prints offsets in decimal, 
	put 8 control (non-printable) characters in a file, followed
	by four printable characters, and then use strings(1) to find
	the offset of your four printable characters.  If the offset
	is ``8'', it's using decimal, if it's ``10'' it's using octal.
	
		Script started on Thu Nov  3 18:45:34 1988
# find the decimal offset of the strings ``debug'' and ``showq'' in the
# sendmail binary.
		okeeffe:tmp {2} strings -o -a sendmail | egrep 'debug|showq'
		0097040 showq
		0097046 debug
		okeeffe:tmp {3} adb -w sendmail
# set the map, then set the default radix to base 10
		?m 0 0xffffffff 0
		0t10$d
		radix=10 base ten
# check to make sure that strings(1) was right, and then find out what
# the byte pattern for ``showq'' is for your machine.  Note that adb
# prints out that byte pattern in HEX!
		97040?s
		97040:		showq
		97040?Xx
		97040:		73686f77	7100
# check on the string ``debug'', then, overwrite the first four bytes,
# move up 4 bytes, and then overwite the last two bytes with the byte
# pattern seen above for ``showq''.
		97046?s
		97046:		debug
		97046?W 0x73686f77
		97046:		1684365941	=	1936224119
		.+4
		.?w 0x7100
		97050:		26368	=	28928
# check to make sure we wrote out the correct string.
		97046?s
		97046:		showq
		okeeffe:tmp {4} strings -o -a sendmail | egrep 'debug|showq'
		0097040 showq
		0097046 showq
		okeeffe:tmp {5}
		script done on Thu Nov  3 18:47:42 1988


# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	fingerd.c
#
echo x - fingerd.c
sed 's/^X//' >fingerd.c << 'END-of-fingerd.c'
X/*
X * Copyright (c) 1983 The Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xchar copyright[] =
X"@(#) Copyright (c) 1983 The Regents of the University of California.\n\
X All rights reserved.\n";
X#endif /* not lint */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)fingerd.c	5.3 (Berkeley) 11/3/88";
X#endif /* not lint */
X
X/*
X * Finger server.
X */
X#include <sys/types.h>
X#include <netinet/in.h>
X#include <stdio.h>
X#include <ctype.h>
X
Xmain(argc, argv)
X	int argc;
X	char *argv[];
X{
X	register char *sp;
X	char line[512];
X	struct sockaddr_in sin;
X	int i, p[2], pid, status;
X	FILE *fp;
X	char *av[4];
X
X	i = sizeof (sin);
X	if (getpeername(0, &sin, &i) < 0)
X		fatal(argv[0], "getpeername		fatal(argv[0], "fdopen");
X	while ((i = getc(fp)) != EOF) {
X		if (i == '\n')
X			putchar('\r');
X		putchar(i);
X	}
X	fclose(fp);
X	while ((i = wait(&status)) != pid && i != -1)
X		;
X	return(0);
X}
X
Xfatal(prog, s)
X	char *prog, *s;
X{
X	fprintf(stderr, "%s: ", prog);
X	perror(s);
X	exit(1);
X}
END-of-fingerd.c
exit

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Fri, 04 Nov 88 12:09:39 -0500
From:      Frederick E Serr BBNCC 20/666 x2474 <fserr@ALEXANDER.BBN.COM>
To:        Clive Dawson <AI.CLIVE@mcc.com>
Cc:        tops20@score.stanford.edu, tcp-ip@sri-nic.ARPA
Subject:   Re: Network Connectivity - Part 2
I would urge TOPS-20 administrators NOT to add more than one or two
other gateways to their gateways file, if any.  The MILNET Mailbridge
Gateways were explicitly turned off yesterday to slow the spread of 
the virus.  As you yourself said, their normal reliability is such
that one primary gateway and one backup entry was enough to keep
your host "connected" for several years without running into this
problem.  Presumably, turning off the Mailbridges because of external
circumstances will continue to be a rare event.

The reason for only having one or two entries in the file in the first
place is to reduce the amount of ICMP overhead traffic on Arpanet and 
Milnet.  TOPS-20s periodically "ping" all the gateways on their list.
A few years back, this was adding up to a substantial fraction of all
the traffic on the Arpanet.  While one can argue that adding one more
gateway to one host will result in only a small amount of traffic, it
still seems worth avoiding, when the problem one is fixing is so rare.

Fred Serr
Network Analysis Dept.
BBN Communications
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 04:59:29 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

The flippant response (to the question about why any application
would use funny characters) is that if the system doesn't allow
interaction with a terminal using the entire character set, then 
that system is brain-dead.  (A notable instance is PR1ME which is
fine except there is no way short of calling some really-really-
really-really low-level kernal routines to get a ^J to be read
by a program).

The non-flippant reasponse is "why not?".  Also, what's so standard
about, for instance, ^O.  Yeah some operating systems use that for
special purposes, but nowhere near all of them.  What's so "standard"
about ^S/^Q (another pair which causes headaches for emacs).  For
one thing it's not standard, but it's also rather braindead to have
a system which uses in-band signaling to do flow control.  Not only
is it slow and error prone, it decreases the "bandwidth".

I don't mean to inflame anybody, and I apologize if I have.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 05:30:58 GMT
From:      salzman@RAND.ORG (Isaac)
To:        comp.protocols.tcp-ip
Subject:   Details on the Internet VIRUS


After carefully leaving the sendmail ``hole'' open on our Internet machine
I've been able to track (for the most part) what the virus is doing and
how it's spreading itself.

The C program that is uploaded and compiled is only the start.  After it's
compiled it's run with the following arguments: argv[1] is the Internet
addr of the infecting host, argv[2] is the port to connect to on that host
and argv[3] is the "magic" number. It connects back to the infecting host
and *carefully* transfers 3 files over.  The socket remains open and
/bin/sh is then exec'd so the infecting host can send shell commands to it
after the files are transferred. Following is an excerpt from the log file of
my hacked up version of the .c file that's uploaded:

  virus: pid=6828, args; x15886501 10.4.0.7 29451 15525687
  connection on sockect 0 active
  trying to write to file 'x15901447,sun3.o', len=47165
  file 'x15901447,sun3.o' written!
  trying to write to file 'x3338475,vax.o', len=45734
  file 'x3338475,vax.o' written!
  trying to write to file 'x11091853,l1.c', len=1542
  file 'x11091853,l1.c' written!
  starting up 'snoop' to watch the rest of the socket

"Snoop" is a shell script that's run in place of /bin/sh to capture the
shell commands that are being sent from the infecting host. Following is a
log of the shell commands are being sent:

  PATH=/bin:/usr/bin:/usr/ucb
  rm -f sh
  if [ -f sh ]
  then
  P=x10903971
  else
  P=sh
  fi
  cc -o $P x15901447,sun3.o

  ./$P -p $$ x15901447,sun3.o x3338475,vax.o x11091853,l1.c

  rm -f $P
  cc -o $P x3338475,vax.o

  ./$P -p $$ x15901447,sun3.o x3338475,vax.o x11091853,l1.c

  rm -f $P
  rm -f x15901447,sun3.o $P
  rm -f x3338475,vax.o $P
  rm -f x11091853,l1.c $P

They real key is to find out what ./$P is actually doing. Knowing the
arguments to the program that's uploaded and executed may be 1/2 the battle
there - especially if you're running on a Sun 3 with SunOS 4.0 (let's thank
Sun for the "trace" command).  So it's starting itself again, probably
using the pid ($$) as random seed, the rest of the arguments being the
names of the files to send off to the next victim. It looks real innocent
when you see "(sh)" in a ps listing (note what $P is set to)....

Earlier today Jim Gillogly (jim@rand.org) was able to find a table of
potential passwords that are probably used to crack accounts on the
infected machine. Some other research into the matter strongly suggests
that .rhosts and hosts.equiv files are used to target the next victim (that
seems to be common knowledge). It apparently tries one of two ways to break
into a machine. First it seems to try the rsh port. I've hacked up rshd to
report all outside attempts via syslog. It would consistenly come in over
rsh a minute or so before trying the SMTP port. Terry West (terry@rand.org)
hacked sendmail to report attempts to use the 'debug' command to the SMTP
server and log that with syslog as well, so we get stuff like this:

  Nov  3 18:10:12 rand-unix rsh[4311]: external address detected port=2,fam=1008,addr=10.4.0.7
  Nov  3 18:10:43 rand-unix sendmail[4328]: AA04328: DEBUG set from: SM.UNISYS.COM
  Nov  3 18:43:08 rand-unix rsh[5106]: external address detected port=2,fam=1021,addr=10.2.0.10
  Nov  3 18:43:41 rand-unix sendmail[5126]: AA05126: DEBUG set from: XN.LL.MIT.EDU
  Nov  3 18:55:59 rand-unix rsh[5377]: external address detected port=2,fam=991,addr=128.52.32.14
  Nov  3 18:57:18 rand-unix sendmail[5421]: AA05421: DEBUG set from: XN.LL.MIT.EDU
  Nov  3 19:03:56 rand-unix rsh[5652]: external address detected port=2,fam=1015,addr=10.4.0.7
  Nov  3 19:29:34 rand-unix rsh[6725]: external address detected port=2,fam=1003,addr=10.4.0.7
  Nov  3 19:48:14 rand-unix rsh[7592]: external address detected port=2,fam=996,addr=10.4.0.7
  Nov  3 19:48:46 rand-unix sendmail[7614]: AA07614: DEBUG set from: SM.UNISYS.COM
  Nov  3 19:55:50 rand-unix rsh[7698]: external address detected port=2,fam=1018,addr=10.6.0.94
  Nov  3 19:56:25 rand-unix sendmail[7712]: AA07712: DEBUG set from: UXC.CSO.UIUC.EDU

So that's the scoop, so far. Of course by the time this makes it out to
the tcp-ip list this will be old news, eh? :-) Now to tear apart the
fake "sh"..... Ciao! 

--
* Isaac J. Salzman                                            ----     
* The RAND Corporation - Information Sciences Dept.          /o o/  /  
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138    | v |  |  
* AT&T: +1 213-393-0411 x6421 or x7923 (ISL lab)            _|   |_/   
* ARPA: salzman@RAND.ORG or salzman@rand-unix.ARPA         / |   |
* UUCP: ...!{cbosgd,decvax,sdcrdcf}!randvax!salzman        | |   |     

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 04 Nov 88 08:31:51 GMT
From:      Robert Cole <rhc%rcole.lb.hp.co.uk@RELAY.CS.NET>
To:        Kevin Montgomery <kmont%hpindda%hpcuhb%hp-sde%hpccc%hpl-opus@HPLABS.HP.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: RPC talking OSI?
> 
> 	Has anyone seen a copy of RPC that speaks an OSI protocol
> instead of using UDP?  Anyone at TWG (or anyone else) have anything 
> like this available either now or in the works?

> 					adv -thanks- ance,
> 					  kevin
Have a look at DIS 10148, which is a copy of ECMA 127.
Robert

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 09:23:32 GMT
From:      CLIVE@XX.LCS.MIT.EDU (Clive B. Dawson)
To:        comp.protocols.tcp-ip
Subject:   Network connectivity

MCC.COM (10.3.0.62) has unable to establish connections with a large
percentage of the Internet hosts during the past 24 hours.  I believe
much of this is caused by the fact that a lot of gateways have been
turned off to try and prevent the spread of the Unix virus that's been
going around.  Furthermore it looks like there's a lot of "one-way"
gateways out there.  OUr SMTP listener has had a lot of connections
hanging in SYN.SYN state and timing out, presumably because our SYN's
aren't making it back to the host who is trying to connect to us.

But I really got confused when I discovered that many of the hosts
I couldn't connect to were reachable from other hosts on the 10 net
(e.g. Score and XX).  If anybody can offer one or more explanations for
this, I would very much like to hear about it.  In particular,
what are the possible causes for a host being reachable from 10.a.b.c
but not from 10.x.y.z?  (Note that MCC.COM's "default,preferred"
address IS 10.3.0.62.)  The only explanation I can come up with 
is that something is messed up in the PSN routing tables, and that
this is a problem for the NOC.

Thanks,

Clive
-------

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 10:25:59 GMT
From:      zwang@CS.UCL.AC.UK (Zheng Wang, Ext: 3701)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus posting #3

Keith,

Your mails about the virus are very interesting. I am working
on how to confine faults with a small area. I am very
interested in this virus and would like to know what on earth
it is and how it can effect some many sites.

I will be very grateful if you can send me more information.


Thanks a lot!

Zheng

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Fri, 04 Nov 88 10:25:59 +0000
From:      Zheng Wang (Ext: 3701) <zwang@Cs.Ucl.AC.UK>
To:        bostic (Keith Bostic) <@ucbvax.berkeley.edu:bostic@okeeffe.berkeley.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Virus posting #3
Keith,

Your mails about the virus are very interesting. I am working
on how to confine faults with a small area. I am very
interested in this virus and would like to know what on earth
it is and how it can effect some many sites.

I will be very grateful if you can send me more information.


Thanks a lot!

Zheng
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 13:47:40 GMT
From:      AI.CLIVE@MCC.COM (Clive Dawson)
To:        comp.protocols.tcp-ip
Subject:   Network Connectivity - Part 2

After sending my previous message in which I wondered what would
cause only some hosts on net 10 to be able to communicate with
a certain other hosts, I began doing some systematic testing
to try and determine what the connectivity was really like.

In the process, I discovered the answer to my own question.  It
turns out that all the prime gateways which my TOPS-20 system
knew about were down!  Some years ago, the NIC assigned certain
MILNET gateways to each Arpanet host.  Up until yesterday,
these gateways have always been sufficient to provide all the
redirect info required.  But since all the Milnet gateways apparently
went down because of this virus, my system had nobody left to
ask.

I've added a couple of other non-Milnet prime gateways to
my INTERNET.GATEWAYS file, and all is well.  I suspect there
may be other TOPS-20 systems out there with the same problem,
since the practice of having only one or two entries in
the gateways file was pretty widespread for a while.

Clive
-------

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 14:02:38 GMT
From:      GILBERT@YaleVM.YCC.Yale.Edu
To:        comp.protocols.tcp-ip
Subject:   re: TCP-IP Information

In article <8811010445.AA05324@ucbvax.Berkeley.EDU>, SCOTTY@UOGUELPH.BITNET (Steve Howie) writes:
 
>I Believe IBM are making plans to sell this book through their regular
>documentation channels. Kinda neat concept, eh? :)
 
It would be, except that SC09-1302 (the IBM order number for the
Comer book) costs $211.  This is a neat marketing concept
for a book which costs $35 in a book store.  Come on IBM, get serious!

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 14:52:28 GMT
From:      goldstei@MITRE.ARPA (Steve Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Network connectivity

Clive,

I have had similar experiences a few weeks ago with a Princeton host on
arpanet and reachable thru nsfnet via jvnc.  The telco line from jvnc to pri
on broke, and there was no way in hell that I could get through to princeton
via my normal methods.  Then, I logged in to a machine in Wisconsin that
happened to be on arpanet and, voila!  there I was getting into the princeton
host!  Seems that the new routes did not age properly on jvnc's EGP-server.
They should have shown the new route to princeton via arpanet, but they did not.

I have no idea in this current swiss cheese Internet whether or not similar
things could be happening, but certainly the gated, EGP and other things that
usually hum must be going bump in the night!

Keep the faith,

Steve Goldstein
normally: goldstein@ames.arc.nasa.gov (which is down!)

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:04:22 GMT
From:      schoff@STONEWALL.NYSER.NET
To:        comp.protocols.tcp-ip
Subject:   possible origin of the virus/phage


>From what I have seen this virus/phage sounds familiar.  I believe
that there is a "recent" doctoral thesis from MIT that describes
this.  This thesis included an implementation that was unleashed
in a test environment.  This is 2nd hand information and I have
not seen the thesis (in fact it was not clear to me at the time
if it would be publicly "published".)  From the description given
to me it is not exactly like was was tested since it did not include
the sendmail injection mechanism and relied on another injection
mechanism.

There must have been some DNA exchange from somewhere.

Marty

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:05:03 GMT
From:      fbraab@cosmo.UUCP (Leuze electronic)
To:        comp.protocols.tcp-ip
Subject:   PC-NFS Telnet with colours ?

Hi there,
does anybody know if there is a TELNET client compatible to SUN's
PC-NFS which works with ANSI colours or 
does anybody know how to treat the original to interpret the
ANSI.SYS colour sequences ?
I have a PPS - System here in my company, running on a Sun 386i with
PC-AT-EGA-Telnet Terminals.
The program is able to produce colour on an AT, but unfortunately not with
the Sun - Telnet.
                                           Fritz B. Raab
                                           fbraab@cosmo.UUCP

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:09:39 GMT
From:      fserr@ALEXANDER.BBN.COM (Frederick E Serr BBNCC 20/666 x2474)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Connectivity - Part 2

I would urge TOPS-20 administrators NOT to add more than one or two
other gateways to their gateways file, if any.  The MILNET Mailbridge
Gateways were explicitly turned off yesterday to slow the spread of 
the virus.  As you yourself said, their normal reliability is such
that one primary gateway and one backup entry was enough to keep
your host "connected" for several years without running into this
problem.  Presumably, turning off the Mailbridges because of external
circumstances will continue to be a rare event.

The reason for only having one or two entries in the file in the first
place is to reduce the amount of ICMP overhead traffic on Arpanet and 
Milnet.  TOPS-20s periodically "ping" all the gateways on their list.
A few years back, this was adding up to a substantial fraction of all
the traffic on the Arpanet.  While one can argue that adding one more
gateway to one host will result in only a small amount of traffic, it
still seems worth avoiding, when the problem one is fixing is so rare.

Fred Serr
Network Analysis Dept.
BBN Communications

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:28:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Network Connectivity - Part 2

Clive,

I discovered the same problem last night caused by the fact that the
prime gateways were down (either deliberately taken down, looped off
the net or powered down by the NOC) in an effort to compartmentalize
the spread of the worm (not virus).  It is not just the TOPS20 hosts
which depend on these gateways for ICMP REDIRECTs - all hosts using
the prime gateways do.  Once I added a couple of other gateways,
everything started flowing again everywhere except across the MIL-ARPA
gateways (as I believe was the intent in shutting off those gateways).

The lesson to be learned from this is that we should have at least one
other non-MIL-ARPA prime gateway in the list of assigned gateways
should it become necessary to isolate those two nets from each other
in the future.

--Frank

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:37:05 GMT
From:      mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield)
To:        comp.protocols.tcp-ip
Subject:   ftp PASSIVE mode (PASV)

In article <8811012118.AA06767@vax.ftp.com> joel@VAX.FTP.COM (Joel Gartland) writes:
>	Should a ftp server, after receiving the PASV command, remain in
>passive mode for the rest of the ftp session, or just for the next transfer?
>It doesn't seem to be stated either way in the RFC (959).

     Here are some extracts from RFC-959:

#         PASSIVE (PASV)
#
#            This command requests the server-DTP to "listen" on a data
#            port (which is not its default data port) and to wait for a
#            connection rather than initiate one upon receipt of a
#            transfer command.  The response to this command includes the
#            host and port address this server is listening on.

     This clearly indicates an action to be taken upon receipt of a PASV
command.  Its result is to place the receiving server in a state listening
for a connection.  This would only affect that transfer since the server
would not normally be in a passive listening state for a data transfer.

#      When data is to be transferred between two servers, A and B (refer
#      to Figure 2), the user-PI, C, sets up control connections with
#      both server-PI's.  One of the servers, say A, is then sent a PASV
#      command telling him to "listen" on his data port rather than
#      initiate a connection when he receives a transfer service command.
#      When the user-PI receives an acknowledgment to the PASV command,
#      which includes the identity of the host and port being listened
#      on, the user-PI then sends A's port, a, to B in a PORT command; a
#      reply is returned.  The user-PI may then send the corresponding
#      service commands to A and B.  Server B initiates the connection
#      and the transfer proceeds.  The command-reply sequence is listed
#      below where the messages are vertically synchronous but
#      horizontally asynchronous:
#
#
#         User-PI - Server A                User-PI - Server B
#         ------------------                ------------------
#         
#         C->A : Connect                    C->B : Connect
#         C->A : PASV
#         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
#                                           C->B : PORT A1,A2,A3,A4,a1,a2
#                                           B->C : 200 Okay
#         C->A : STOR                       C->B : RETR
#                    B->A : Connect to HOST-A, PORT-a
#
#                                Figure 3

     Note that the PASV command is followed by a STOR or RETR command.
This implies that its domain of effect covers the data connection only.

     BTW - before I get flamed - It is true that this is a slightly ad-hoc
conclusion and I recognize it as such.  That's why I said IMPLIED.

     When taken as a whole, there is strong indication that the PASV command
is on a connection by connection basis.  Note too that if you assume such
in the client, you are safe.  If you assume that it is on a session basis in
the client you may well get FRIED when you find a server that assumes a
connection basis.  Implimenting the PASV command with a session basis in the
server could well be an unnecessary exercise in frustration.

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:38:51 GMT
From:      rls@telebit.UUCP (Richard Siegel)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: Trailblazer detailed info wanted

In article <1615@sater.cs.vu.nl>, sater@cs.vu.nl (Hans van Staveren) writes:
> Not too long ago there was an article in one of these groups
> explaining in gory details the working of the Telebit Trailblazer.

OK, due to popular demand (actually, several other people have requested this
via mail, too), I am reposting this to this newsgroup. Please forgive me if
you've already read it, and are tired of hearing about Telebit TrailBlazers.

Otherwise, this should provide you with a basic idea of how the modem works,
and may prevent confusion when talking about modulation technologies. Note
that we make no claim that this is "unbiased" - it describes our product.

Enjoy!

==========================================================================
Richard Siegel                 Phone:                       (415) 969-3800
Product Manager                UUCP:  {sun,uunet,ames,hoptoad}!telebit!rls
Telebit Corporation            ARPA:  telebit!rls@ames.ARPA
                             
                "We are, after all, professionals"...HST
==========================================================================

 
========================================================================
Telebit Corporation           Revision 1.00                  07 APR 1988
========================================================================

  A BRIEF TECHNICAL OVERVIEW OF THE TELEBIT TRAILBLAZER MODEM

     By Michael Ballard, UNIX Program Manager, Telebit Corp.

Before starting on this document, a caveat: this document is intended
to address many of the questions and comments about the Telebit
TrailBlazer that have appeared from the user community. We are
striving to provide as much information as possible, in such a
way that will be useful to the widest group of readers. This is
NOT intended to be a Marketing Article, but rather a technical
overview for the more sophisticated reader. Its purpose is to
inform, not to sell product. If anyone is offended by Telebit 
taking this action, please mail directly to me first, to avoid
cluttering the newsgroup. Thank you.

I would like to provide some background for Unix users considering 
the use of Telebit's TrailBlazer Plus high speed dialup modem.  
I served as project manager and principal programmer for 
Telebit's protocol support developement.  The UUCP "g", Kermit,
Xmodem and Ymodem protocols are directly supported in the TrailBlazer 
modem's firmware.  Peter Honeyman, co-developer of ATT's
HoneyDanBer/BNU UUCP, coded those portions of the TrailBlazer
firmware which support the "g" protocol. 

The Telebit modem employs a patented multicarrier modulation scheme 
coined DAMQAM (Dynamically Adaptive Multicarrier Quadrature Amplitude 
Modulation).  A CRC-16 based sliding window protocol with selective 
retransmission runs on top of this modulation scheme insuring data 
integrity across the phone line.  This telephone line protocol is 
known as the Packetized Ensemble Protocol or PEP.  PEP is the 
trademark by which all modems employing this technique can be 
recognized.

This technique (DAMQAM) divides the voice bandwidth into 511 
individual channels each capable of passing 2, 4, or 6 bits per 
baud based on the measured characteristics of the individual 
frequencies associated with each channel.  On a typical phone
connection, the modem uses a subset of about 400 of those channels.

Each time the modem connects to a circuit established on the dialup 
Public Switched Telephone Network (PSTN), the TrailBlazer measures the
quality of the connection, and determines the usable subset of the 511 
carriers.  The aggregate sum of bits modulated on this subset of 
carriers multiplied times the baud rate yields a bit per second 
rate that on a local telephone connection (i.e. round trip through 
your local telco) is 18031 bps.  This 18031 bps is then reduced by
about 20% to allow for the CRC overhead, to about 14400 bps of data
throughput. 

Long distance line quality varies with location and carrier, but you 
can expect this number to be in the 10000 to 17000 bps range under 
most conditions domestically.  By choosing a high quality long 
distance carrier, you will ensure the best throughput overall.

 

The modem operates at 7.35 and 88.26 baud, transparently changing 
baud rates to accomodate the pace and quantity of data traffic. 
When in "interactive mode" the modem sends data using 11 msec 
packets (which run at 88.26 baud). Each packet contains 15 bytes 
of data. In "file transfer mode" the modem uses 136 msec packets 
(that transfer at 7.35 baud) that contain 256 bytes of data. 
The TrailBlazer decides which packet size to use on an ongoing 
dynamic basis. No intervention from the user is required. 

At lower speeds, such as 300, 1200, and 2400 bps, the TrailBlazer
provides emulation (performed in the DSP section, not by a "chip"
modem) to support these standards. The 300 bps standard is called
Bell 103C. At 1200 bps, two standards exist, Bell 212A and CCITT 
V.22. Both are supported. At 2400 bps, the standard is called 
CCITT V.22 bis. These speeds are all available with or without 
MNP Class 3 Error Correction.

The TrailBlazer employs a Motorola 68000 and a Texas Instuments 
TMS32010 digital signal processor to accomplish this performance.  
Because of this substantial computer horsepower (about 7.5 MIPS), 
the TrailBlazer is really a communications processor, rather than 
a conventional modem.

The software defined architecture produces a flexible product platform
that allows broad feature development capabilities while allowing the 
product's installed base to benefit from those developments by installing
upgrade EPROM sets.

All four protocols (Kermit, Xmodem/Ymodem, UUCP), V.22bis support, MNP at 
low speeds, multiple releases to improve the interactive performance 
(earlier TrailBlazers utilized only one baud rate), a multitude of 
RS-232 behavior related features, leased line capabilities, remote 
command processor access, echo suppressor compensation, increased 
data rates, and a myriad of user requested features have found their 
way into current production modems and are available to earlier 
revisioned modems via the EPROM uprgrade kits.

PEP modems provide a full duplex serial interface to an attached computer, 
however they employ a half duplex implementation on the telephone line.
Telebit refers to this half duplex technique as "Adaptive Duplex".  
As the name implies, the ownership of the line (i.e. the ability 
to transmit) adapts to the quantity of data available to send at 
any single moment.  Maximum efficiency is achieved by sending data 
in a nonstop data stream at 19.2Kbps relying on serial interface 
flow control to moderate the data flow into and out of the modem.

This allows the maximum amount of data to be available every time 
a transmitting modem takes ownership of the line.  In this way the 
modem, not the DTE, controls the line turnarounds.  The protocol 
provides a ceiling at about 3k of sent data before a transmitting 
modem must give up its turn and allow the other modem an opportunity 
to send. A continuous 19.2Kbps data flow into the modem is required 
to ensure that there is always 3k of data to send each time a 
transmitting modem takes its turn. The serial interface speed must 
exceed the telephone line speed, potentially 18,031 bps, or the maximum 
efficiency of the modems can not be reached). 

 

UUCP's "g" protocol behavior on dialup lines was a clear contradiction 
of the desired behavior with the PEP protocol.  "g" sends 3 small data 
packets at time and then waits for the remote UUCP to ACK or NAK their 
receipt.  The resulting throughput when using UUCP and "g" with the 
TrailBlazer was only a little better than a standard 1200 bps modem.  
This was unacceptable. Telebit decided to improve UUCP performance.

The TrailBlazer can be configured to "spoof" the protocol by setting 
a register (S111) to one of several values. The spoof can support four 
different protocols: UUCP "g", Xmodem, Ymodem, and Kermit.

"Spoof" means to fool the various protocols into thinking that they 
are getting their acknowledgment packets from the remote computer, 
when in reality they are getting them from the modem.

All of these protocols are what are commonly referred to as
"send and wait" protocols. This type of protocol builds a packet 
in computer A, sends it out through the modems, where it is received by 
computer B. Next, computer B looks at the packet to determine whether 
or not it arrived intact.  If it did, it sends an ACK (acknowledgement) 
packet back to computer A. If it did not arrive intact, it sends a NAK 
(non-acknowledgement) packet. In either case, computer A can't send the 
next packet out until it gets the ACK from the first packet. This is slow! 

Since our modems are error-free between the modems, the only place data 
could get "broken" is between the modems and their respective computers. 
Let me draw the connection diagram below:

          Ca <======> Ta <----------------> Tb <======> Cb

          Ca = Computer A                   Cb = Computer B 
          Ta = Telebit Modem A              Tb = Telebit Modem B

         ====== RS-232 Cable
         ------ Phone Line

When we are running our protocol support, we look at the packet coming 
from Ca.  Ta checks the packet for validity and sends the ACK or NAK.
Ca can begin building the next packet immediatly upon receipt
of Ta's ACK.  This results in Ca building and sending packets as fast as it
can.  Many packets are now forwarded to Tb.   Tb now delivers the packets
to Cb, observing the rules of the protocol.  Tb will deliver the next packet
or retransmit the previous packet based on the ACK or NAK received from Cb.
Cb ACKs and NAKs are then thrown away so as not to return to Ca.

Protocol support can be configured to run in parallel with data compression
enabled.  The real world result of this is to increase protocol transfers
from 2-3 Kbps to 10-19.2 Kbps. 

This covers most of the commonly asked questions about the TrailBlazer. 
If any of the above information is unclear, or you have questions 
regarding other aspects of modem technology or performance, send mail to:

	Michael Ballard
	Telebit Corporation
	1345 Shorebird Way
	Mountain View, CA 94043
	{ames, uunet, hoptoad, sun, dwon}!telebit!modems

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:41:47 GMT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Re: Network Connectivity - Part 2

Clive,

Right.  Here's the rest of the story.  XX and Score are configured
differently than MCC or NIC, because while all four are multi-homed
hosts, XX and Score are not the sole contact points between the nets
to which they are connected.  Eg, XX is connected to nets 10 and 18,
but so is GW.LCS.MIT.EDU.  A multi-homed TOPS-20 in this configuration
needs more entries in its INTERNET.GATEWAYS file than just its IMP's
two assigned "mailbridge" gateways, eg, XX's also lists GW,
KLUDGE.AI.MIT.EDU, SLUDGE.LCS.MIT.EDU, and SEWAGE.MIT.EDU.  Yesterday
XX ended up routing all of its "default" traffic via GW.LCS.MIT.EDU
after it gave up on IMP44's assigned gateways.  I assume something
similar happened to Score.

Is the "eager pinger" problem believed to be fixed?  If I remember
correctly, that's where the practice of having only two live core
gateways known per host came from.  The NIC has a file online (in
NETINFO:, I think) explaining this, but it was never clear to me if
the underlying problem was really fixed or simply toned down to an
acceptable level if everybody stuck to the two gateway rule.

--Rob
-------

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 17:43:52 GMT
From:      bbn.com!mfidelma@bbn.com  (Miles Fidelman)
To:        tcp-ip@sri-nic.arpa
Subject:   IP for the MAC

Folks,

Does anyone have a version of IP for the MAC that can run as a background
task rather than as part of an application such as NCSA Telnet?

What I have in mind is as follows:

I would like to be able to send and recieve IP packets over Appletalk from a
program running within Allegro Common Lisp.  I believe this will require a
background or interrupt process that receives incoming packets and then passes
them to the Lisp environment as well as the code for sending packets.

Allegro CL has a facility for linking code in MPW object format. Allegro
can also receive system events and generate traps.

So.....if you any ideas or pieces of the solution, please send me email. I'll
post what I find out.

Thanks much,

Miles Fidelman
mfidelman@bbn.com
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 18:47:23 GMT
From:      haas@wasatch.UUCP (Walt Haas)
To:        comp.protocols.tcp-ip
Subject:   Re: Rlogin vs Telnet in terminal servers

In article <1020@murtoa.cs.mu.oz.au>, kre@cs.mu.oz.au (Robert Elz) writes:
> The most likely reason for wanting "rlogin support" in a terminal
> server is 100% unrelated to protocols, automatic login (which is
> typically not applicable anyway) , terminal type negotiation, or
> any of the rest of all of this "can telnet really do ...?" stuff.
> 
> The real reason is that users have become trained that the way
> one connects to a destination host is by using
> 
> 	rlogin host

I couldn't agree with you less... I don't think anybody around here cares
what they have to type to get there, the issue is transparency.  The TELNET
spec is written so that almost minimal subset, no matter how useless, can
be advertised as a TELNET implementation.  Combined with a total lack of
conformance testing, we have a protocol "standard" that probably does more
harm than good.  By contrast rlogin code is usually a copy of the Berkeley
code so the implementations are a lot more consistent, and the functionality
is a lot more transparent to the user.

Cheers  -- Walt Haas    haas@cs.utah.edu    utah-cs!haas

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 19:45:00 GMT
From:      glr@WHEATIES.AI.MIT.EDU (Jerry Roylance)
To:        comp.protocols.tcp-ip
Subject:   Virus


A method of finding the culprit:

NYT implies the user is a CS student.  The files that compose his system
were stored on disk in his directory; the program is complicated, so the
development probably took a long time; the files were probably stored on
a public machine.

So the first step might be to (quietly) grep unix filesystems for some
appropriate (cleartext) substrings that would appear in his files (ie,
pieces of the infecting shell script).  Anyone who owned such files
before the infection would be suspect.

The internet reaction has probably scared the author, so he has
presumably deleted the relevant online files, but probably does not have
access to his system's backup tapes.  Scanning those tapes (levels 0-9)
for say Monday or Tuesday would probably turn something up.

Coordinating the search effort would be difficult and possibly not worth
it.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 20:08:19 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  possible origin of the virus/phage

Would you like to mention what the other proposed virus's injection
mechanism was so we can immunize against it?

	Stuart

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 20:52:52 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   RFC on Internet "Virus", Please


Hi.

I would like to have an RFC written about the Internet "Virus" event to 
document exactly what actually happened.  Virus is in quotes since this
was technically a Worm.  The RFC should describe features were used, what
tricks were used, and how it worked.  Also how it was stopped, and what 
lessons were learned.  All the history, the story of its spread and its
defeat.  This RFC should include all the gory details.   This RFC can then
be the basis for summary articles in magazines and journals.  I think that
this RFC should have many authors, as many people contributed to the efforts
to understand and stop this program.

--jon.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 22:04:57 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   V1.70 (Virus (really worm) posting #4)

Subject: Virus (really worm) posting #4
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
	This is hopefully the final posting we'll make regarding
	the worm that was released onto the Internet.  MIT (as I
	understand it, a combination of people from Project Athena,
	the Lab for Computer Services, the Networking Group, and
	SIPB), and members of the Berkeley UNIX Workshop have both
	decompiled copies of the worm (into about 2000 lines of C).

	As of this time, we believe that there were three methods
	of attack; exploiting software bugs in sendmail and fingerd,
	and by guessing (albeit fairly intelligently) passwords.
	We believe that the fixes already posted for sendmail and
	fingerd are sufficient to stop the worm from entering your
	system; as far as guessing passwords, there's not much you
	can do but educate your users.  We also recommend renaming
	``/bin/ld'' for the next few days, meanwhile checking your
	machines for occurrences of the worm.  This should keep it
	from moving around on your local nets.

	We are reposting fingerd(8), since it apparently got munged
	before arriving at some sites.  

	Complete copies of all postings regarding the worm are
	available by anonymous ftp from ucbvax.berkeley.edu and
	ucbarpa.berkley.edu, as ``pub/virus.patch''.
	
	We believe that the virus cannot be propagated by uucp.

	In the Berkeley tradition of fixing other people's software,
	and in the general interests of software portability and
	matainability, we have provided three fixes for those
	individuals wishing to continue to run the worm on their
	systems.  To apply theses fixes, discompile the worm 
	and then use patch.

	Note: 
		THESE FIXES ARE PROVIDED ``AS IS'' AND WITHOUT ANY
		EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT
		LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY
		AND FITNESS FOR A PARTICULAR PURPOSE.

*** if_init.c.old	Fri Nov  4 14:01:54 1988
--- if_init.c	Fri Nov  4 14:02:10 1988
***************
*** 39,45 ****
  				break;
  		}
  		for (; j >= nifs; nifs++) {
! 			bzero(&ifs[0], sizeof(ifs[j]));
  			strcpy(ifs[nifs].o0, ifreqs[i].ifr_name);
  			strcpy(ifrq.ifr_name, ifreqs[i].ifr_name);
  			if (ioctl(s, SIOCGIFFLAGS, &ifrq) < 0) {
--- 39,46 ----
  				break;
  		}
  		for (; j >= nifs; nifs++) {
! 			/* use offset of `j', not zero! */
! 			bzero(&ifs[j], sizeof(ifs[j]));
  			strcpy(ifs[nifs].o0, ifreqs[i].ifr_name);
  			strcpy(ifrq.ifr_name, ifreqs[i].ifr_name);
  			if (ioctl(s, SIOCGIFFLAGS, &ifrq) < 0) {


*** main.c.old	Fri Nov  4 12:49:05 1988
--- main.c	Fri Nov  4 12:49:26 1988
***************
*** 67,73 ****
  	if (pgrp != 0) {
  		if (getpgrp(getpid()) == pgrp)
  			setpgrp(getpid(), getpid());
! 		kill(pgrp, SIGKILL);
  	}
 doit();
  }
--- 67,73 ----
  	if (pgrp != 0) {
  		if (getpgrp(getpid()) == pgrp)
  			setpgrp(getpid(), getpid());
+		/* they really want to kill the process group! */
! 		killpg(pgrp, SIGKILL);
  	}
 doit();
  }

*** fxread.c.old	Fri Nov  4 12:53:36 1988
--- fxread.c	Fri Nov  4 12:54:49 1988
***************
*** 5,11 ****
  {
  	struct timeval tv;
  	int cnt, mask;
! 	int some_uninitialized_var;
  
  	if (cnt = 0; cnt < buflen; ++cnt) {
  		mask = 1 << fd;
--- 5,11 ----
  {
  	struct timeval tv;
  	int cnt, mask;
! 	int some_uninitialized_var = use_lint_twit;
  
  	if (cnt = 0; cnt < buflen; ++cnt) {
  		mask = 1 << fd;


# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	fingerd.8
#	fingerd.c
#	Makefile
#
echo x - fingerd.8
sed 's/^X//' >fingerd.8 << 'END-of-fingerd.8'
X.\" Copyright (c) 1980 The Regents of the University of California.
X.\" All rights reserved.
X.\"
X.\" Redistribution and use in source and binary forms are permitted
X.\" provided that the above copyright notice and this paragraph are
X.\" duplicated in all such forms and that any documentation,
X.\" advertising materials, and other materials related to such
X.\" distribution and use acknowledge that the software was developed
X.\" by the University of California, Berkeley.  The name of the
X.\" University may not be used to endorse or promote products derived
X.\" from this software without specific prior written permission.
X.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X.\" WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X.\"
X.\"	@(#)fingerd.8	6.2 (Berkeley) 9/19/88
X.\"
X.TH FINGERD 8 "September 19, 1988"
X.UC 6
X.SH NAME
Xfingerd \- remote user information server
X.SH SYNOPSIS
X.B /etc/fingerd
X.SH DESCRIPTION
X.I Fingerd
Xis a simple protocol based on RFC742 that provides an interface to the
XName and Finger programs at several network sites.
XThe program is supposed to return a friendly,
Xhuman-oriented status report on either the system at the moment
Xor a particular person in depth.
XThere is no required format and the
Xprotocol consists mostly of specifying a single ``command line''.
X.PP
X.I Fingerd
Xlistens for TCP requests at port 79.
XOnce connected it reads a single command line
Xterminated by a <CRLF> which is passed to
X.IR finger (1).
X.I Fingerd
Xcloses its connections as soon as the output is finished.
X.PP
XIf the line is null (i.e. just a <CRLF> is sent) then 
X.I finger
Xreturns a ``default'' report that lists all people logged into
Xthe system at that moment.
X.PP
XIf a user name is specified (e.g. eric<CRLF>) then the
Xresponse lists more extended information for only that particular user,
Xwhether logged in or not.
XAllowable ``names'' in the command line include both ``login names''
Xand ``user names''.
XIf a name is ambiguous, all possible derivations are returned.
X.SH SEE ALSO
Xfinger(1)
X.SH BUGS
XConnecting directly to the server from a TIP
Xor an equally narrow-minded TELNET-protocol user program can result
Xin meaningless attempts at option negotiation being sent to the
Xserver, which will foul up the command line interpretation.
X.I Fingerd
Xshould be taught to filter out IAC's and perhaps even respond
Xnegatively (IAC WON'T) to all option commands received.
END-of-fingerd.8
echo x - fingerd.c
sed 's/^X//' >fingerd.c << 'END-of-fingerd.c'
X/*
X * Copyright (c) 1983 The Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley.  The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xchar copyright[] =
X"@(#) Copyright (c) 1983 The Regents of the University of California.\n\
X All rights reserved.\n";
X#endif /* not lint */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)fingerd.c	5.3 (Berkeley) 11/3/88";
X#endif /* not lint */
X
X/*
X * Finger server.
X */
X#include <sys/types.h>
X#include <netinet/in.h>
X#include <stdio.h>
X#include <ctype.h>
X
Xmain(argc, argv)
X	int argc;
X	char *argv[];
X{
X	register char *sp;
X	char line[512];
X	struct sockaddr_in sin;
X	int i, p[2], pid, status;
X	FILE *fp;
X	char *av[4];
X
X	i = sizeof (sin);
X	if (getpeername(0, &sin, &i) < 0)
X		fatal(argv[0], "getpeername");
X	if (fgets(line, sizeof(line), stdin) == NULL)
X		exit(1);
X	sp = line;
X	av[0] = "finger";
X	for (i = 1;;) {
X		while (isspace(*sp))
X			sp++;
X		if (!*sp)
X			break;
X		if (*sp == '/' && (sp[1] == 'W' || sp[1] == 'w')) {
X			sp += 2;
X			av[i++] = "-l";
X		}
X		if (*sp && !isspace(*sp)) {
X			av[i++] = sp;
X			while (*sp && !isspace(*sp))
X				sp++;
X			*sp = '\0';
X		}
X	}
X	av[i] = 0;
X	if (pipe(p) < 0)
X		fatal(argv[0], "pipe");
X	if ((pid = fork()) == 0) {
X		close(p[0]);
X		if (p[1] != 1) {
X			dup2(p[1], 1);
X			close(p[1]);
X		}
X		execv("/usr/ucb/finger", av);
X		_exit(1);
X	}
X	if (pid == -1)
X		fatal(argv[0], "fork");
X	close(p[1]);
X	if ((fp = fdopen(p[0], "r")) == NULL)
X		fatal(argv[0], "fdopen");
X	while ((i = getc(fp)) != EOF) {
X		if (i == '\n')
X			putchar('\r');
X		putchar(i);
X	}
X	fclose(fp);
X	while ((i = wait(&status)) != pid && i != -1)
X		;
X	return(0);
X}
X
Xfatal(prog, s)
X	char *prog, *s;
X{
X	fprintf(stderr, "%s: ", prog);
X	perror(s);
X	exit(1);
X}
END-of-fingerd.c
echo x - Makefile
sed 's/^X//' >Makefile << 'END-of-Makefile'
X#
X# Copyright (c) 1988 Regents of the University of California.
X# All rights reserved.
X#
X# Redistribution and use in source and binary forms are permitted
X# provided that the above copyright notice and this paragraph are
X# duplicated in all such forms and that any documentation, advertising
X# materials, and other materials related to such redistribution and
X# use acknowledge that the software was developed by the University
X# of California, Berkeley.  The name of the University may not be
X# used to endorse or promote products derived from this software
X# without specific prior written permission.  THIS SOFTWARE IS PROVIDED
X# ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
X# WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND
X# FITNESS FOR A PARTICULAR PURPOSE.
X#
X# @(#)Makefile	5.1 (Berkeley) 9/19/88
X#
X
XCFLAGS=	-O
XLIBC=	/lib/libc.a
XSRCS=	fingerd.c
XOBJS=
XMAN=	fingerd.0
X
Xall: fingerd
X
Xfingerd: ${LIBC}
X	${CC} -o $@ ${CFLAGS} $@.c
X
Xclean:
X	rm -f ${OBJS} core fingerd
X
Xcleandir: clean
X	rm -f ${MAN} tags .depend
X
Xdepend: ${SRCS}
X	mkdep -p ${CFLAGS} ${SRCS}
X
Xinstall: ${MAN}
X	install -s -o bin -g bin -m 755 fingerd ${DESTDIR}/etc/fingerd
X	install -c -o bin -g bin -m 444 fingerd.0 ${DESTDIR}/usr/man/cat8
X
Xlint: ${SRCS}
X	lint ${CFLAGS} ${SRCS}
X
Xtags: ${SRCS}
X	ctags ${SRCS}
END-of-Makefile
exit

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 23:04:43 GMT
From:      salzman@RAND.ORG (Isaac)
To:        comp.protocols.tcp-ip
Subject:   A look inside the Internet VIRUS


Hi again folks! I've had some mild success at poking inside the virus using
Sun's trace command on a Sun 3/50 running SunOS4.0.  YP had to be shutdown
for this to be usefull and of course all routes were deleted so it couldn't
propagate anywhere outside the machine. This machine had a relatively small
/etc/hosts and /etc/passwd file so it did its thing pretty quickly. To
really see what it's doing the best scenario would be to run it on a network
with a very small number of other machines (and no gateways to other nets!)
to give it a chance to actually connect to something. What I did get was
interesting though it only tells only a partial story.  Keeping up with it
was tricky since it would fork occasionally and exit, so I'd have to start
trace up and attach to that new process pretty quickly to see anything
happen. In this run it didn't look for individual .rhosts files (though it
looked at .forward files). My feeling is that it would look at .rhosts after
it's cracked the password for that person. It's not clear from this where
password cracking would happen either since a lot of that doesn't require
system calls. We have a disassembly of the thing as well and it's got a few
of its own routines to do password cracking (replacements for stuff allready
resident in UNIX). So here are some excerpts from trace with some redunancy
edited out and some comments embedded comments. Enjoy!! 

13:20:35 gettimeofday (0xefffce0, 0) = 0
13:20:36 getpagesize () = 8192
13:20:36 brk (0x29298) = 0
13:20:36 brk (0x2b29c) = 0
13:20:36 setrlimit (4, 0xefffcf4) = 0
13:20:36 sigvec (13, 0xefffcac, 0xefffcd8) = 0
13:20:36 open ("x15053677,vax.o", 0, 06) = 3
13:20:36 fstat (3, 0xefffca4) = 0
13:20:36 brk (0x3729c) = 0
13:20:36 read (3, "".., 45734) = 45734
13:20:37 close (3) = 0
13:20:38 unlink ("x15053677,vax.o") = 0
13:20:38 open ("x15901447,sun3.o", 0, 06) = 3
13:20:38 fstat (3, 0xefffca4) = 0
13:20:38 brk (0x4329c) = 0
13:20:38 read (3, "".., 47165) = 47165
13:20:38 close (3) = 0
13:20:39 unlink ("x15901447,sun3.o") = 0
13:20:39 open ("x11091853,l1.c", 0, 06) = 3
13:20:39 fstat (3, 0xefffca4) = 0
13:20:39 read (3, "#include <stdio.h>\n#include <sys".., 1542) = 1542
13:20:39 close (3) = 0
13:20:39 unlink ("x11091853,l1.c") = 0
13:20:39 close (0) = 0
13:20:39 close (1) = 0
13:20:39 close (2) = 0
13:20:39 close (3) = -1 EBADF (Bad file number)
.
.
13:20:39 close (31) = -1 EBADF (Bad file number)
13:20:39 unlink ("sh") = 0
13:20:40 unlink ("sh") = -1 ENOENT (No such file or directory)
# unlink itself and make sure it was done!
13:20:40 unlink ("/tmp/.dumb") = -1 ENOENT (No such file or directory)
13:20:40 socket (2, 1, 0) = 0
13:20:40 ioctl (0, 0xc0086914, 0xefffce4) = 0
13:20:40 ioctl (0, 0xc0206911, 0xefffb34) = 0
13:20:40 ioctl (0, 0xc020690d, 0xefffb34) = 0
13:20:40 ioctl (0, 0xc0206919, 0xefffb34) = 0
13:20:40 ioctl (0, 0xc0206911, 0xefffb34) = 0
13:20:40 ioctl (0, 0xc020690d, 0xefffb34) = 0
13:20:40 getpid () = 6077
13:20:40 getpgrp (6077) = 6076
13:20:40 kill (70, 9) = -1 EPERM (Not owner)
# kill its parent process (i gave it a pid it couldn't kill)
13:20:40 gettimeofday (0xefffccc, 0) = 0
13:20:40 getdtablesize () = 64
13:20:40 pipe (0xefffccc) = 1
13:20:40 vfork () = 6079
13:20:40 close (2) = 0
13:20:40 getdtablesize () = 64
13:20:40 ioctl (1, 0x40125401, 0xefffae4) = -1 EOPNOTSUPP (Operation not supported on socket)
13:20:40 fstat (1, 0xefffb10) = 0
13:20:41 read (1, "Routing tables\nDestination      ".., 4096) = 167
# this is output from "netstat -r"
13:20:44 read (1, "", 4096) = 0
13:20:44 - SIGCHLD (20)
13:20:44 close (1) = 0
13:20:44 sigblock (0x7) = 0
13:20:44 wait4 (0, 0xefffb78, 0, 0) = 6079
13:20:44 sigsetmask (0) = 0x7
13:20:44 open ("/etc/hosts", 0, 0666) = 1
13:20:44 lseek (1, 0, 0) = 0
13:20:44 getdomainname ("".., 256) = 0
13:20:44 getpid () = 6077
13:20:44 open ("/var/yp/binding/isltest.rand.org".., 0, 0) = 2
13:20:44 flock (2, 06) = 0
13:20:44 close (2) = 0
13:20:44 socket (2, 1, 0) = 2
13:20:45 connect (2, "".., 16) = 0
13:20:45 close (2) = 0
13:20:45 gettimeofday (0xefff9f4, 0) = 0
13:20:45 getpid () = 6077
13:20:45 socket (2, 2, 17) = 2
13:20:45 getpid () = 6077
13:20:45 bind (2, "".., 16) = -1 EACCES (Permission denied)
13:20:45 ioctl (2, 0x8004667e, 0xefff9c0) = 0
13:20:45 sendto (2, "".., 56, 0, 0x42a84, 16) = 56
13:20:45 getdtablesize () = 64
13:20:45 select (64, 0xefff9dc, 0, 0, 0x42a98) = 1
13:20:45 recvfrom (2, "".., 400, 0, 0xefff9ac, 0xefff9fc) = 28
13:20:45 close (2) = 0
13:20:45 close (2) = -1 EBADF (Bad file number)
13:20:45 socket (2, 2, 0) = 2
13:20:45 bind (2, "".., 16) = 0
13:20:45 close (2) = 0
13:20:45 ioctl (1, 0x40125401, 0xefffaa0) = -1 ENOTTY (Inappropriate ioctl for device)
13:20:45 fstat (1, 0xefffacc) = 0
13:20:45 brk (0x4729c) = 0
13:20:45 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:45 read (1, "", 8192) = 0
13:20:45 pipe (0x1) = 2
13:20:45 vfork () = 6081
13:20:45 close (3) = 0
13:20:45 ioctl (2, 0x40125401, 0xefff948) = -1 EOPNOTSUPP (Operation not supported on socket)
13:20:46 fstat (2, 0xefff974) = 0
13:20:46 read (2, "Routing tables\nDestination      ".., 4096) = 167
13:20:47 read (2, "", 4096) = 0
13:20:47 close (2) = 0
13:20:48 - SIGCHLD (20)
13:20:48 sigblock (0x7) = 0
13:20:48 wait4 (0, 0xefff9dc, 0, 0) = 6081
13:20:48 sigsetmask (0) = 0x7
13:20:48 lseek (1, 0, 0) = 0
13:20:48 lseek (1, 0, 0) = 0
13:20:48 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:48 read (1, "", 8192) = 0
13:20:48 open ("/etc/hosts.equiv", 0, 0666) = 2
13:20:48 close (2) = 0
13:20:48 open ("/.rhosts", 0, 0666) = 2
13:20:48 ioctl (2, 0x40125401, 0xefff808) = -1 ENOTTY (Inappropriate ioctl for device)
13:20:48 fstat (2, 0xefff834) = 0
13:20:48 read (2, "owl\nrand-unix.arpa\n", 8192) = 19
13:20:48 lseek (1, 0, 0) = 0
13:20:48 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:48 lseek (1, 0, 0) = 0
13:20:48 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:48 lseek (1, 0, 0) = 0
13:20:48 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:48 lseek (1, 0, 0) = 0
13:20:48 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:48 lseek (1, 0, 0) = 0
13:20:48 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:48 read (2, "", 8192) = 0
13:20:48 close (2) = 0
13:20:48 open ("/etc/passwd", 0, 0666) = 2
13:20:49 ioctl (2, 0x40125401, 0xefff3e8) = -1 ENOTTY (Inappropriate ioctl for device)
13:20:49 fstat (2, 0xefff414) = 0
13:20:49 read (2, "root:***sorry***:0:1:Operator:".., 8192) = 714
13:20:49 open ("//.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("//.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("//.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("//.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("/bin/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("/var/spool/uucppublic/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("/u/oper/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("/var/spool/news/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("/usr/ingres/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:49 open ("//.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:50 open ("/usr/diag/sysdiag/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:50 open ("/home/terry/.forward", 0, 0666) = 3
13:20:50 ioctl (3, 0x40125401, 0xefff808) = -1 ENOTTY (Inappropriate ioctl for device)
13:20:50 fstat (3, 0xefff834) = 0
13:20:50 brk (0x4b29c) = 0
13:20:50 read (3, "terry@zoo\n", 8192) = 10
13:20:50 lseek (1, 0, 0) = 0
13:20:50 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:50 read (3, "", 8192) = 0
13:20:50 close (3) = 0
13:20:50 open ("/home/guyton/.forward", 0, 0666) = 3
13:20:50 ioctl (3, 0x40125401, 0xefff808) = -1 ENOTTY (Inappropriate ioctl for device)
13:20:50 fstat (3, 0xefff834) = 0
13:20:50 read (3, "guyton@condor\n", 8192) = 14
13:20:50 lseek (1, 0, 0) = 0
13:20:50 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:20:50 read (3, "", 8192) = 0
13:20:50 close (3) = 0
13:20:50 open ("/home/salzman/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:51 open ("/home/edhall/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:51 open ("/home/jim/.forward", 0, 0666) = -1 ENOENT (No such file or directory)
13:20:51 getpid () = 6077
13:20:51 open ("/var/yp/binding/isltest.rand.org".., 0, 0) = 3
13:20:51 flock (3, 06) = 0
13:20:51 close (3) = 0
13:20:51 socket (2, 1, 0) = 3
13:20:51 connect (3, "".., 16) = 0
13:20:51 close (3) = 0
13:20:51 gettimeofday (0xefff374, 0) = 0
13:20:51 getpid () = 6077
13:20:51 socket (2, 2, 17) = 3
13:20:51 bind (3, "".., 16) = -1 EACCES (Permission denied)
13:20:51 ioctl (3, 0x8004667e, 0xefff340) = 0
13:20:51 sendto (3, "".., 56, 0, 0x27aa8, 16) = 56
13:20:51 select (64, 0xefff35c, 0, 0, 0x27abc) = 1
13:20:51 recvfrom (3, "".., 400, 0, 0xefff32c, 0xefff37c) = 28
13:20:51 close (3) = 0
13:20:51 close (3) = -1 EBADF (Bad file number)
13:20:51 socket (2, 2, 0) = 3
13:20:51 bind (3, "".., 16) = 0
13:20:51 close (3) = 0
13:20:51 read (2, "", 8192) = 0
13:20:51 close (2) = 0
13:20:51 setitimer (0, 0xefffc9c, 0xefffc8c) = 0
13:20:51 sigvec (14, 0xefffc50, 0xefffc74) = 0
13:20:51 sigblock (0x2000) = 0
13:20:51 setitimer (0, 0xefffc9c, 0) = 0
13:20:51 sigpause (0) = -1 EINTR (Interrupted system call)
13:21:21 - SIGALRM (14)
13:21:21 sigcleanup () = 0
13:21:21 sigvec (14, 0xefffc50, 0) = 0
13:21:21 sigsetmask (0) = 0x2000
13:21:22 setitimer (0, 0xefffc8c, 0) = 0
13:21:23 fork () = 6083
13:21:23 close (0) = 0
13:21:23 close (1) = 0
13:21:23 close (2) = -1 EBADF (Bad file number)
13:21:23 close (1) = -1 EBADF (Bad file number)
13:21:23 exit (0) = ?

# now for the forked process.... 

# I missed a good 6 seconds of stuff here...
# notice the "ENETUNREACH" errno's since I deleted all the routes
# (as our ``friendly'' virus attempts to propagate
13:21:29 sigpause (0) = -1 EINTR (Interrupted system call)
13:21:29 - SIGALRM (14)
13:21:29 sigcleanup () = 0
13:21:30 sigvec (14, 0xefffc1c, 0) = 0
13:21:30 sigsetmask (0) = 0
13:21:30 setitimer (0, 0xefffc58, 0) = 0
13:21:30 wait4 (0, 0, 0x1, 0) = 6086
13:21:30 sigvec (14, 0xefff820, 0xefff84c) = 0
13:21:30 socket (2, 1, 0) = 2
13:21:30 setitimer (0, 0xefff84c, 0xefff83c) = 0
13:21:30 connect (2, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:30 setitimer (0, 0xefff84c, 0xefff83c) = 0
13:21:30 close (2) = 0
13:21:30 socket (2, 1, 0) = 2
13:21:30 connect (2, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:30 close (2) = 0
13:21:30 socket (2, 1, 0) = 2
13:21:30 bind (2, "".., 16) = 0
13:21:30 listen (2, 10) = 0
13:21:30 sigvec (14, 0xefffa30, 0xefffa5c) = 0
13:21:30 socket (2, 1, 0) = 3
13:21:30 setitimer (0, 0xefffa5c, 0xefffa4c) = 0
13:21:30 connect (3, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:30 setitimer (0, 0xefffa5c, 0xefffa4c) = 0
13:21:30 close (3) = 0
13:21:30 setitimer (0, 0xefffc78, 0xefffc68) = 0
13:21:30 sigvec (14, 0xefffc2c, 0xefffc50) = 0
13:21:30 sigblock (0x2000) = 0
13:21:30 setitimer (0, 0xefffc78, 0) = 0
13:21:30 sigpause (0) = -1 EINTR (Interrupted system call)
13:21:31 - SIGALRM (14)
13:21:31 sigcleanup () = 0
13:21:31 sigvec (14, 0xefffc2c, 0) = 0
13:21:31 sigsetmask (0) = 0x2000
13:21:31 setitimer (0, 0xefffc68, 0) = 0
13:21:31 pipe (0) = 3
13:21:31 pipe (0) = 5
13:21:31 fork () = 6088
13:21:31 close (3) = 0
13:21:31 close (6) = 0
13:21:31 write (4, "\n/bin/echo 6480629\n", 19) = 19
13:21:31 select (6, 0xefff96c, 0, 0, 0xefff964) = 1
13:21:32 read (5, "", 1) = 0
13:21:32 close (5) = 0
13:21:32 close (4) = 0
13:21:32 kill (6088, 9) = 0
13:21:32 setitimer (0, 0xefffc68, 0xefffc58) = 0
13:21:32 - SIGCHLD (20)
13:21:32 sigvec (14, 0xefffc1c, 0xefffc40) = 0
13:21:32 sigblock (0x2000) = 0
13:21:32 setitimer (0, 0xefffc68, 0) = 0
13:21:32 sigpause (0) = -1 EINTR (Interrupted system call)
13:21:33 - SIGALRM (14)
13:21:33 sigcleanup () = 0
13:21:33 sigvec (14, 0xefffc1c, 0) = 0
13:21:33 sigsetmask (0) = 0x2000
13:21:33 setitimer (0, 0xefffc58, 0) = 0
13:21:33 wait4 (0, 0, 0x1, 0) = 6088
13:21:33 sigvec (14, 0xefff820, 0xefff84c) = 0
13:21:33 socket (2, 1, 0) = 3
13:21:33 setitimer (0, 0xefff84c, 0xefff83c) = 0
13:21:33 connect (3, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:33 setitimer (0, 0xefff84c, 0xefff83c) = 0
13:21:33 close (3) = 0
13:21:33 socket (2, 1, 0) = 3
13:21:33 connect (3, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:33 close (3) = 0
13:21:33 socket (2, 1, 0) = 3
13:21:33 bind (3, "".., 16) = 0
13:21:33 listen (3, 10) = 0
13:21:33 sigvec (14, 0xefffa30, 0xefffa5c) = 0
13:21:33 socket (2, 1, 0) = 4
13:21:33 setitimer (0, 0xefffa5c, 0xefffa4c) = 0
13:21:33 connect (4, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:33 setitimer (0, 0xefffa5c, 0xefffa4c) = 0
13:21:33 close (4) = 0
13:21:33 setitimer (0, 0xefffc78, 0xefffc68) = 0
13:21:33 sigvec (14, 0xefffc2c, 0xefffc50) = 0
13:21:33 sigblock (0x2000) = 0
13:21:33 setitimer (0, 0xefffc78, 0) = 0
13:21:33 sigpause (0) = -1 EINTR (Interrupted system call)
13:21:34 - SIGALRM (14)
13:21:34 sigcleanup () = 0
13:21:34 sigvec (14, 0xefffc2c, 0) = 0
13:21:34 sigsetmask (0) = 0x2000
13:21:34 setitimer (0, 0xefffc68, 0) = 0
13:21:34 pipe (0) = 4
13:21:34 pipe (0) = 6
13:21:34 fork () = 6089
13:21:34 close (4) = 0
13:21:34 close (7) = 0
13:21:34 write (5, "\n/bin/echo 6541524\n", 19) = 19
13:21:34 select (7, 0xefff96c, 0, 0, 0xefff964) = 1
13:21:35 read (6, "", 1) = 0
13:21:35 close (6) = 0
13:21:35 close (5) = 0
13:21:35 - SIGCHLD (20)
13:21:35 kill (6089, 9) = -1 ESRCH (No such process)
13:21:35 setitimer (0, 0xefffc68, 0xefffc58) = 0
13:21:35 sigvec (14, 0xefffc1c, 0xefffc40) = 0
13:21:35 sigblock (0x2000) = 0
13:21:35 setitimer (0, 0xefffc68, 0) = 0
13:21:35 sigpause (0) = -1 EINTR (Interrupted system call)
13:21:36 - SIGALRM (14)
13:21:36 sigcleanup () = 0
13:21:36 sigvec (14, 0xefffc1c, 0) = 0
13:21:36 sigsetmask (0) = 0x2000
13:21:36 setitimer (0, 0xefffc58, 0) = 0
13:21:36 wait4 (0, 0, 0x1, 0) = 6089
13:21:36 sigvec (14, 0xefff820, 0xefff84c) = 0
13:21:36 socket (2, 1, 0) = 4
13:21:36 setitimer (0, 0xefff84c, 0xefff83c) = 0
13:21:36 connect (4, "".., 16) = -1 ENETUNREACH (Network is unreachable)
13:21:40 setitimer (0, 0xefffa5c, 0xefffa4c) = 0
13:21:40 close (6) = 0
13:21:40 pipe (0x6) = 6
13:21:40 vfork () = 6092
13:21:40 close (7) = 0
13:21:40 ioctl (6, 0x40125401, 0xefff948) = -1 EOPNOTSUPP (Operation not supported on socket)
13:21:40 fstat (6, 0xefff974) = 0
13:21:41 read (6, "Routing tables\nDestination      ".., 4096) = 167
13:21:44 read (6, "", 4096) = 0
13:21:44 - SIGCHLD (20)
13:21:44 close (6) = 0
13:21:44 sigblock (0x7) = 0
13:21:44 wait4 (0, 0xefff9dc, 0, 0) = 6092
13:21:44 sigsetmask (0) = 0x7
13:21:44 lseek (1, 0, 0) = 0
13:21:44 lseek (1, 0, 0) = 0
13:21:44 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:21:45 read (1, "", 8192) = 0
13:21:45 setitimer (0, 0xefffc9c, 0xefffc8c) = 0
13:21:45 sigvec (14, 0xefffc50, 0xefffc74) = 0
13:21:45 sigblock (0x2000) = 0
13:21:45 setitimer (0, 0xefffc9c, 0) = 0
13:21:45 sigpause (0) = -1 EINTR (Interrupted system call)
13:23:45 - SIGALRM (14)
13:23:45 sigcleanup () = 0
13:23:45 sigvec (14, 0xefffc50, 0) = 0
13:23:45 sigsetmask (0) = 0x2000
13:23:45 setitimer (0, 0xefffc8c, 0) = 0
13:23:45 gettimeofday (0xefffccc, 0) = 0
13:23:46 setitimer (0, 0xefffc9c, 0xefffc8c) = 0
13:23:46 sigvec (14, 0xefffc50, 0xefffc74) = 0
13:23:46 sigblock (0x2000) = 0
13:23:46 setitimer (0, 0xefffc9c, 0) = 0
13:23:46 sigpause (0) = -1 EINTR (Interrupted system call)
13:24:16 - SIGALRM (14)
13:24:16 sigcleanup () = 0
13:24:16 sigvec (14, 0xefffc50, 0) = 0
13:24:16 sigsetmask (0) = 0x2000
13:24:16 setitimer (0, 0xefffc8c, 0) = 0
13:24:17 fork () = 6094
13:24:17 close (0) = 0
13:24:17 close (1) = 0
13:24:17 close (2) = 0
13:24:17 close (1) = -1 EBADF (Bad file number)
13:24:17 exit (0) = ?

# and another - there are a couple more that look like this but
# it was getting boring since it had no where to go....

13:24:21 read (6, "Routing tables\nDestination      ".., 4096) = 167
13:24:22 read (6, "", 4096) = 0
13:24:22 close (6) = 0
13:24:22 - SIGCHLD (20)
13:24:22 sigblock (0x7) = 0
13:24:22 wait4 (0, 0xefff9dc, 0, 0) = 6097
13:24:22 sigsetmask (0) = 0x7
13:24:22 lseek (1, 0, 0) = 0
13:24:22 lseek (1, 0, 0) = 0
13:24:22 read (1, "127.0.0.1 localhost loghost\n192.".., 8192) = 3823
13:24:22 read (1, "", 8192) = 0
13:24:22 setitimer (0, 0xefffc9c, 0xefffc8c) = 0
13:24:22 sigvec (14, 0xefffc50, 0xefffc74) = 0
13:24:22 sigblock (0x2000) = 0
13:24:22 setitimer (0, 0xefffc9c, 0) = 0
13:24:22 sigpause (0) = -1 EINTR (Interrupted system call)
13:26:23 - SIGALRM (14)
13:26:23 sigcleanup () = 0
13:26:23 sigvec (14, 0xefffc50, 0) = 0
13:26:23 sigsetmask (0) = 0x2000
13:26:23 setitimer (0, 0xefffc8c, 0) = 0
13:26:23 gettimeofday (0xefffccc, 0) = 0
13:26:25 setitimer (0, 0xefffc9c, 0xefffc8c) = 0
13:26:25 sigvec (14, 0xefffc50, 0xefffc74) = 0
13:26:25 sigblock (0x2000) = 0
13:26:25 setitimer (0, 0xefffc9c, 0) = 0
13:26:25 sigpause (0) = -1 EINTR (Interrupted system call)
13:26:55 - SIGALRM (14)
13:26:55 sigcleanup () = 0
13:26:55 sigvec (14, 0xefffc50, 0) = 0
13:26:55 sigsetmask (0) = 0x2000
13:26:55 setitimer (0, 0xefffc8c, 0) = 0
13:26:55 fork () = 6103
13:26:55 close (0) = 0
13:26:55 close (1) = 0
13:26:55 close (2) = 0
13:26:55 close (1) = -1 EBADF (Bad file number)
13:26:56 exit (0) = ?

--
* Isaac J. Salzman                                            ----     
* The RAND Corporation - Information Sciences Dept.          /o o/  /  
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138    | v |  |  
* AT&T: +1 213-393-0411 x6421 or x7923 (ISL lab)            _|   |_/   
* ARPA: salzman@RAND.ORG or salzman@rand-unix.ARPA         / |   |
* UUCP: ...!{cbosgd,decvax,sdcrdcf}!randvax!salzman        | |   |     

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 88 23:55:19 GMT
From:      tep@helix.UUCP (Tom Perrine x397)
To:        comp.protocols.tcp-ip
Subject:   Virus detection and prevention

Well, that was a nice perl script, but how do I get "perl"?

Tom Perrine
Logicon(Tactical and Training Systems Division)	San Diego CA (619) 455-1330
UUland:		uunet!nosc!hamachi!tots!tep
Internet:	hamachi!tots!tep@NOSC.MIL (last resort:Perrine@DOCKMASTER.ARPA)
"There is a special place in Hell reserved for people who park in File Lanes."

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 01:57:29 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)

No, it's not that the daemon can't detect when the pipe is empty.
What it can't detect is when the user program does an ioctl to set
the mode on the tty/pty.  To be a player in a smart telnet etc.
protocol it needs to recognize when the application switches tty modes.

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 02:06:28 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) writes:
> why does EMACS, in general, use standard control characters as
> application dependent function characters?

	I am sure there will be many answers to this.  Before we get off to
the races on this topic, may I remind people that we run the risk of getting
into emacs religious wars.  And, as most people can tell you, one very good
way to generate lots of traffic and accomplish absolutely nothing in the
process is to get involved in a emacs religious war.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 03:13:13 GMT
From:      salzman%aja@RAND.ORG (Isaac)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus


>So the first step might be to (quietly) grep unix filesystems for some
>appropriate (cleartext) substrings that would appear in his files (ie,
>pieces of the infecting shell script).  Anyone who owned such files
>before the infection would be suspect.

Another thing that everyone should do is make sure you clean out
your /usr/tmp directories (though most of you have probably done
so allready), and also check if anyone on your net has snarfed up
copies of the stuff left in /usr/tmp. Anyone who's got that stuff
lying around has the potential for starting the whole thing up again!
Of course since everyone out there has plugged the holes it wouldn't
get anywhere, right? :-) 

As far as I'm concerned, this virus or worm or whatever you want
to call it was actually a good thing! We can all be thankful that
the thing was benign and didn't cause any real damage. What it did
do (hopefully) is make everyone take a hard look at network security,
or a lack thereof. Everyone likes to think that their system is safe
from viruses and such attacks. This was a very humbling experience
for those who think their net's are invincable. And of course it
rid us of a very nasty security hole in sendmail. Rest assure
people will start to find holes in other network utilities and 
get them patched up, and let the rest of us know about it! Ciao....

--
* Isaac J. Salzman                                            ----     
* The RAND Corporation - Information Sciences Dept.          /o o/  /  
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138    | v |  |  
* AT&T: +1 213-393-0411 x6421 or x7923 (ISL lab)            _|   |_/   
* ARPA: salzman@RAND.ORG or salzman@rand-unix.ARPA         / |   |
* UUCP: ...!{cbosgd,decvax,sdcrdcf}!randvax!salzman        | |   |     

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 03:25:14 GMT
From:      rdp@pbseps.UUCP (Richard Perlman)
To:        comp.protocols.tcp-ip
Subject:   Cheap Bridge wanted...


I am lookin to connect to ethernet installations as CHEAPLY as
possible.  At the moment cost is much more of a consideration
than performance! The purpose is to demonstrate the possibilities
of file/device sharing over medium (45 mile) distances.

The curerent installations are as follows:

A:	Sun workstation running Sun's IR and connected to one end
	of a 56kb DDS sync circuit.  Other machines exist on the
	same ethernet as the Sun.

B:	Sequent Symmetry (has SLIP available), Annex II terminal
	server (can do SLIP at <= 38kb), various PCs running
	PC-NFS.  All this is connected by thinwire with a 3COM
	Multi-port fanout box (8 empty slots).  The other end of
	the 56kb ckt is at this location and is currently
	unterminated (other than the DSU/CSU).

Note that the DSU/CSU (General Datacom) does not appear to be
able to change speeds (like its slower 9.6 cousin can).

What would you suggest???  (suggestions like "2 Proteon Routers @
12K each" will not be helpful!  8^)


Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602,  San Francisco, CA  94105  |*|  (415) 545-0233

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 04:28:37 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   ^O in EMACS


From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
>Thanks to everyone who responded and informed me the function of ^O; however,
>the question was more specifically "why?".  In a rhetorical vein, why does
>EMACS, in general, use standard control characters as application dependent
>function characters?  Why would any application?

On the system EMACS was developed (ITS) ^O was not a "standard control
character", at least not in the way you seem to think of it, flushing
output. I am sure one motivation for moving it with its (ITS?)
original commands to other systems was to make life easier for users
moving to those systems. EMACS was originally written in TECO, an
editor which could parse and run line noise in useful and mysterious
ways.

So, backwards compatability is one reason.

Another was mnemonic value (^O == Open Line.)

Another is it's not clear that there was ever any strong motivation to
preserve or interpret meaning for characters oriented towards line
mode when in a full-screen editor. Full-screen editors like EMACS
tended to grab the full character set (in fact, Emacs grabbed more
than the full character set, 9-bits.)

Another is that ^O is SHIFT-IN in ASCII, which means to change
character sets or some such thing, is that what you had in mind as a
more correct interpretation? It might be its use as flush output
which is questionable.

Better: Control-O on Emacs was not intended to be, particularly, ASCII
0xF. There was an intention in the original design to use other
extended character sets and Control would be just another prefix bit,
quite unlike the common usage we all know and love.

If none of this is satisfying perhaps you can suggest what you are
looking for as an explanation.

	-Barry Shein, ||Encore||

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 05:19:40 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Deja vu wormus

Folks,

Several years ago when the Internet was but a wee tot I happened a booboo in
my GGP implementation which resulted in a severely retarded routing update
sent to a gateway of what became the BBN core gateways system. The update
caused the gateway to crash, but not before replicating the update sent to
all of its neighbors, which promptly redistributed it and crashed as well.
This of course was a worm, although I can't say whether I, John Shoch or
John Brunner can claim the First Worm Award.

To cover my embarassment, I noticed in the world news that a company of
mercenaries, later found to be in the pay of South Africa, had just invaded
Madagascar, but were repulsed. I therefore caused my boo to become known as
the Great Commando Raid to put the best spin I could on it and all my dear
friends seemed to have forgiven me. The legend is sometimes whispered as
a lesson to aspiring undergrad programmers.

Comes now the Worm of 88, which will surely become known to the worldwide
community. Now, I see in the news that India has sent mercenaries to the
Maldives, sleepy little islands in the same sea as Madagascar, itself a
largish island. I don't mind telling you the coincidence is unsettling,
perhaps less so because the mercs seem to have been successful in thier raid.

Dave

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 06:43:21 GMT
From:      fjd@bridge2.UUCP (Farokh J. Deboo)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC on Internet "Virus", Please

Jon,

This is really addressed to the "tcp-ip" community in general:


Good idea.  A "virus" RFC indeed!

My main comment to this state of affairs  is  the  sensationalism
associated witht this kind of event.

Although it is very fruitful to discuss such issues within closed
groups  (eg.  "tcp-ip"), when at all possible can we please leave
the press out of this kind of an  event.    Publicizing  such  an
event  on  the  6  o'clock news only tends to encourage the worm-
maker, the virus-monger, you name it!    Terrorists  and  hackers
really  fall  into  the same category.  Let's not glorify them on
the front page of the local rag sheet!

Farokh Deboo

----------------------- Replied Message Body -----------------------
Date: Fri, 4 Nov 88 12:52:52 PST
From: sun!venera.isi.edu!postel
Posted-Date: Fri, 4 Nov 88 12:52:52 PST
Message-Id: <8811042052.AA00423@bel.isi.edu>
Received: by bel.isi.edu (5.54/5.51)
	id AA00423; Fri, 4 Nov 88 12:52:52 PST
To: arpa!tcp-ip@sri-nic
Subject: RFC on Internet "Virus", Please

Hi.

I would like to have an RFC written about the Internet "Virus" event to 
document exactly what actually happened.  Virus is in quotes since this
was technically a Worm.  The RFC should describe features were used, what
tricks were used, and how it worked.  Also how it was stopped, and what 
lessons were learned.  All the history, the story of its spread and its
defeat.  This RFC should include all the gory details.   This RFC can then
be the basis for summary articles in magazines and journals.  I think that
this RFC should have many authors, as many people contributed to the efforts
to understand and stop this program.

--jon.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 07:05:23 GMT
From:      cracraft@venera.isi.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus detection and prevention

In article <8811040037.AA01678@rand.org> terry@RAND.ORG (Terry West) writes:
>If you have been hit by the current Internet virus (grep for "sed" in your
>syslog file), you will want to run the enclosed perl script to make sure
>it won't find its way back in as easily the next time.

Jim's PERL script is very handy. Below is a version with a fix for
an annoyance. When a password field is empty, the crypt matches
against every password in the sample word list, thus producing lots
of output. This version is a bit more terse:

#!/usr/local/perl
#
# vircheck: brute force password from Internet virus password list
#
# 4 Nov 88, Stuart Cracraft -- handle blank passwd field 
#			(was outputting entire wordlist)
# 3 Nov 88, Jim Gillogly

$pwfile = "virpasswords";

$words = "/etc/passwd";        # Try all words out of the virus list

$| = 1;                         # Flush the output

open(pw, $pwfile);              # Get the password file
while (<pw>)                    # a line at a time
{
	($user, $pass) = split(/:/);    # Get the username and password
	if ($pass eq "")
	{
	    print "  *****$user: blank password field.\n";
	}
        else {
	 $usalt = substr($pass, 0, 2);   # 1st 2 chars are the salt
	 print "Trying $user\n";
	 $salt = substr($pass, 0, 2);    # Get the salt
	 open(w1, $words);               # Get the dictionary once
	 while (<w1>)                    # For each word from the dictionary
	 {       chop;                   # Ignore the newline
		 if (crypt($_, $salt) eq $pass)  # Check the word
		 {       print "  *****$user: $pass comes from password $_.\n";
		 }
	 }
	 if (crypt($user, $salt) eq $pass)       # Is this a "joe"?
	 {       print "  *****$user: $pass comes from password $user.\n";
	 }

	 close(w1);
    }
}

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 07:11:18 GMT
From:      cracraft@venera.isi.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip
Subject:   Addendum

In  the previous PERL script, swap the assignments for $words
and $pwfile. That is,

	$pwfile should be /etc/passwd
and
	$words should be virpasswords

(Leftover from debugging)

Stuart

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 11:03:25 GMT
From:      jim@eda.com (Jim Budler)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

In article <10521@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
>The flippant response (to the question about why any application
>would use funny characters) is that if the system doesn't allow
 [deleted]
>The non-flippant reasponse is "why not?".  Also, what's so standard
>about, for instance, ^O.  Yeah some operating systems use that for
>special purposes, but nowhere near all of them.  What's so "standard"

[but somewhere near a lot of them]

>about ^S/^Q (another pair which causes headaches for emacs).  For
>one thing it's not standard, but it's also rather braindead to have
>a system which uses in-band signaling to do flow control.  Not only
>is it slow and error prone, it decreases the "bandwidth".
OK, I'll give you ^O, but g-d d--n it ^S/^Q, if not a NIC, IEEE, OSI
or any organisation approved *standard* predates by YEARS any
implementation of Emacs. Ignoring it's existence in a predominent
portion of the existing hardware was a philosophical, or even religious
choice. Who cares if the philosophical idea is that in-band signals
should not be used. When Emacs was developed, they were already
nearly 100% in use. The original computer terminal, the original
teletype terminal, used them. The decision to ignore that, for a
philisophical reason, was STUPID. Is that too mild? The decision
was arogant, uncaring, stupid, assinine, wanton, petty, and many
other adjectives.

For instance: I have a 19.2K modem. My computer cannot take input
at that rate. I have two choices. Use vi, or set my interface rate
below my modem rate. F**k. When they developed emacs they could
have chosen other keys. They cannot have *not* known the majority
of the world was using ^S/^Q at that time. Sitting back and
saying hardware, please note that, I said hardware, including
terminals, data concentrators, modems was brain dead for using
in band signals so therefor Emacs will ignore this reality
and force you to buy better hardware is AROGANT, STUPID,
ELITEST, ACADEMIC, IVORY TOWER, ASSININE,...

My G*D! Hardware predating the computers Emacs was developed on
used ^S/^Q for the exact purpose hardware is using it for today.
Are the only standards we work from those that are blessed
by ARPA. Western Union was here BEFORE ARPA. ARPA doesn't even
call them standards, they call them 'Request For Comment'. Now
days they don't even call them that, someone might comment. Now
they call them 'IDEAS'.

I like Emacs. But when I run into the *frequent* situation where
the hardware doesn't allow it, I don't say 'Damn hardware', I say
******* ******* Stallman.

He was WRONG. The use of ^S/^Q was WELL ESTABLISHED, even if no
standards body had bothered to write it up. They probably didn't
think it needed, because any ******* would notice it was prevalent.

Like I said, I'll grudgingly give you ^O, but I wont give you ^S/^Q.
Why grudgingly? Because people who write *portable* code observe
things that effect their *portable* code. ^O is common on *many*
operating systems, it's called flush output.

It was wrong!!!!!!!! I don't care if it is in band, I mean, gag me
with a spoon, 7 bit is stupid, too.

Send me flames. That way I'll know the UUCP links are working.

-- 
uucp:     {decwrl,uunet}!eda!jim        Jim Budler
internet: jim@eda.com                   EDA Systems, Inc.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5 Nov 88 16:32:25 EST
From:      sudduth@harvard.harvard.edu
To:        tcp-ip@sri-nic.arpa
Subject:   tracking anonymous messages

If anyone cares who sent the anonymous message from foo@bar.arpa through
isis.brown.edu,  I did it.  The machine influenza.harvard.edu is an
annex terminal server.  At the time I didn't want to answer questions
about how I knew.  

Andy Sudduth
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 15:08:56 GMT
From:      ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre)
To:        comp.protocols.tcp-ip
Subject:   Re: is there a need for class A addresses?

In article <8811012316.aa00563@SEM.BRL.MIL> reschly@BRL.MIL ("Robert J. Reschly Jr.") writes:
>
>      Barry,
>
>   There is a good reason for arguing against a cluster of class B (or C)
>addresses over one A (or B).  When one is in a situation where there is
>one portal (or just a few portals) into a cluster of networks, and those
>networks are richly interconnected, then subnetting is a win.  
For AMPRNET (Amateur Packet Radio Net, #44), some are questioning whether 
getting a class A address was the best thing at this early development stage.
Having a class A address makes internetworking Harder in our case, since
a network is assumed to be fully connected internally.

AMPRNET is not, and probably will not be for the next few years.

So my gripe isn't with the size of networks as much as the (presumed) model and
the various implementations of it. I'd rather glue things together with smart 
AMPRnet<->Internet gateways (I believe that they should be the only machines 
with the burden of keeping detailed routing information for AMPRnet.)

-- 
					- Ralph W. Hyre, Jr.
Internet: ralphw@ius3.cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 15:19:01 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  SUPDUP (was: telnet vs rlogin)

Yes, but SUPDUP local editing protocol, while very powerful, is also very
complicated.  It makes X.3 look trivial.

	Stuart

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 16:39:44 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Implications of recent virus (Trojan Horse) attack

Now that the crime of the century has been solved and all of the
bows have been taken it is, perhaps, time to reflect a little more
on the implications of what has happened.

First of all, to the nature of the problem. It has been suggested that
this was little more than a prank let loose without sufficient restraint.
I have not seen the latest in press releases but there seems to be
a hint of "I didn't want anything like this to happen!" Perhaps not.
In fact, if the thing had not run wild and had not bogged down a number
of systems it might have gone undetected for a long time and might
have done much worse damage than our estimates suggest was done. I can
accept that the author did not anticipate the virulence of his creation
but not that it was out of some benevolent concern for the users of
other systems. Rather it was because it allowed him to be caught.

In fact, with function names such as "des", "checkother", and
"cracksome", I am less likely to believe that the intent of this
program was one of simple impishness.

Let's look, for a moment, at the effects of this system (whether
intended or otherwise). First, it satisfied a public desire for news
and, one might argue, served as a reassurance to the many technophobes
out there that our systems are as vulnerable as error prone as they,
all along, have been arguing. If you don't think that this might have
social consequences you need only look at things like community bans
on genetic research have resulted from social policy implemented as
a result of public distrust. When I was interviewed by a local news
agency the questions asked were on the order of "Does this mean that
someone could fix a Presidential Election?" (sure, Daley did it in
Chicago but he didn't used computers!), and "What implications does
this have for the nation's defense?" (In spite of reassurances from
here and CMU, the local media still insisted on the headline "Defense
Computers invaded by virus.")

Second, there is an economic conseqence. Since we were unable to
determine the extent of the programs activities we were forced to
commit programmers time to installing kernel fixes, rebuilding systems,
checking user data files, and checking for other damage. That was
the direct cost. The indirect cost comes from the delay in other
tasks that was incurred by the diversion of people's time to solving
this one. If you multiply by the effort that is going on at a number
of other sites I suspect that in salary time, alone, you are looking
at costs into the hundreds of thousands of dollars.

Perhaps, most importantly, there is the academic costs. I would argue
that that the popularity of Unix, today, is due in great part to the
development of the Berkeley Software Distribution which was made available
in source form to thousands of research and academic organizations starting
in the '70s. In a sense, it is a community designed system and although
Berkeley deserves the lion's share of the credit, it was the contribution
of hundreds of users with access to source codes that allowed the system
to evolve in the way that it did.

There is a cost to providing an academic environment and there are
responsibilities that are imposed by it. One advantage of academic is
access to information which would not be tolerated in an industrial
domain. This access requires our users to observe some code of behavior
in order to guarantee that everyone will have the same access to the
same information. The person who rips out the pages of an article from
a library journal is abusing this privilege of free access to information
and depriving others of the same. By convention, we agree not to do
that, and so we protect that system that has benefited us so that others
derive the same benefit.

A great part of the Internet was funded by DARPA because some forward
thinking individuals recognized the tremendous technological and academic
benefits that would be derived from this open network. This has resulted,
I believe, in significant economic benefits to American industry and
continues to support our leadership role in software development. It is
an an infrastructure that supports a gigantic technological community
and there are very few, if any, computer interests in this country that
were influenced by DARPA' experiment.

Within a week or two, members of the organizations responsible for this
network are going to be meeting to discuss the implications of the recent
virus(es), and mechanisms with which they can be dealt. One possible outcome
would be increased restrictions on access to the network (the Defense
Research Network is already moving along these lines). It would not
be unreasonable to consider whether a venture such as this should be
supported, at all. To restrict access to a network such as this, or
to remove the network, altogether, would be the economic equivalent
to tearing up the Interstate highway system. The effect on academic
and technological advancement would be quite serious.

The bottom line being that to suggest that program such as the
"virus" (which is really more of a Trojan Horse), was little more
than a harmless prank is to overlook what the long term effects of
both the technology, and the PUBLICATION of that technology will
have on continued academic freedom and technological growth.

But what of the nature of the act? Is there something to be said of
that? First, there is the personal tragedy, here. There is public
humiliation for the (supposed) perpetrator's father who is, himself,
a computer security expert (his employer's must be questioning whether
the son had access to specialized information though most of us realize
that the holes that were exploited were well known). There is the
jeopardy of the academic career for the programmer. But there is more
than that.

There seems to be a real lack of consideration for what are the ethical
considerations of this action. Consider, for a moment, that you are
walking down the street and the person in front of you drops a 10 dollar
bill. You have three options: 1) You can pick it up and hand it to them;
2) You can pick it up and keep it; 3) You can leave it and continue walking.
It should be obvious that these choices are not morally equivalent. To
have known about the holes in the system which allowed the virus in
(and even to have known how to exploit these), is NOT the same as actually
doing it (any more than leaving the bill on the sidewalk is the same
as pocketing it). Somewhere along the line, we fail ourselves and our
students if we don't impress upon them the need to regard the network
as a society with rights, responsibilities, and a code of professional
ethics which must be observed in order to preserve that society. There
are probably a few hundred people who could have written the code to
do what this virus did; most of those people didn't do it. Most, if
not all, of us have had the opportunity to pocket a candybar from
the local convenience store, but most of us don't. We don't, not
because we will be punished or because there are laws against it,
but because we have a social consciousness which tells us that
such an action would, in the end, would substantially degrade the
society in which we live.

What happened in this situation reflects not only a moderately
high level of programming sophistication but also a disturbingly
low level of ethical maturity.

If we tolerate those who view the network as a playground where
anyhting goes, we are going to be faced with serious consequences. But
the answer is not to change the character of the network (by increasing
restrictions and decreasing freedom of access), but to promote a sense
of character among the members of the community who work and experiment
in this network. This puts the burden on us to remember that there
is a need for us to encourage, teach, and provide examples of the
kind of behaviors that we need to preserve in order to preserve the
network.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 17:07:50 GMT
From:      cracraft@venera.isi.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip
Subject:   virulence of the recent virus

Some brief tests have shown that the recent virus attack could
breach approximately 4.6% of passwords on a typical large-sized
Unix mainframe, revealing 10-20 passwords.

All of this once again exposes the weakest link of any password-based
security system: the passwords.

As a system maintainer, the two best things you can do to increase
your ability to sleep at night are:

	* enable password aging

	* enable complex passwords


The first of these tells Unix to occasionally require that the
user input a new password and confirm it, giving the old password to
assure he is authorized. If you enable aging, for example, once every
month or two, every user who logs into your system will be required
to specify a new password.

The second of these is the more useful, but both are needed in
conjunction to close a lot of holes in Unix. This particular one requires
that the user specify a password with complex characters in it, 
either non-alphabetic, or numeric mixed with alphabetic and of
at least a certain length (10 characters seems like a good size).

Prior to this, the system maintainer can conduct an audit of the
system, looking for null password fields in /etc/passwd or using
Jim GIllogly's script (see earlier messages on this list) to
discover English language words already compromised by the
current attack (its candidate word list -- which will most surely
be in the hands of every small-fry youngster who sees the current
media-glory as a chance to gain new heights in his teenage years
by becoming a cracker). Hence, this list must always be checked
against.

Doing these three things (audit, aging, and complex) will greatly
increase the security of a system. Not all Unix's have the latter
two, but this is possible to implement.

	Stuart

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 17:10:25 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Dumb question: ping w/o icmp support?

Henry,

Hey, you guys drop Millstones around my neck, howcum Dave Boggs gets relief?
Why not invert the measure, so that High Bog stands for squeaky clean and
Low Bog stnads for the other kind? The unit, of course, would be the Bogg
and calibrated to MTBF.

Dave

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 21:32:25 GMT
From:      sudduth@HARVARD.HARVARD.EDU
To:        comp.protocols.tcp-ip
Subject:   tracking anonymous messages


If anyone cares who sent the anonymous message from foo@bar.arpa through
isis.brown.edu,  I did it.  The machine influenza.harvard.edu is an
annex terminal server.  At the time I didn't want to answer questions
about how I knew.  

Andy Sudduth

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 22:01:59 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   misquoting . . . .


From: stev@vax.ftp.com
>it is bad enough that articles misquote someone, i would like to think
>that most of them dont know they are mucking it up, rather than not caring
>or trying to twist things to prove their point.

Although I agree with you in spirit I'd be happy to ship you a
transcript of CBS's coverage on their evening news report of the
Hacker's Convention a few weeks ago.

They blatantly and consciously lied, clipped out of context, overlaid
sensationalist narrative to turn what was basically a benign
convention of computer nerds into some sort of conspiratorial assembly
of criminals, it was unbelievable. Here is part of the opening:

----------
Narrator (trees and outdoor scenes at conference):  A small revolutionary
army is meeting in the hills above California's Silicon Valley this
weekend, plotting their next attacks on the valley below, the heart
of the nation's computer industry.  They call themselves computer hackers.
----------

The rest is worse.

	-Barry Shein, ||Encore||

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 88 23:45:24 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   RE: Internet VIRUS alert

> I guess I am not that familiar with the Unix mail systems
> of the Sun and Vax.  Is this sendmail?

Yes.

> Does sendmail have the ability
> of receiving mail for a process?  If so, this is the biggest security
> hole I have heard about in a long time.

The problem is the implementation, not the concept.  Receiving mail
for a process is extremely useful.  Three examples, first, a daemon
program that automatically files bug reports.  Two, a program that
replies that you've gotten the mail, but aren't reading it because
you're on vacation.  Three, a program that takes mail and gateways
it to network news groups.

--keith

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Nov 1988 08:57-EST
From:      Ralph.Hyre@IUS3.IUS.CS.CMU.EDU
To:        bostic@berkeley.edu
Cc:        tcp-group@ucsd.edu, tcp-ip@sri-nic.arpa
Subject:   VIRUS discussion quenched? (was Re: Virus)
Read a disturbing report in the Sunday paper (Pittsburgh Press, pA16),
attributed to 'Press news services; LA Times, distributed by LA 
Times-Washington Post News Service':

"Most of the program has been deciphered, but the computer scientists said 
they were no longer allowed to discuss the virus because of a Pentagon
directive."

I find this disturbing, was a 'gag order' really issued?  By whom?
To what parties?
					- Ralph W. Hyre, Jr.
Internet: ralphw@ius3.cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 06:00:10 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Implications of recent virus (Trojan Horse) attack

One side effect that I don't like is that UNIX is taking the blame for
a combination of (1) a security hole in an application (sendmail), and
(2) deliberate loosening of security to trusted sites (rhosts, etc...).

Non-academic UNIX in general is a lot less open to techniques like this.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation
"Have you hugged  U  your wolf today?"     uunet.uu.net!ficc!peter
Disclaimer: My typos are my own damn business.   peter@ficc.uu.net

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6 Nov 88 11:40 EST
From:      <SYSTEM%CRNLNS.BITNET@MITVMA.MIT.EDU>
To:        SRA@XX.LCS.MIT.EDU
Subject:   Returned Network Mail
Comment: forwarded by CRNLNS/FMAIL v2.0
Comment: REPLY may not work.
Comment: Network-Source:  _LNS61::SYSTEM (HEPnet/SPAN)
Comment: Originally-From: POSTMASTER
Comment: Originally-To:   EDU%"SRA@XX.LCS.MIT.EDU"

Your mail is being returned to you.
Reason for return is:
%MAIL-E-OPENOUT, error opening SYS$COMMON:[SYSMGR.MAIL]MAIL$00040091B741871C.MAI
-RMS-E-CRE, ACP file create failed
-SYSTEM-W-DIRALLOC, allocation failure on directory file
Returned mail follows:
------------------------------
Received: From BYUADMIN(MAILER) by CRNLNS with Jnet id 9437
          for SYSTEM@CRNLNS; Sun,  6 Nov 88 11:39 EST
Received: by BYUADMIN (Mailer R2.01) id 9415; Sun, 06 Nov 88 05:14:58 MST
Date:         Thu, 3 Nov 88 19:22:00 EST
Reply-To:     <TCP-IP@SRI-NIC.ARPA>
Sender:       "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
From:         Rob Austein <SRA@XX.LCS.MIT.EDU>
Subject:      ^O in EMACS
X-To:         Merton Campbell Crockett <mcc@ETN-WLV.EATON.COM>
X-cc:         tcp-ip@SRI-NIC.ARPA
To:           "(no name)" <SYSTEM@CRNLNS>
In-Reply-To:  Msg of 1 Nov 1988  18:01-EST from mcc@ETN-WLV.EATON.COM (Merton
              Campbell Crockett)

    Date: Tuesday, 1 November 1988  18:01-EST
    From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)

    Thanks to everyone who responded and informed me the function of
    ^O; however, the question was more specifically "why?".  In a
    rhetorical vein, why does EMACS, in general, use standard control
    characters as application dependent function characters?  Why
    would any application?

Ancient history, mostly.

Keep in mind that the original EMACS was a set of TECO macros (hence
the name Editor MACroS) on the MIT Incompatible Timesharing System.
ITS has a long tradition of doing nonstandard things with control
characters, eg, to most ITS programs other than EMACS (which has so
many commands that RMS had to use every possible key combination):

    ^C = EOF;
    ^D = Discard (punt the line currently being entered);
    ^S = Shutup (stop tty output);
    ^Q = Quote (quote the next character).

You expect conformity on a system where the command processor is a
souped-up assembly language debugger?

--Rob
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 06:42:57 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   ^O in EMACS


Er, calm down, it's rather easy to bind ^O or ^S/^Q key functions to
other keystrokes in all the emacs's I know of, for the latter a
special note is even included spelling this out (and a function built
in to make sure this works correctly, (set-input-mode nil t), GNU
EMACS.)

Also, for what it's worth, your complaint about ^S/^Q is in the wrong
direction. It's not the host sending it to you when downloading, it's
you sending it as keystrokes to the host. But that's ok, the point is
the same, many terminals couldn't take 9600b anyhow and would send
^S/^Q, same for some network terminal muxes.

I agree with you (at least in spirit) about the ^S/^Q thing but being
as it's resettable easily I really don't think about it much.

	-Barry Shein, ||Encore||

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 07:10:18 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   misquoting . . . .


If I can give some small, oft-repeated advice about speaking to the
media...(I apologize for this slightly off-base note but a *lot* of us
are getting calls from the media about this worm thing, maybe this
will be of some help.)

1. Don't get starry-eyed and speak to them if you're not in a position
to speak to them. They will misquote you, screw it up etc and your
boss will be sure s/he could have done better, is p-o'd that you got
the interview and not him/her and you will feel betrayed (which is
naive.) Remember, you will take the heat if they get it wrong, people
will assume you were somehow unclear.

2. Don't take their questions *too* seriously, they're just poking
around in the dark (particularly about technical matters.) Just say
what you want to see yourself quoted as saying, don't worry if it
doesn't exactly answer the question. Reporters are used to that and
don't care as long as you're giving them stuff they can use in an
article. IT'S NOT A PERSONAL CHAT.

3. If they get rude or press about an issue you don't want to talk
about either smile and tell them the interview has ended or repeat
what you want them to walk away with, politely. Don't fight or argue
with them.

4. Don't be afraid to pause before answering a question and collecting
your thoughts, even it seems awkward, they understand you are thinking
and trying to give a good answer and know better than you do that what
you are about to say might be very important.

If you're the sort of person who can't separate the person from the
issue (eg. worry that you're offending a reporter personally by not
sticking to the question) you don't belong talking to the press. Same
advice if you anger easily. Speaking to the press is a professional
act, not a personal one. Refer them to someone else.

Above all, be courteous and try to tell the truth (or don't say
anything at all, or be absolutely sure you want to deal with the
possible consequences.)

	-Barry Shein, ||Encore||

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 08:27:57 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet, Rlogin, and Terminal Servers

No one else has mentioned it, but it is worth pointing out that RLOGIN
can be made more efficient than TELNET, since a TELNET implementation
has to look at the data stream looking for IACs, whereas RLOGIN (or
SUPDUP) doesn't.  This is not an issue one most unix systems, where
scanning the data stream is not the limiting factor, but it can
make a big difference in a terminal server, where you have (for example)
a poor 68020 trying to deal with 96 terminal lines.

Bill Westfield
cisco Systems.
-------

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 13:57:00 GMT
From:      Ralph.Hyre@IUS3.IUS.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   VIRUS discussion quenched? (was Re: Virus)

Read a disturbing report in the Sunday paper (Pittsburgh Press, pA16),
attributed to 'Press news services; LA Times, distributed by LA 
Times-Washington Post News Service':

"Most of the program has been deciphered, but the computer scientists said 
they were no longer allowed to discuss the virus because of a Pentagon
directive."

I find this disturbing, was a 'gag order' really issued?  By whom?
To what parties?
					- Ralph W. Hyre, Jr.
Internet: ralphw@ius3.cs.cmu.edu    Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 14:46:25 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   VIRUS discussion quenched? (was Re: Virus)

> "Most of the program has been deciphered, but the computer scientists said 
> they were no longer allowed to discuss the virus because of a Pentagon
> directive."

I have no knowledge of this, and the government portion of the Internet
is quite aware that we have decompiled source.  They have requested a
copy but, again, to my knowledge, have made no further requests.

The Berkeley postings to this mailing list and to USENET have reported,
in extensive detail, EVERYTHING that is interesting about this worm.  I
don't believe there is anything to be gained by copies of the source being
readily available.

--keith

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 15:18:08 GMT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC on Internet "Virus", Please



Some years ago, we were worried about the security of our mail relay
machines, and we set a standard task to all local hackers to try  (but
with warning) to break the system. Each time a hole was found, we
fixed it and also tried to appreciate the general lesson too.

general lesson 1 is that you dont allow someone to pull data from a
machine over the net without password authentication in any way (e.g.
pulling mail, fingerd, rwhod etc are all disabled).

general lesson 2 (more obvious) is that you dont let anyone even
execute any program on a machine over the net without password
authentication, the only exception being the implicit execution of the
login program, so there is only one point of entry into execution of
arbitary code, and therefore only one point to audit...

this still leaves you open to one problem - denial of service if
someone sends datas into your system and simply cloggs up the disk -
this can be limited to the denial of mail service, and can be kept to
a minimum by not talking to machines you havnt heard of (e.g. dont
know a name for...)

The facilitiy for executing a program on the body oif a message is
still allowed in our system, but which program (and on which
messages) is specified by recipient only, and
not as part of the message - so we could have problems if recipients
are careless - but we can monitor that.

Having said all this, we are bound to lose, but then we'll learn some
more! 

Maybe there should be an Internet target practice machine

 jon

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Sun, 06 Nov 88 15:18:08 +0000
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RFC on Internet "Virus", Please


Some years ago, we were worried about the security of our mail relay
machines, and we set a standard task to all local hackers to try  (but
with warning) to break the system. Each time a hole was found, we
fixed it and also tried to appreciate the general lesson too.

general lesson 1 is that you dont allow someone to pull data from a
machine over the net without password authentication in any way (e.g.
pulling mail, fingerd, rwhod etc are all disabled).

general lesson 2 (more obvious) is that you dont let anyone even
execute any program on a machine over the net without password
authentication, the only exception being the implicit execution of the
login program, so there is only one point of entry into execution of
arbitary code, and therefore only one point to audit...

this still leaves you open to one problem - denial of service if
someone sends datas into your system and simply cloggs up the disk -
this can be limited to the denial of mail service, and can be kept to
a minimum by not talking to machines you havnt heard of (e.g. dont
know a name for...)

The facilitiy for executing a program on the body oif a message is
still allowed in our system, but which program (and on which
messages) is specified by recipient only, and
not as part of the message - so we could have problems if recipients
are careless - but we can monitor that.

Having said all this, we are bound to lose, but then we'll learn some
more! 

Maybe there should be an Internet target practice machine

 jon

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sun,  6 Nov 88 22:08:08 CST
From:      John Carter <retrac@rice.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: 4BSD TCP Ethernet Throughput

    This is a short followup to a posting I made a while back in which
I responded to Van Jacobson's comments on the poor performance of the
Intel ethernet interface in the SUN-3/280 and similar workstations.
At the time I commented, I had not fully completed my re-implementation
of the V bulk data IPC protocols for the Intel interface.  I recently
completed a a version, and want to make a few corrections to my previous
posting.

    I seem to have been a little hard on the Intel interface.  I am able
to get *peak* process-to-process throughputs (measured as I laid out in the
previous posting) of a little over 8 Mbps (up to 8.2).  This corresponds
to a 1 Mbyte transfer taking about a second (8.4 million bits in 1.02 secs
is about 8.2 Mbps).  Unfortunately, it isn't very stable - it seems to
fluctuate between 6.5 mbps and 8.2 mbps.  It appears that packets are
getting dropped quite often, causing timeouts (argh).  I'm not sure if
it's the interface or a flaky network (outwork net isn't a prime example
of a well laid out and administered Ethernet...).

    Oh yeah, the above numbers are SUN-3/50 -> SUN-3/180.  The best that
I can get the Intel interface to transmit at is 6.3-6.5 mbps.  I attain that
by chaining together 32 packet descriptors for transmission at a time,
then waiting until I get an ACK before I chain the next 32 (no shadow
descriptors, i.e. setting them up while awaiting the ACK).

    This dichotomy (transmit vs receive) seems quite strange, and I don't
have an explanation for it.

    The Intel implementation is quite a bit smaller, thanks to it not
having as many annoying "features" as the LANCE, particularly not having
a hardware CRC tailer appended on every packet (which really made the
optimistic blast implementation gross for handling certain error cases).

John Carter
Rice University

P.S. Several people asked for my opinions on interfaces and such not.
     I've been quite busy lately, I'll try to repond soon.

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 16:51:15 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   a holiday gift from Robert "wormer" Morris

"Wormer" Morris has quite a career ahead of him, i'll bet.
he has done us all a favor by benevolently bashing bsd 'security'.

the smtp/sendmail security hole that he exploited was big enough to 
drive the Whirlwhind computer through -- never mind a few
thousand Suns & bsd vaxes.

the hole was so obvious that i surmise that Morris
was not the only one to discover it.  perhaps other less
reproductively minded arpanetters have been having a field
'day' ever since this bsd release happened. 

some of the more security minded folk out there might have 
archived ps records which could indicate the presence of 
spurious shells spawned from smtp.  depending on how long
Mr. Morris used the security hole, he may be very well qualified
to tell all whether he saw signs of other creative use of the
sendmail security gift.   

in at least one sense, Morris has done a service for the internet.
nobody will be able to continue to "benefit" from the bsd/sysV
sendmail -- which was the true trojan horse.



-- 

 
  	harvard!spdcc!eli

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 88 19:36:10 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

# the hole [in sendmail] was so obvious that i surmise that Morris
# was not the only one to discover it.  perhaps other less
# reproductively minded arpanetters have been having a field
# 'day' ever since this bsd release happened. 

I've known about it for a long time.  I thought it was common knowledge
and that the Internet was just a darned polite place.  (I think it _was_
common knowledge among the people who like to diddle the sendmail source.)

The bug in fingerd was a big surprise, though.  Overwriting a stack frame
on a remote machine with executable code is One Very Neat Trick.
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 01:44:47 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

This has been the second major trojan horse in sendmail.

I think the people working on the code should put a lot more
thought into including code that can cause such serious security
holes EVER, in addition to trying to make sure that test code is
not propagated into "production" environments.

It isn't obvious to me that being able to send mail to commands
is particurally useful even in a debugging environment.

Bill Westfield
cisco Systems.
-------

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 02:02:16 GMT
From:      chend@beasley.CS.ORST.EDU (Donald Chen - Microbiology)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Implications of recent virus (Trojan Horse) attack

In article <1698@cadre.dsl.PITTSBURGH.EDU> sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) writes:
>Now that the crime of the century has been solved and all of the
>bows have been taken it is, perhaps, time to reflect a little more
>on the implications of what has happened.
>
 text deleted
>
>Let's look, for a moment, at the effects of this system (whether
>intended or otherwise). First, it satisfied a public desire for news
>and, one might argue, served as a reassurance to the many technophobes
>out there that our systems are as vulnerable as error prone as they,
>all along, have been arguing. If you don't think that this might have
>social consequences you need only look at things like community bans
>on genetic research have resulted from social policy implemented as
>a result of public distrust. When I was interviewed by a local news

Are you suggesting that the "public" does not have an interest and
responsibility to ask for suitable safeguards from what "they"
consider to be either dangerous or incompletely thought out?
Although people like Jeremy Rifkin have been nuisances to the
practical application of bio-engineered tools, they have also
caused investigators to more completely think out their studies,
AND have forced scientists to explain and defend their approaches
and tools to the people who ultimately fund their research.

>Second, there is an economic conseqence. Since we were unable to
>determine the extent of the programs activities we were forced to
>commit programmers time to installing kernel fixes, rebuilding systems,
>checking user data files, and checking for other damage. That was
>the direct cost. The indirect cost comes from the delay in other

Perhaps I am foolish, but I feel some of the responsibility goes to
whoever left the debug option in sendmail, and to those who allow
promiscuous permissions in their systems.

>
>If we tolerate those who view the network as a playground where
>anyhting goes, we are going to be faced with serious consequences. But
>the answer is not to change the character of the network (by increasing
>restrictions and decreasing freedom of access), but to promote a sense
>of character among the members of the community who work and experiment
>in this network. This puts the burden on us to remember that there
>is a need for us to encourage, teach, and provide examples of the
>kind of behaviors that we need to preserve in order to preserve the
>network.
>

You talk of personal responsibility -to oneself, to one's colleagues,
to one's community - and I heartily agree; however, you also talk of the 
burden we all have to somehow teach and instill in others that sense of
rightness which makes the net possible. This does not insure that those
whom we teach will listen, and even if they do, that they will do it
right away. Perhaps there is an analogy to children who, though they
have been told to "do right", test the limits of their freedom, test the
extent of their personal strengths. We hope that through time and 
experience these children will grow to become an integral part of their
communities - but it takes time.
I do not wish to condone the actions of anyone who disrupts the net or
rips out pages from library books or trashes the environment in which we
all live. Although our site has not seen evidence for this particular
virus, it will, no doubt, be the victim of others. In that vein, we need 
to protect our site from the thrashings of either childish behaviour 
or cynical attacks. This means we treat our sites more protectively -
viz. the family heirloom - yet no so much that growth and evolution
of the system is stifled.
I suspect that part of the openess and collegiality which we would like
pays its price in these attacks. We can only muted the number and
intensity of them

Don Chen
Dept of Microbiology
Oregon State University

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 02:27:19 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
>The bug in fingerd was a big surprise, though.  Overwriting a stack frame
>on a remote machine with executable code is One Very Neat Trick.

       Yes.  But not all that uncommon, given classical C's rather casual 
approach to array sizing.  "login" in V6 UNIX could be broken by submitting 
very long, suitably constructed passwords.

					John Nagle

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 03:47:42 GMT
From:      retrac@RICE.EDU (John Carter)
To:        comp.protocols.tcp-ip
Subject:   Re: 4BSD TCP Ethernet Throughput


    This is a short followup to a posting I made a while back in which
I responded to Van Jacobson's comments on the poor performance of the
Intel ethernet interface in the SUN-3/280 and similar workstations.
At the time I commented, I had not fully completed my re-implementation
of the V bulk data IPC protocols for the Intel interface.  I recently
completed a a version, and want to make a few corrections to my previous
posting.

    I seem to have been a little hard on the Intel interface.  I am able
to get *peak* process-to-process throughputs (measured as I laid out in the
previous posting) of a little over 8 Mbps (up to 8.2).  This corresponds
to a 1 Mbyte transfer taking about a second (8.4 million bits in 1.02 secs
is about 8.2 Mbps).  Unfortunately, it isn't very stable - it seems to
fluctuate between 6.5 mbps and 8.2 mbps.  It appears that packets are
getting dropped quite often, causing timeouts (argh).  I'm not sure if
it's the interface or a flaky network (outwork net isn't a prime example
of a well laid out and administered Ethernet...).

    Oh yeah, the above numbers are SUN-3/50 -> SUN-3/180.  The best that
I can get the Intel interface to transmit at is 6.3-6.5 mbps.  I attain that
by chaining together 32 packet descriptors for transmission at a time,
then waiting until I get an ACK before I chain the next 32 (no shadow
descriptors, i.e. setting them up while awaiting the ACK).

    This dichotomy (transmit vs receive) seems quite strange, and I don't
have an explanation for it.

    The Intel implementation is quite a bit smaller, thanks to it not
having as many annoying "features" as the LANCE, particularly not having
a hardware CRC tailer appended on every packet (which really made the
optimistic blast implementation gross for handling certain error cases).

John Carter
Rice University

P.S. Several people asked for my opinions on interfaces and such not.
     I've been quite busy lately, I'll try to repond soon.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 05:58:51 GMT
From:      jfh@rpp386.Dallas.TX.US (John F. Haugh II)
To:        comp.unix.xenix,comp.protocols.tcp-ip
Subject:   Need help with TCP/SLIP


I am running SCO-Xenix 386 on a Wyse 3216 and am trying to get Phil Karn's
SLIP code to work.  I am looking for documentation, etc., to make this
work.  Anyone who is actually running the code at this very moment will
be immediately deified ;-)

Send mail, I'll summarize to the net.
-- 
John F. Haugh II                        +----Make believe quote of the week----
VoiceNet: (214) 250-3311   Data: -6272  | Nancy Reagan on Richard Stallman:
InterNet: jfh@rpp386.Dallas.TX.US       |          "Just say `Gno'"
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 06:01:10 GMT
From:      hutch@net1.ucsd.edu (Jim Hutchison)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Crackers and Worms

Unix is not a "secure" system.  No system attached to a network is
entirely secure.  Valid and illicit network transactions can be
identical.  A casual shell expansion here, a little flexibility in
input for a mailer there, ... the system not designed to stop intruders
lets them in.  For security, put the machine in a red Tempest can and
seal it up tight.  Or looked at in another light, more damage could
have been done with a modem and 10 popular women's names!

The type of hole through which a recent Deutschlander climbed, still
exists.  The casual hole.  A broken piece of software that did not
get updated, or came back from a backup when the controller scrawled
wild accusations across the system partition.  Human error is real,
it can not be ignored.  Most importantly, it will happen to you.

Locks are for children and honest people.  It is nice to know that
there are "locks" on the doors of the system.  I don't go out cracking
security, I'm simply not interested.  Almost anyone *can* crack
security.  BSD security is not particulary more ventilated than SysVr*,
or VMS.  Software has bugs.  Get it.  If it fails to deliver a letter,
or lets in "the man with no name", it's still just a bug.

Hopefully this article has not fed any hysteria.

/*    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!cs!net1!hutch
		    		ARPA:	JHutchison@ucsd.edu
     These are my opinions, and now you have your perceptions of them. */

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 06:36:35 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP terminalservers and BREAK(/^C)


	From: hedrick@rutgers.edu  (Charles Hedrick)

	Unless I'm misreading him, Chris is saying that telnetd can't tell
	when you've cleared the output buffer on the pty.

You misread me.  You can flush *output*; you cannot flush *user typeahead*.
You should be able to, but some critical information---namely, just how much
to flush---is missing.

Chris

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 07:15:13 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   password aging (from worm discussion)

Be *very* careful how you implement password aging.  If it is done
improperly, it weakens security instead of strengthening it.  For
instance, if the system demands that you replace your password once
every two weeks, and demands that you replace it immediately upon
logging in, users are likely to use `easy' passwords and/or write them
down, since they must remember them only for a short while and since
they have little time to think of a new one.

At any rate, we intend to implement shadow password files here (at U of
MD CSD) if Berkeley does not get to it first.  The way the worm breaks
Unix passwords is by efficiently implementing the Unix `salted' DES
encryption (possibly the worm's author simply used Bob Baldwin's code),
and doing forward encryption on each of the passwords from its
dictionary lists for each account.  If the encrypted passwords are not
readable except from privileged accounts, this method is not available;
the program must instead go through standard accessways such as the
`login' program, which were long ago instrumented to be able to log
apparent breakin attempts.  (Of course, all of this assumes that one is
unable to exploit some existing bug that gives privileged access.  It
also assumes that your Unix vendor has at least kept up with Berkeley's
security improvements since 4.2BSD.)

We already enforce `hard to guess' passwords---dictionary checking is
in 4.3BSD-tahoe, and we had been using similar checking earlier---and,
by some stroke of luck, we had modified the finger daemon, and had a
piggish sendmail: the worm gave it a mere 20 seconds to establish
connections, and we no doubt timed out.  At any rate, the worm never
got established on any UMD CSD machine (though other departments were
affected); but the potential was there, and that is rather
frightening.  The possibility of an efficient brute-force attack on
other user's accounts, given an unprivileged account (as the finger bug
did), is much more so.  Shadow password files suddenly look quite
attractive. . . .

Chris

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 07:27:19 GMT
From:      whwb@cgchb1.uucp (Hans W. Barz)
To:        comp.protocols.tcp-ip
Subject:   X.29 <-> TCP/IP ?

I'am looking for a product which links X.25 to TCP/IP in the following way:
  The X.25 link should work as a X.29/PAD and the TCP/IP link should be
  a terminalserver. This means a PAD could dial to this X.25 address and
  the TCP/IP-terminalserver answers. Dialing from TCP/IP to the terminal-
  server connect the user to the PAD.

Any experiences with such a product are also appreciated.

Hans Barz, CIBA-GEIGY, CH-Basel, Switzerland
mail: whwb.cgch.uucp

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 13:29:10 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   Virus - did it infect "secure" machines

Does anyone know whether the sendmail virus was able to infect
the machines protected by Kerebos?  No flames, please, the question
isn't a statement against Kerebos per se; I just wonder whether
clever people will always find ways into "secure" Unix boxes.
What about machines that have met with tempest specs?

					Rick Spanbauer
					SUNY/Stony Brook

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 13:59:32 GMT
From:      asuvax!anasaz!john@noao.edu  (John Moore)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: a holiday gift from Robert "wormer" Morris
In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
># the hole [in sendmail] was so obvious that i surmise that Morris

According to press reports, RM spent his summers working at AT&T
on "Unix Communications Software Security". Anyone with a source
license check to see if he slipped a trojan horse into uucico
or uuxqt or something?
-- 
John Moore (NJ7E)           {decvax, ncar, ihnp4}!noao!nud!anasaz!john
(602) 861-7607 (day or eve) {gatech, ames, rutgers}!ncar!...
The opinions expressed here are obviously not mine, so they must be
someone else's. :-)
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 15:22:29 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC on Internet "Virus", Please

I to would like to have as much information as possible on the
Virus/Worm in order to better protect my site, and the sites my company
helps to maintain for the Government.  My concern on publishing an RFC
is that it might inspire some bored Grad student or disgruntled
employee on how to write a better and/or more destructive virus/worm.

One suggestion is not to place this RFC in the "public" domain, but to
have some intity maintain it and only send it on request.  Possible
checking out the 's credentials/identity of the requestor first!

------------------------------------------------------------------------
* The opinions expressed here are my own and not those of my employer. *
*  My employer's secretary may disavow any knowledge of my actions.    *
------------------------------------------------------------------------
Scott W. Rogers		Computer Sciences Corporation - Systems Division
AT&T: (703) 876-1363	3160 Fairview Park Dr. - Falls Church, VA 22152
Fax:  (703) 876-4072	Internet: scottr@csc-lons.ARPA
------------------------------------------------------------------------

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 15:55:05 GMT
From:      ferencz@cwsys3..CWRU.Edu (Don Ferencz)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
>
>I've known about it for a long time.  I thought it was common knowledge
>and that the Internet was just a darned polite place.  (I think it _was_
>common knowledge among the people who like to diddle the sendmail source.)
>
>The bug in fingerd was a big surprise, though.  Overwriting a stack frame
>on a remote machine with executable code is One Very Neat Trick.

I wasn't aware of these tricks, but I find them interesting now, knowing
what security hazards they pose.  Is there some place interested
[sick, twisted] individuals like me could get more information on
Morris' handiwork?  It would be a benefit from a security aspect.  I also
realize that presenting such information could be considered another
risk, perhaps "inviting" someone else to subject us to the same
peril (although most of the net is now "immunized" against this
particular virus).


===========================================================================
| Don Ferencz                       |  "And in the end/                   |
| ferencz@cwsys3.cwru.EDU           |   The love you take/                |
| Department of Systems Engineering |   Is equal to the love you make."   |
| Case Western Reserve University   |       -- The Beatles                |
===========================================================================

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 15:57:33 GMT
From:      bukys@CS.ROCHESTER.EDU
To:        comp.protocols.tcp-ip
Subject:   Getting Vendors To Fix Bugs


The never-ending debate in computer security circles is whether to
publicize bugs, or to hide them, hoping the vendor will fix them, someday.

Whatever ones opinions are in this matter, it is clear that the widespread
public embarrassment caused by the worm escapade will lead to a quick response
from the vendors.  Failure to act doesn't look very good when "the network
is the computer".

In light of the power of public embarrassment, here is a modest proposal.
It does NOT address the problem of a malevolent cracker discovering a hole
and instantly exploiting it.  It does address the problem of any vendor's
reluctance to fix bugs or publicize them within a reasonable time.

(1)  Set up an Internet Security Accountability (ISA) organization.  Vendors
subscribe to its services for some reasonable amount.  Failure to subscribe
brands a vendor as one which does not care about security lapses.

(2)  Vendor subscription requires that vendor supply access (to ISA) to
complete source code to every release of software, and in a timely manner.

(3)  ISA employs a crack team of crackers to find security holes in the
systems.  When a hole is found, the bug is reported back to the vendor.
Vendor has two weeks in privacy to produce official patches, which are to
be made immediately available to ISA and the user community.  (Patches
should have no restriction on copying.)  A vendor response of "upgrade
to release X.Y" is not adequate when the previous release is not all that
old.

(4)  Whether or not the vendor produces the patches, when the two weeks is
up, ISA announces the existence of the bug, its ramifications, and the vendor's
patches, if any.  If there aren't any patches yet, the vendor's phone rings
off the hook, and various customers get steamed and cancel orders, etc.

(5)  At the end of that hot two weeks, ISA announces any workarounds that it
has devised, or pronounces the system and vendor hopeless for now.  One hopes
that the stigma attached to the latter is painful enough that vendors will
avoid it.

ISA could publish a newsletter, containing the current inventory of known bugs
and official patches.  Available by anonymous ftp, of course.

Maybe this is all too grandiose.  On the other hand, I think that there are
plenty of responsible people out there who would love to submit bugs reports,
if only there were someplace they could send them where they would have some
effect.  So the crack staff wouldn't have to be very large, since the community
would be providing a lot of "free" expertise.  As to whether vendors could be
made to go for it:  there are lots of things that vendors don't like that they
submit themselves to because the market requires it.  Certification of X.25
protocol implementations, for instance.

Now, will the market require it?

Liudvikas Bukys
<bukys@cs.rochester.edu>

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 16:54:51 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Deja vu wormus


Speaking of dates, Nov 3, 1988 (The Day of the Loud Worm) is also,
according to the Mt Xinu calendar, the 5th anniversary of the 4.2BSD
release.

	-Barry Shein, ||Encore||

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 17:52:04 GMT
From:      kumar@hpindda.HP.COM (Krishna Kumar)
To:        comp.protocols.tcp-ip
Subject:   Re: Deja vu wormus

Just a technical point, Dave -- India sent troops (on the request of the
govt. of the Maldives) to fight the mercenaries who
wanted to overthrow the government of the Maldives. And, as far as I know,
the mercs were successful only in capturing a radio station, and the troops
otherwise succeeded in quelling the coup attempt. 

Regards,
krishna kumar,
Business Networks, HP.

Disclaimer: These views are mine and not HP's, etc. etc...

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 18:11:52 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: virulence of the recent virus

>As a system maintainer, the two best things you can do to increase
>your ability to sleep at night are:
>
>	* enable password aging

In an article in the October 1984 AT&T Bell Laboratories Technical
Journal - "UNIX Operating System Security", F. T. Grampp and R. H.
Morris - some doubt is expressed as to whether password aging really
should help system administrators sleep better at night:

	(Description of how password aging works)

	Four things are wrong here.  First, picking good passwords,
	while not very difficult, does require a little thought, and the
	surprise that comes just at login time is likely to preclude
	this.  There is no hard evidence to support this conjecture, but
	it is a fact that the most incredibly silly passwords tend to be
	found on systems equipped with password aging.

	Second, the user who discovers that the new password is unsound
	or compromised cannot change it within the week without help
	from the system administrator.  (This is a characteristic of
	implementations such as the System V one, which, once you've
	been forced to change your password, don't let you change it
	back for a week; of course, if you *can* change it back
	immediately, aging is pretty much advisory - gh)

	Third, the feature only forces people to toggle back and forth
	between two passwords.  This is not a great gain in security,
	especially if it encourages the use of less-than-ideal
	passwords.  (At an AT&T site, one person told me that it was
	common to add "0" to the end of their password, and toggle it
	between "0" and "1" whenever you were forced to change your
	password - gh)

	Fourth, as implemented, the date and the lifetime of a password
	is encoded, not encrypted, just after the encrypted password in
	the password file.  It is easy to write a program that scans a
	password file and prints out a list of abandoned accounts,
	together with the length of time each account has been unused. 
	Whether this is a horror or a blessing depends on your point of
	view.

>The second of these is the more useful, but both are needed in
>conjunction to close a lot of holes in Unix. This particular one requires
>that the user specify a password with complex characters in it, 
>either non-alphabetic, or numeric mixed with alphabetic and of
>at least a certain length (10 characters seems like a good size).

Except that UNIX systems tend to pay attention only to the first 8
characters of the password.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 18:14:30 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet VIRUS alert


 >> Does sendmail have the ability
 >> of receiving mail for a process?  If so, this is the biggest security
 >> hole I have heard about in a long time.
 >
 >The problem is the implementation, not the concept.  Receiving mail
 >for a process is extremely useful.  Three examples, first, a daemon
 >program that automatically files bug reports.  Two, a program that
 >replies that you've gotten the mail, but aren't reading it because
 >you're on vacation.  Three, a program that takes mail and gateways
 >it to network news groups.

Or, putting it another way, the hole exploited by the worm was not the
mere ability of "sendmail" to deliver mail to a process; it was the fact
that a remote host could force "sendmail" to deliver incoming mail to a
process running a command *specified by the remote host*.  There may
well be some security hole caused by the ability of the *receiving* host
to specify that mail to "4bsd-bugs" be sent to the "bugfiler" program,
but that's a different matter. 

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 18:26:59 GMT
From:      kent@WSL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

A long time ago, in a context far, far away, the standard unit of
bogosity was declared to be the "lenat". Except that, like the coulomb,
1 lenat is so large that one normally uses the microlenat.

We may or may not wish to resurrect this usage. 

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 19:26:54 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

Interesting that you should mention X.25 certification as an example.
It is true that the market requires X.25 certification, but the procedures
and tests them selves are pretty much a joke.

The other problem is that I doubt whether you can get "a crack team of
crackers" to spend weeks or months pouring over the source code of some
random operating system looking for security flaws, and still get vendors
to pay only "a reasonable amount".  I don't see how this could cost any
less than $100K/release.

There is always the current practice of "beta test at a university", or
"put it on the internet", which is a pretty reasonable test.  The weakest
point is still the users..

The sad part about this particular incident is that the sendmail hole
has apparently been known to quite a large number of people for a long
time.  (After all, sendmail is not proprietary to any vendor, and
source are widely available.)  No one did anything about it.  It is
approximately true that the Internet is NOT overly concerned with
security.  The current incident has pointed out that perhaps we should
be somewhat more concerned.

Bill Westfield
cisco Systems.
-------

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 19:38:47 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about SNMP


	Ask snmp-request@nisc.nyser.net for a subscription to the snmp
mailing list.

	Kent England, Boston U

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 19:53:26 GMT
From:      bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus

In article <19881104194515.0.GLR@MOSCOW-CENTRE.AI.MIT.EDU> glr@WHEATIES.AI.MIT.EDU (Jerry Roylance) writes:
>So the first step might be to (quietly) grep unix filesystems for
>some appropriate (cleartext) substrings that would appear in his
>files (ie, pieces of the infecting shell script).  Anyone who owned
>such files before the infection would be suspect.

This would yield circumstantial evidence, at best.

Any information found this way would be obtained illegally, at worst,
unless you have a search warrant against a specific user's files.

Ironically enough, I recall someone else, from another subdomain of
MIT, who recently discussed MIT's refusal to run `arbitron' because it
would glean information from files in users' home directories, which
(in that installation) are considered sacred and private.
-=-
Zippy sez,								--Bob
- if it GLISTENS, gobble it!!

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 20:01:40 GMT
From:      jwegl@DDN-WMS.ARPA (John Wegl)
To:        comp.protocols.tcp-ip
Subject:   Sun to IBM Full Screen Operation

If anyone out there has experienced the following problem and found
a solution we would greatly appreciate any help.

We have a Sun 3/280 connected to the DDN using the Sun provided
DDN interface.  On the back side of the Sun we have a number of
WYSE terminals emulating VT-100s.  We are trying to connect from those
terminals through the Sun and DDN to an IBM system using TELNET and
SIM 3278 on the IBM.  To get into the applications on the IBM we have
to change our TELNET from character mode to line mode.  However, once
we are there we lose some functionality--mainly, we can't get cursor
movement using the arrow keys; and using shift F3 does not do a screen
print but just echoes.  Those are the only problems we have identified
thus far, but there may be others we have not encountered because of
those two.  We have tried turning the echo off until in the application
and then turning it back on at the terminal.  That was supposed to be
a working solution, but no luck so far.  By the way, the IBM is using
the Network Solutions DDN interface package.

Any solutions or suggestions are welcome.

Thanks,
John Wegl
~

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 20:06:23 GMT
From:      dre%ember@Sun.COM (David Emberson)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes:
> "Wormer" Morris has quite a career ahead of him, i'll bet.
> he has done us all a favor by benevolently bashing bsd 'security'.
> 

I knew about this sendmail bug at least four years ago, courtesy of Matt
Bishop (now at Dartmouth).  He wrote a paper detailing at least a half dozen
holes in the Unix system and methods for constructing trojan horses which was
so dangerous that he responsibly decided not to publish it, but instead to
give selected copies to people who could fix some of the problems.  He also
wrote an article for the Usenix newsletter, ;login, which explained how to
write secure setuid shell scripts--a major source of security holes.  Matt did
not "benevolently bash" anyone's machines.  His behaviour, while unsung by
the press and the Usenet community, is an example of the highest in profession-
al and academic standards.  This is the kind of behaviour that we should be
extolling.

It is a pity that the perpetrator of this hack, allegedly Mr. Morris, is now
hailed as a famous "expert" in computer security.  No doubt he will make a
fortune after the noise dies down as a security consultant.  In fact, I saw
someone quoted in this morning's Wall Street Journal as saying that the
perpetrator was someone he would love to hire!  Not I!  I would think that
prison would be a better place for a person who cost the government, several
universities, and many companies untold thousands of man-hours and millions of
dollars in downtime and effort spent tracking this piece of garbage down.  And
it is almost certain that all the copies of the virus haven't been found.

Unfortunately, the press seems to grab hold of every stupid jerk like this and
hail him as some sort of genius.  Somehow the issue of computer security evokes
images of high school kids firing off MX missles or some other vision which
terrifies the public, and the press loves sensation more than substance.  A few
years ago there was pandemonium in the press when someone told them that
terminals with programmable function keys could be trojan-horsed.  Big deal!
But the media broadcast repeatedly the "revelation" that most terminals in the
world had this "bug."  Now they are jumping up and down because the recent
virus made its way into Lawrence Livermore and NASA Ames--even though it didn't
make it into any classified machines.  The news people are more interested in
irresponsibly stirring people into a frenzy than they are in responsible
reporting of facts.

I call upon my fellow computing professionals to promote ethical behaviour
amongst their students and colleagues and to denounce destructive misuse of
computing knowledge.  I also call upon them to refuse to participate in the
glorification of people in the profession who engage in this kind of behaviour.
We must police ourselves and censure those amongst us who engage in this type
of computer crime.  Much is at risk if hysterical reporters cause hysterical
law makers to place restrictions on networks, on the capability of hardware,
on access to computing facilities, or on software.  Computer security costs a
great deal of money, like defense spending.  I for one would rather see this
money go for better things.


			Dave Emberson (dre@sun.com)

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 20:16:30 GMT
From:      mcrware!droid@uunet.uu.net  (Andy Nicholson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
Just a note regarding the recent illness of the internet, etc.  I am sure
that the perpetrator will be found and almost certainly punished in some
way.  But I for one thank the guy.  Fred Cohen and others have been telling
people this could happen for a long time.  Now somebody actually did it, in
a fairly benign manner.  The New York Times article on Saturday implied that
the worm was not supposed to make itself so apparent, but bugs will happen!

Perhaps the plan was not to make such a mess as to force everyone to clean
up the problem, but to simply "mole" into as many systems as possible.  At
some later date the perpetrator could then start pointing fingers.  Upon the
inevitable denials, that person could then say "Look for file XXXXXX and
process XXXX on your system, and then tell me you did not get infected".

You just can't convince some people that something is possible until it is
too late.  I have seen some postings on the net about "Other people know
how to do this too, but we are too polite to do it".  Well, that is not
sufficient.  If you know it can happen, why was this gaping hole left in?
Lucky for us it was a reasonably responsible person who did this instead of
a juvenile "cracker" who thought "Oh boy, wouldn't it be neat to crash
every machine on the internet and delete all their files."  Obviously things
could have been a lot worse.  The fact that these holes were left in and not
fixed is a problem.  Those who were aware of the problem and did not do
anything about it are just as guilty as the person who did.

If these holes had been fixed in the first place, maybe nothing would have
happened.  Maybe next time someone discovers a security hole, they will fix
it instead of being polite and not exploit it.  If you haven't got the time,
then at least post it and maybe someone else will have or make time enough
for fixing security problems.

I'll bet the KGB are laughing their asses off.

Andy Nicholson
Microware Systems   uunet!mcrware!droid
These are my opinions, the company policy manual says so.
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 20:18:47 GMT
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

[FYI: it's spelled "Kerberos", not "Kerebos"]

In article <1792@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes:
>Does anyone know whether the sendmail virus was able to infect
>the machines protected by Kerberos? 

First of all, machines aren't (directly) protected by Kerberos;
network services are.  So, if you run sendmail with debug turned on,
or a fingerd without the range check, or a normal rlogind while
.rhosts files abound, you're vulnerable.  So, yes, a few people who
administer systems here at Athena were a little careless, and
installed mailers with "debug" enabled, and some even left .rhosts in
places.  

The virus didn't get very far at Athena, mostly thanks to from "second
order effects" of kerberos--our fileservers don't run any more daemons
than they have to, or allow remote logins to mere mortals, and most of
our operations staff have been educated about using passwords which
are in a dictionary.  

>No flames, please, the question
>isn't a statement against Kerberos per se; I just wonder whether
>clever people will always find ways into "secure" Unix boxes.

If you want to have some hope of containing things while connected to
a network, be _very_ careful about the network services you run, and
don't run any more servers than you need.

					- Bill

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 22:03:49 GMT
From:      pdb@sei.cmu.edu (Patrick Barron)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Packet filtering for 4.3BSD ?


I have a TCP/IP gateway running 4.3BSD, and I've just been told that it
has to be able to filter packets based on UDP and TCP port numbers, and
possibly on source and destination IP addresses.  Has anyone already modified
4.3BSD to do this sort of thing?  If so, I'd like to see the code...

Thanks,
--Pat Barron
  CMU Software Engineering Institute
  Systems and Network Engineering

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 22:06:54 GMT
From:      jherr@umbio.MIAMI.EDU (Jack Herrington)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC on Internet "Virus", Please

in article <8811071522.AA15390@csc-lons.arpa>, scottr@CSC-LONS.ARPA (Scott W. Rogers) says:
> 
> One suggestion is not to place this RFC in the "public" domain, but to
> have some intity maintain it and only send it on request.  Possible
> checking out the 's credentials/identity of the requestor first!
>

If anything that would only make the hackers more intent on getting it and
using it, if we make it avaliable and say that making one would be 'passe' and
would be like repeating a bad joke twice, chances are half of the hackers
won't care enough to give it the time.

-Jack
 "Got any sweet n' low little fella?"
 "What--? Elvis?! Elvis Presley?!"
 "Mum's the work, I tired of the 15-hour workday of the Vegas Headliner..."
                                                          -Bloom County

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 22:22:02 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Predictable


Spreading like the virus itself I am getting the following "thought
virus" argument from some very predictable (old guard) people:

	This worm is a good reason to stop the widespread acceptance
	of Unix. (INSERT FAVORITE UPPER-CASE DYING O/S HERE) would
	not have been infected by this problem.

Yeah, right, sort of like saying that if everyone drove their cars at
5MPH there'd be less fatalities on the highways.

Doubtless, but wrong.

The benefits of standards in operating systems far outweigh the risks.
Running one of each O/S and making your users try to use them
effectively is a pretty dumb way to try to achieve security.

I hope we can nip *this* thought virus in the FUD. Nice try though.

	-Barry Shein, ||Encore||

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 22:37:39 GMT
From:      zwang@CS.UCL.AC.UK (Zheng Wang, Ext: 3701)
To:        comp.protocols.tcp-ip
Subject:   anonymous messages

There is a person who keep sending anonymous messages to
soc.culture.china. He/she sometimes uses a fake name and
sometimes uses someone else's real name which causes
great confusion. Once there were two messages and each of
them claimed that the other were forged.

Now I guess this person could use sendmail to forge a
message.

Is there any methods to prevent messages from being forged?

Zheng

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Nov 88 22:37:39 +0000
From:      Zheng Wang (Ext: 3701) <zwang@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   anonymous messages
There is a person who keep sending anonymous messages to
soc.culture.china. He/she sometimes uses a fake name and
sometimes uses someone else's real name which causes
great confusion. Once there were two messages and each of
them claimed that the other were forged.

Now I guess this person could use sendmail to forge a
message.

Is there any methods to prevent messages from being forged?

Zheng
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 22:49:15 GMT
From:      gkn@SDS.SDSC.EDU (Gerard K. Newman)
To:        comp.protocols.tcp-ip
Subject:   RE: Virus - did it infect "secure" machines

>From:	 root@sbcs.sunysb.edu  (root)
>To:	 tcp-ip@sri-nic.arpa
>Subject: Virus - did it infect "secure" machines
>Date:	 7 Nov 88 13:29:10 GMT
>Organization: State University of New York at Stony Brook
>
>Does anyone know whether the sendmail virus was able to infect
>the machines protected by Kerebos?  No flames, please, the question
>isn't a statement against Kerebos per se; I just wonder whether
>clever people will always find ways into "secure" Unix boxes.
>What about machines that have met with tempest specs?
>
>					Rick Spanbauer
>					SUNY/Stony Brook

Rick:

TEMPEST is a specification for the controlling of electromagentic
emissions through which data on a computer system can be compromized.
TEMPEST cerfified systems are usually housed in some sort of enclosure
(ranging in size from slightly larger than the machine to a computer
room) which prevents someone from being able to intercept these
emissions and make sense from them.  This in and of itself does not
make it immune from the kind of virus (worm) which infected the
interenet last week.

Typically, a TEMPEST certified machine processes classified data.
It is ILLEGAL (a federal offense) to have a machine connected to the
interenet which contains classified data.  Thus, machines which process
classified data do not in general have network connections to unclassified
networks.

If the virus managed to infect a machine which contains classified data
then someone (the CSSO in DOE-speak) is not doing their job, and is,
as they say in the south, in a heap of trouble.

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:	  SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:	  Gerard K. Newman
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138-5608
Phone:	  619.534.5076

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 23:07:17 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over FDDI

Some time ago, I asked if "everyone" is going to use 802.2 LLC and
RFC-1042 to encapsulate TCP/IP over FDDI.  Only a couple of people
responded, and they said yes.

As I understand (or, more accurately, misunderstand) things, in the
next MAC document 48-bit addresses will be required & 16-bit optional
(good news!).  That means, we have a 13 byte MAC header in front of every
FDDI packet.  If we add an 8-byte 802.2 LLC header in the style of
RFC-1042, then the IP header starts at the wonderous offset of 21.

A (mostly) standard 4.3BSD+VanJacobson/Karels TCP/IP on a machine which
insists on natural alignment requires either byte-copying or aligned
packets.  Byte-copying is generally not a formula for speed.  Copying
from 1-byte to 4-byte alignment is "optimal" if you want to avoid
saturating the network.

If we used an 802.2 LLC encapsulation with a length of 3(mod 4) (e.g.
7 or 11), the IP header would be aligned.  (It would also be aligned
if you use 16-bit addresses with 5-byte MAC headers.)  The only other
evident solutions involve extra hardware.

So, my current questions are: Does "everyone" still think RFC 1042 is a
	good idea?  What have I misunderstood?


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 88 23:39:05 GMT
From:      root@SBCS.SUNYSB.EDU
To:        comp.protocols.tcp-ip
Subject:   RE: Virus - did it infect "secure" machines

Yes, I knew tempest covered EM emissions.  I was referring to a
product that Sun recently announced which was said to meet
".....", a DOD security specification.  I mistakenly inserted
tempest...

					Rick

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 00:18:22 GMT
From:      chuq@plaid.Sun.COM (Chuq Von Rospach)
To:        comp.protocols.tcp-ip
Subject:   Internet Virus: SunOS patches

The following modifications have been approved by Sun Microsystems
Customer Support to fix the current Internet Virus problem.  This is a
set of patches designed to prevent the propagation of the Internet
'worm' that has infected Sun-3 and Vax computers. There are two parts to
this fix:

	1) an adb patch that closes a security hole in sendmail.
	2) a new version of the file /usr/etc/in.fingerd.

If you have any questions about this patch or if the instructions don't
match what you see, contact Sun Microsystems Customer Support via the
800-USA4SUN phone number, via the hotline@sun.com e-mail address, or send
e-mail to Chuq Von Rospach at chuq@sun.com (uucp form: ..!sun!chuq). 

A few notes on the worm. It affects only machines with SMTP-based
connections to computer networks. If your machines are not connected to
outside organizations or are connected only by uucp, you are not at
risk and you may choose to not install these patches. If you do have a
connection with an outside organization (either on the Internet or with
an organization that might have an Internet connection) you are
potentially at risk to infestation. The connections with potential risk
are those that allow you to access another system via commands like
rlogin or telnet. If that is not possible, you are not at risk.

This worm is benign. It's primary purpose is to find other systems in which
to replicate. It does no damage to your system other than sapping system 
resources. Under some circumstances, it can make systems crash due to
resource exhaustion, but otherwise causes few problems.

The worm was specifically targeted at Sun-3 and Vax computers. While the
security hole exists on Sun-2 and Sun-4 machines, they are not at risk from
the current virus. We recommend that you install these patches on any
machine that acts as a gateway between your organization and the rest of the
network and on any machine whose network address is publicly available to
the Internet. We recommend installing these patches on every machine. These
patches are not Sun-specific, they should work for all Berkeley-based Unix
systems.

These patches will work on Sun-2, Sun-3 and Sun-4 machines under releases
3.x and 4.0 and 386i machines under 4.0. Only Sun-3 machines running 3.x
are at risk from the current worm, but all machines are potentially at risk
for future variations of this attack, so every system should be corrected.

Patching sendmail:

The following instructions should be used to fix the security hole in 
sendmail:

	1) log onto the system as root
	2) make a copy of sendmail
		# cd /usr/lib
		# cp sendmail sendmail.debug
	3) find the offset for the debug option in sendmail:
		# strings -o -a sendmail | egrep debug
		124882 debug
	   [note: this number will vary depending on architecture and
	    release. Make sure you use the number appropriate for your
	    system!]
	4) start adb:
		# adb -w sendmail
	   [note: adb does not print user prompts. Just type at it]
	5) put adb into base 10:
		[type the string:] ?m 0 0xffffffff 0
		[there is no response from adb]
		[type the string:] 0t10$d
		[adb responds:] radix=10 base ten
	6) verify the address of the of the debug option:
		[type the string:] 124882?s
		[adb should respond:] 124882:		debug
	   [note: make sure you use the correct number for your system here]
	7) disable the debug option:
		[type the string:] 124882?w 65535
		[adb should respond:] 124882:		25701	=      65535
	   [note: make sure you use the correct number for your system here]
	8) exit adb:
		^D
		#
	9) kill off your sendmail daemon and restart it. 
		# ps -ax | grep sendmail
		1563 ?  I     0:00 /usr/lib/sendmail -bd -q17m
		1849 p4 S     0:00 grep -i sendmail
		# kill 1563
		# /usr/lib/sendmail -bd -q17m &

	10) verify the debug option is disabled:
		# /usr/etc/mconnect
		connecting to host localhost (127.0.0.1), port 25
		connection open
		220 [system dependent header information here]
		[type: ] debug
		500 Command unrecognized
		[type: ] quit
		221 plaid.Sun.COM closing connection

Installing a new fingerd:

Attached to the end of this message is a new version of the program
/usr/etc/in.fingerd. This version fixes a security hole in that program.

To install this on your system, save the program to a file named
in.fingerd.c. Then compile the program with:

	% cc -O  -o in.fingerd in.fingerd.c

Install the new fingerd as follows:

	% su
	# cp in.fingerd /usr/etc/in.fingerd.new
	# cd /usr/etc
	# mv in.fingerd in.fingerd.orig
	# mv in.fingerd.new in.fingerd
	# chown root in.fingerd
	# chmod 755 in.fingerd

Then reboot your system to re-initialize the daemons.

----- Begin of file in.fingerd.c -----
/*
 * Copyright (c) 1983 Regents of the University of California.
 * All rights reserved.  The Berkeley software License Agreement
 * specifies the terms and conditions for redistribution.
 */

#ifndef lint
char copyright[] =
"@(#) Copyright (c) 1983 Regents of the University of California.\n\
 All rights reserved.\n";
#endif not lint

#ifndef lint
static char sccsid[] = "@(#)in.fingerd.c 1.4 88/02/08 SMI"; /* from UCB 5.1 6/6/85 */
#endif not lint

/*
 * Finger server.
 */
#include <sys/types.h>
#include <netinet/in.h>

#include <stdio.h>
#include <ctype.h>

main(argc, argv)
	char *argv[];
{
	register char *sp;
	char line[512];
	struct sockaddr_in sin;
	int i, p[2], pid, status;
	FILE *fp;
	char *av[4];

	i = sizeof (sin);
	if (getpeername(0, &sin, &i) < 0)
		fatal(argv[0], "getpeername");
	line[0] = '\0';
	(void) fgets(line, sizeof(line), stdin);
	sp = line;
	av[0] = "finger";
	i = 1;
	while (1) {
		while (isspace(*sp))
			sp++;
		if (!*sp)
			break;
		if (*sp == '/' && (sp[1] == 'W' || sp[1] == 'w')) {
			sp += 2;
			av[i++] = "-l";
		}
		if (*sp && !isspace(*sp)) {
			av[i++] = sp;
			while (*sp && !isspace(*sp))
				sp++;
			*sp = '\0';
		}
	}
	av[i] = 0;
	if (pipe(p) < 0)
		fatal(argv[0], "pipe");
	if ((pid = fork()) == 0) {
		close(p[0]);
		if (p[1] != 1) {
			dup2(p[1], 1);
			close(p[1]);
		}
		execv("/usr/local/finger", av);
		execv("/usr/ucb/finger", av);
		printf("No local finger program found\n");
		fflush(stdout);
		_exit(1);
	}
	if (pid == -1)
		fatal(argv[0], "fork");
	close(p[1]);
	if ((fp = fdopen(p[0], "r")) == NULL)
		fatal(argv[0], "fdopen");
	while ((i = getc(fp)) != EOF) {
		if (i == '\n')
			putchar('\r');
		putchar(i);
	}
	fclose(fp);
	while ((i = wait(&status)) != pid && i != -1)
		;
	return(0);
}

fatal(prog, s)
	char *prog, *s;
{

	fprintf(stderr, "%s: ", prog);
	perror(s);
	exit(1);
}
----- end of in.fingerd.c -----

----- end of virus patch message -----

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 00:49:20 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

It seems the phrase `shadow password file' is not well known, so here
is a definition:

It means the encrypted passwords themselves (and any other `sensitive'
information) is not kept in /etc/passwd, which is readable by everyone,
but rather in some other file that is not readable except by root
(and/or by other privilege of your choice).  The typical implementation
is to rename the real password file /etc/passwd as something else
(e.g., /etc/pw.shadow), and replace /etc/passwd with a copy that has
the password field replaced with something unusable (`*').  Programs
that really need a user's password run privileged, and are changed to
refer to the shadow file; others use the usual file, but have no access
to the encrypted password.  Updates must happen to both files.

(The phrase comes about from the fact that /etc/passwd is---or has,
depending on your point of view---a `shadow' thrown by another file.)

Chris

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 01:01:59 GMT
From:      spdcc!eli@bbn.com  (Steve Elias)
To:        tcp-ip@sri-nic.arpa
Subject:   legality of filesystem greps
> glr@WHEATIES.AI.MIT.EDU (Jerry Roylance) writes:

>>So the first step might be to (quietly) grep unix filesystems for

 bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes:

>This would yield circumstantial evidence, at best.
>Any information found this way would be obtained illegally, at worst,
>unless you have a search warrant against a specific user's files.

	do you consider Cornell's search of Morris' files to be illegal?
	did Cornell CCS or a department sysadm conduct such a search?
	(the press did report this.)


-- 

 
  	harvard!spdcc!eli
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 02:25:06 GMT
From:      fair@APPLE.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

This has a flaw: suppose a member company sues ISA for defamation (or
whatever else their legal department thinks up)? ISA had better have a
very good legal department to go over all its public pronouncements,
and defend it against litigation.

Also, if ISA goofs...

	Erik E. Fair    apple!fair      fair@apple.com

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 03:01:59 GMT
From:      dtynan@sultra.UUCP (Der Tynan)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet VIRUS alert

In article <8811052345.AA18501@okeeffe.Berkeley.EDU>, bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) writes:
> 
> > Does sendmail have the ability
> > of receiving mail for a process?  If so, this is the biggest security
> > hole I have heard about in a long time.
> 
> The problem is the implementation, not the concept.  Receiving mail
> for a process is extremely useful.  Three examples, first, a daemon
> program that automatically files bug reports.  Two, a program that
> replies that you've gotten the mail, but aren't reading it because
> you're on vacation.  Three, a program that takes mail and gateways
> it to network news groups.
> 
> --keith

I agree with the first poster.  It is a BIG security hole.  I can understand
the justification for piping incoming mail to a process, but this should be
done via the 'aliases' file, not the To: line.  If I can send mail

	To: "|program"

Then why have a /bin/login at all?  This gives me ultimate access to the
machine, without ever needing an account.  If all I can do, is send mail to
an alias, which is in turn, a process, then the final control is from the
person who owns the '/usr/lib/aliases' file.  Perhaps I'm missing something,
but it seems to me, that this is the way the worm propagated.
						- Der
-- 
	dtynan@Tynan.COM  (Dermot Tynan @ Tynan Computers)
	{apple,mips,pyramid,uunet}!zorba.Tynan.COM!dtynan

 ---  God invented alcohol to keep the Irish from taking over the planet  ---

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 03:44:30 GMT
From:      dtynan@sultra.UUCP (Der Tynan)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Worms and Paranoia

In retrospect, from someone who wasn't affected (directly) by the recent worm,
I think the repercussions will be far-reaching, and painful for everyone.
I have to disagree with Weemba's comments about how Morris has done us a
favor (It's not the first time I've disagreed with him - his position is
usually contrary to my own).  In the first place, mail (and news) is backed
up all over the place.  I think it will be that way for some time.  I am
predicting that a lot of 'anonymous' ftp sites will disappear.  More companies
will follow the AT&T example, and stop forwarding mail.  Others will drop
USENET completely.  It is one thing to say that the danger has passed, but
when one looks at the general public's view of other 'virii', a lot of
people tend to be irrational.  They will view the security breech as being
caught 'with their pants down'.  All one has to do is look at the way the
press is handling the whole affair.  The headlines read 'Defense computers
compromised'.  They would have you believe that we were seconds away from
World War III (shades of 'War Games'?).  The popular press has long been
enamoured with the 'Hacker' (their words not mine).  They will probably make
Mr. Morris 'Crown Prince of Hackers'.  As a reference, consider such
luminaries as John Lennon's killer (I refuse to give his name), who did it
purely for the glory (?).  If we could increase the overall network security,
without compromising its effectiveness, then perhaps Morris' attack would be
beneficial.  As it is, the only difference it will bring about, is a stricter
network.  Not necessarily a better or more secure network, but one in which
the flow of data is more controlled.  It is clear that there are a lot more
bugs which could be exploited, to produce even worse effects.  How will these
be discovered?  Hopefully, through dissemination and education.  I, for one,
was not aware that sendmail had that bug (and I certainly don't blame the
fiasco on the person who left the 'debug' option in-place).  Had the
circumstances been different, I would not have been pleased to find out 'the
hard way'.  In general, a lot of people will be asking their System Adminis-
trators, how this could happen, and what has been done to prevent a
reoccurance.  In all honesty, without devoting many man-years to finding the
rest of the bugs, nothing short of 'pulling the plug' will suffice.  In many
cases, this will indeed be the result.  All in all, my goal of working at
home, just took three steps backward, and the process of linking many machines
across the planet, with the concept of 'shared information' has probably
been pushed back irretrievably.
As for Morris' defense, that he didn't expect the program to swamp the machines
I claim that this is no defense.  Consider, that if his program HAD WORKED AS
HE WANTED IT TO, no-one would be the wiser, right now.  What's more, the next
generation of his worm, could transfer the source, when on a machine besides
a VAX or Sun.  In which case, by the time anyone actually discovered the worm,
*every* system on the Internet would be contaminated.  Not to mention the
UUCP network.  Before this gets totally out of hand in terms of public
perception, we need to address the underlying mechanism that lets this happen.
I say, "send him to the salt mines", and we won't have to worry about someone
trying it again...
						- Der
-- 
	dtynan@Tynan.COM  (Dermot Tynan @ Tynan Computers)
	{apple,mips,pyramid,uunet}!zorba.Tynan.COM!dtynan

 ---  God invented alcohol to keep the Irish from taking over the planet  ---

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 06:06:48 GMT
From:      dlr@daver.UUCP (Dave Rand)
To:        comp.protocols.tcp-ip
Subject:   printers over TCP/IP

Is there a "standard" for driving printers with a TCP/IP connection?
We've just wrapped up a small board with a couple of serial ports,
a parallel port, an ethernet chip set, 512K of memory and a 15 Mhz
processor. We would like to use this to drive an HP-Laserjet (using
the parallel), and an Apple Laser printer.

Would a (single direction) telnet connection be appropriate?

Is there an RFC (or some such) that would be a good place to
start for this?

Thanks in advance.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Nov 88 13:48 CST
From:      MARK E. NORTON                              <TMEN0%UMNADMIN.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   MITEK 2030/2130 Systems
I would like to solicit response from anyone familar with the
MITEK TCP/IP products.  I am particularly interested in experience
with their MCP/FS product which allows an IBM 3270 terminal look
like a VT100 terminal for full screen access.

Thanks.
Mark E. Norton
TMEN0@UMNADMIN.BITNET
University of Minnesota Administrative Information Services
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Nov 88 16:47:20 PST
From:      ram@Sun.COM (Renu Raman)
To:        comp.protocols.tcp-ip, tcp-ip@sri-nic.ARPA
Subject:   Re: And You Thought You Were Paranoid...
In article <31997@bbn.COM> wbe@BBN.COM (Winston B Edmond) writes:
>In article <7080011@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes:
>>those huge incremental backups that you keep on disk; or to give you some
>>free space, the worm could silently truncate files that hadn't been touched
>>for three months or so).
>
>Even easier -- use the 10% free space area to hold the virus's files,
>then adjust the used-block count.  The penalty is somewhat worse disk
>performance, and the possibility of detection when the disk is fsck'd,
>but how many people worry about reports that the free block count has
>been adjusted when there are no reports of broken files?
>
> -WBE

    If Morris had used the technique to fix all those sendmail's (fingerd)
    with  the debug option turned on, that would have been the quickest bug fix
    done in the history of computing.  Then what would one call it?
    (in the likes of worm/virus).

    Renu Raman

    Disclaimer:  I speak for myself (isn't that obvious)
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 08:59:52 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   various virus (wondrous worm?) quotes

Thot you all might enjoy some excerpts from some of the more vacuous
articles about the recent infection.

These quotes do not make any more sense in full context. Honest.

As a side issue, I think the virus RFC is an excellent idea, but
please, *please* DO try to get the press to use it as the basis for
their material. Shove it down the throat of PC Week, at least. Part of
the reason the press seems to screw up things so often or make up
things is that they don't have good access to the information. The
suggestion of keeping this RFC out of the hands of the press is
horrible; some publications may screw up now as it is, but they'll
have no hope of getting it right if the information isn't made
available to them.


Both excerpts are reprinted without permission.

ComputerWorld, Nov 7, p157: "MIS reacts"

"...Polaroid Corp. in Cambridge, Mass., told users to minimize their
exposure to the virus by temporarily avoiding use of databases
established by neighbor and virus victim MIT.

"'We always insist that our people don't replicate software or
otherwise violate copyright laws,' said Al Hyland, director of
world-wide systems at Polaroid...

"...Carl Conger, manager of client services at Texas Utilities Co. in
Dallas said, 'Most of our corporate communications is on leased
lines.'"


PC Week, Nov7, p8: "'Worm' Attacks National Network"

"...No data was destroyed, however, leading computer experts to state
that it was a worm, not a virus. A software worm differs from a virus
in that it is a program that installs itself in a system and takes
total control of a computer's resources, while a virus consists of
code that is installed in a program and, when invoked, can spread
throughout a system and destroy data."

			- john romkey
UUCP: romkey@asylum.uucp		ARPA: romkey@xx.lcs.mit.edu
 ...!ames!oli-stl!asylum!romkey		Telephone: (415) 594-9268
Immanentize the Eschaton: Vote BUSH in '88.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 11:03:55 GMT
From:      naim@eecs.nwu.edu (Naim Abdullah)
To:        comp.protocols.tcp-ip
Subject:   And You Thought You Were Paranoid...

One of our staff members here, was suspicious that the recent worm
may have planted trojan horses for crucial binaries like vmunix,
fsck etc. He used "ls -l" to compare the sizes on our infected machine
with that of an uninfected machine and satisfied himself that things were
ok (actually he got a nasty shock when "ls -l" showed up different sizes
but then he remembered he had recompiled stuff to toss out yp and use the
BIND stuff and that is why the sizes were different).

I thought about this and then later remembered Ken Thompson's Turing award
lecture. Here is a worst case scenario which we were spared fortunately.

In PRINCIPLE "ls -l" is not enough. The worm had root priveleges, it could have 
installed a modified /bin/ls so that if one of the files being listed
was fsck, vmunix, ls, telnetd etc (the tampered binaries) /bin/ls
would always show predetermined sizes. In that situation, "ls -l" wouldn't
be enough.

It is even worse than that. Actually, the worm could have replaced cmp
and cc with it's own versions so that even if you recompiled any of the
tampered binaries, cc (which had been tampered itself), would substitute
the phony code instead of the true code. Even recompiling cc wouldn't
work because the phony cc would recognize that it is compiling cc.c and
would put in the extra devious code. Ofcourse, copying sources from
other machines wouldn't work either because ftp, rcp etc have all been
substituted with phony versions. Actually, the bad guy could even have
tampered with tar, dump, restore so that if it is retrieving cc.c or
ls.c or any of the tampered binaries, it retrieves instead a hidden file
(the hidden file lives on the disk, but you would still see the tape
spinning). As you would expect, emacs, vi, less could also
be tampered with, so that they show you the original bsd code, when what you
are looking at is really phony code.

In such a situation, you would have no inkling that there was anything
wrong. The only way to get out of such a situation would be to physically
replace disk packs. And you would only do that if you got suspicious. But
why would you get suspicious, since all the commands are giving you a rosy
picture... ? (probably high disk usage would be one clue, but then the bad
guy was probably smart enough to have tampered with du and df so you wouldn't
see the high disk usage; your partitions would just get full and you would
either blame it on the BSD file system hogging that 10% free space :-) or
those huge incremental backups that you keep on disk; or to give you some
free space, the worm could silently truncate files that hadn't been touched
for three months or so).

This kind of paranioa isn't worth it, but I think given enough incentive,
the bad guy could have carried such a thing out. Ofcourse, the worm would 
have to carry most Unix commands with it, on it's travels but with high
bandwidth networks that might have been ok.

		      Naim Abdullah
		      Dept. of EECS,
		      Northwestern University

		      Internet: naim@eecs.nwu.edu
		      Uucp: {oddjob, chinet, att}!nucsrl!naim

		  

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 12:40:42 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: re NetBIOS/TCP (UDP)

In article <8811010516.AA05874@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
>To: tcp-ip@sri-nic.arpa
>
>Here is where I have the problem.  If you are talking theory or ideals
>you are right of course.  If you are talking implementations of
>NetBIOS/TCP then perhaps the memory issue needs to be revisited.
>If you have an MS-DOS machine, you may find 256k or so of your available
>memory space gone to provide this transparency (example 3c505, FTP SW,
>IBM PC LAN program rdr).  Cut off another 60 - 80k for DOS and many
>of the applications that provide the user with menus and manage the
>files cannot run.  Then what does transparency buy you?
>
>It is my belief that the vendors who invested time/effort/
>brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan,
>Bridge [they weren't 3Com at the time], Network Research Corp) wish
>they had placed their investment somewhere else like NFS or OSI or
>whatever.
>

	[]

	An individual employee of a vendor's view:

	I've implemented NETBIOS on top of ISO as both a host based and
	board based protocol under both DOS and OS/2.  Observations:

		1).  The board is 8 Mhz. 80186 based; the board based protocol
		     is 50% as fast as the host based protocol.

		2).  The host based protocol takes up 128K of space under
		     both DOS and OS/2.  The board based protocool takes up
		     less than 10K of space.

		3).  The board based protocol can support 32 sessions easily;
		     the host based protocol can support at most 8-16 sessions
		     before needing another 64K of memory for data buffers.

	Opinions:

		1).  Under OS/2 you want a host based protocol for performance;
		     under DOS you want a board based protocol for memory.

		2).  Future DOS NETBIOS protocol stacks will be more cognizent
		     of Expanded memory version 4.0;  there is no reason why
		     a 128K driver can't use 64K of DOS memory for code, and
		     a large chunk of expanded memory for data; this would
		     save valuble DOS memory, and also allow more data buffers;
		     i.e. more sessions.


						Larry Backman
						Interlan, Inc.

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 12:56:32 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <76424@sun.uucp> dre%ember@Sun.COM (David Emberson) writes:
>In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes:
>> "Wormer" Morris has quite a career ahead of him, i'll bet.
>> he has done us all a favor by benevolently bashing bsd 'security'.
>
>prison would be a better place for a person who cost the government, several
>universities, and many companies untold thousands of man-hours and millions of
>dollars in downtime and effort spent tracking this piece of garbage down.  And
>it is almost certain that all the copies of the virus haven't been found.

	my opinion is that it is almost certain that others have
	been using such security holes in unix for quite some time.

	i'm glad to see such gaping security holes closed; it is too
	bad that it took a USA Today Worm Program to do this.  ca va.

>Unfortunately, the press seems to grab hold of every stupid jerk like this and
>hail him as some sort of genius.  

	Morris is apparently quite intelligent.  
	but he's also apparently a jerk enough to let his worm get away.

	we may be lucky that it escaped (or was released) before he
	had a chance to slow its propagation speed such that it would
	be more difficult to notice...  or worse.


-- 

 
  	harvard!spdcc!eli

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 13:16:36 GMT
From:      avolio@decuac.dec.com (Frederick M. Avolio)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

Just thought I'd mention that there is a corporation called ISA ...  Don't
remember what ISA means (isavax.isa.com would know).  Anyway, this talk --
hypothetic to be sure -- of suing ISA, etc is going to make one cheif
scientist of ISA real nervous if he ever saw these notes :-).

fma

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 13:48:42 GMT
From:      walsh@endor.harvard.edu (Bob Walsh)
To:        comp.protocols.tcp-ip
Subject:   virus

Since the virus reportedly includes a quick implementation of a password
cracking scheme, since the cracker did not personally aggressively eradicate
it from the internet that night (eg., by using a copy of the virus to
distribute its own fixes or by personally submitting an explanation, fixes,
and an apology), and since it has taken almost a whole week to learn the
facts, I believe that he should NOT be held up as a role model.  The mistake
may not be wholly innocent.

The act was unfortunate.  Increasing the security of the Internet is a
beneficial side-effect, but could have been achieved another way.

I agree that there are many individuals who work in a positive fashion
who unfortunately go unrecognized at times like this.  The cracker possessed
no special skills; others could have done the same thing if given the
inclination.  It is a lack of possession (of judgement over an interval of
time) which sets him apart.

If an RFC is developed, I believe it should include the issues raised in
a very pithy tcp-ip article sent yesterday, which included a discussion of
potential ramifications for the Internet, society's view of computers and
computer scientists...

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 13:54:14 GMT
From:      honey@mailrus.cc.umich.edu (peter honeyman)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   rtm and uucp

John Moore asks:
>Anyone with a source
>license check to see if he slipped a trojan horse into uucico
>or uuxqt or something?

there's not a line of code in honey danber or 4.3uucp that was written
by rtm.

however, rtm's (independent) work on adding protection to uucp served
as the inspiration for honey danber's tight-assed protection scheme.
(e.g., by default, don't send files unless you placed the call; e.g.,
by default don't allow hosts to request files).  his contribution here
was a valuable one.

	peter

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 15:09:21 GMT
From:      matthews@eleazar.dartmouth.edu (Jim Matthews)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert Morris

In article <1445@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
>
>According to press reports, RM spent his summers working at AT&T
>on "Unix Communications Software Security". Anyone with a source
>license check to see if he slipped a trojan horse into uucico
>or uuxqt or something?
>-- 

As a matter of fact, one of the things Robert did at Bell Labs (while
still a high school student, I believe) was fix some of the glaring
security holes in uucp (AT&T Bell Laboratories Technical Journal,
10/84).

It is very easy in the aftermath of something like this to indulge in
the devil theory of crime -- that all bad things must come from evil
minds.  The more you find out about rtm I believe the more you will find
he has in common with the people criticizing his behavior.  He has done
significant work in computer security, including warning people for
years about the security holes that made the worm possible.  He has
worked as a sysadmin for an arpanet host.  He is a serious student of
computer science and was making contributions to the field at an age
when most of us were trying to learn Pascal.  He's also one hell of a
great guy, and no one seems more appalled by the effects of his actions
than he is.

We can argue about the advisability of what he did, but I urge you to
resist the temptation to pigeon-hole someone you don't know on the basis
of fragmentary information.

Jim Matthews
Dartmouth Software Development

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 15:42:51 GMT
From:      thomas@uplog.se (Thomas Hameenaho)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

In article <266@eda.com> jim@eda.com (Jim Budler) writes:
>In article <10521@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:

<text deleted>

>For instance: I have a 19.2K modem. My computer cannot take input
>at that rate. I have two choices. Use vi, or set my interface rate
>below my modem rate. F**k. When they developed emacs they could
>have chosen other keys.

I don't particularly like the Emacs use of ^S/^Q either. We have however
learned to live with it, we use hardware handshake! This is really a big win
anytime. If you have a 19.2Kbaud modem I'll bet it can handle hardware
handshake. Most machines also handles it provided one use enough wires
in the cables between the modem and computer.
-- 
Real life:	Thomas Hameenaho		Email:	thomas@uplog.{se,uucp}
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 15:56:40 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

>According to press reports, RM spent his summers working at AT&T
>on "Unix Communications Software Security". Anyone with a source
>license check to see if he slipped a trojan horse into uucico
>or uuxqt or something?

      This is serious.  The knowledge that this person had the opportunity to
tamper with the master source code for UNIX is very worrisome.  A major 
examination of all AT&T-provided security related code is in order.

      We may not be at the end of this yet.


					John Nagle

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 15:58:26 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   [Dheeraj Sanghi:  Re: Deja vu wormus]

Folks,

My apologies to Dheeraj and others who quickly pointed out my error, which
resulted from reading a local paper early in the incident. I and/or the
paper got it backwards. No political or motivational comment was intended
other than the spooky coincidence, which still stands.

Dave

----- Forwarded message # 1:

Received: from louie.udel.edu by Huey.UDEL.EDU id aa29470; 8 Nov 88 10:53 EST
Received: from mimsy.umd.edu by Louie.UDEL.EDU id aa04602; 8 Nov 88 10:46 EST
Received: from chakra.cs.umd.edu by mimsy.umd.edu (5.58/4.7)
	id AA27540; Tue, 8 Nov 88 10:45:24 EST
Received: by chakra.cs.umd.edu (5.58/3.14)
	id AA24942; Tue, 8 Nov 88 10:47:17 EST
Date: Tue, 8 Nov 88 10:47:17 EST
From: Dheeraj Sanghi <dheeraj@chakra.cs.umd.edu>
Return-Path: <dheeraj@chakra.cs.umd.edu>
Message-Id: <8811081547.AA24942@chakra.cs.umd.edu>
To: Mills@UDEL.EDU
Subject: Re:  Deja vu wormus
Cc: dheeraj@tove.umd.edu


> Now, I see in the news that India has sent mercenaries to the
> Maldives, sleepy little islands in the same sea as Madagascar,
> itself a largish island.
 
> Dave

Hi,
	It is not correct that India has sent mercenaries to the
Maldives. The mercenaries were from Sri Lanka, hired by a politician
in Maldives. India interfered on the request of Maldives government
and forced the mercenaries to flee.

-dheeraj

Dheeraj Sanghi					(301)-454-1516  (off)
Systems Design & Analysis Group			(301)-345-6024	(home)
Dept of CS, U of MD., College Pk. MD -20742	dheeraj@tove.umd.edu

----- End of forwarded messages

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 16:03:29 GMT
From:      hubcap@hubcap.UUCP (Mike Marshall)
To:        comp.protocols.tcp-ip
Subject:   Morris bashers...


Dave Emberson (dre@sun.com) points out how  anti-social  and  ir-
responsible  Robert  Morris was to unleash the worm, and is upset
that Mr. Morris is being glorified at the expense of the net  (in
the form of hundreds of man hours put in by worm eradicators).  I
understand the point Mr. Emberson is making, but I  want  to  ask
him...  if  HE  has  known  about  this hole for four years - why
didn't he do something about getting the word out? What  has  Mr.
Emberson  done to help me close the hole? Nothing. Mr. Morris has
seen to it that the sendmail hole, and several others, are mostly
fixed  across  the  whole network. I wonder how many man hours of
work it would have taken to fix sendmail, finger and the ftp  bug
(that  wasn't part of the worm, but has come to light, I believe,
because of the worm), network wide, under any other circumstances
anyone cares to imagine?

I wish the network only had people as trustworthy as me on it :-),
but you know that there are people out there who will take advant-
age of any security hole they find... our  only  hope  is  to know
about those holes & close them.

So, I don't want to applaud Mr. Morris for his poor judgement  in
unleashing  the  worm,  but  I'm glad the holes are fixed now (no
thanks to you Mr. Emberson!).

-Mike Marshall     hubcap@hubcap.clemson.edu    ...!hubcap!hubcap

DISCLAIMER: If Mr. Emberson has spent the last four years  trying
to  get  everyone  he  knows  to  turn off "debug" on their send-
mails... my apologies to him.  It just seems to me that the  worm
issue  points out once again that "security through obscurity" is
no security at all.

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 16:12:28 GMT
From:      beck@numerian.uucp (Stephen Beck)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Virus: SunOS patches

In article <76492@sun.uucp> chuq@plaid.Sun.COM (Chuq Von Rospach) writes:
>
>These patches will work on Sun-2, Sun-3 and Sun-4 machines under releases
>3.x and 4.0 and 386i machines under 4.0. Only Sun-3 machines running 3.x
>are at risk from the current worm, but all machines are potentially at risk
>for future variations of this attack, so every system should be corrected.

This is WRONG.  Our Sun-3 file server running 4.0 was hit by this worm.

--Stephen Beck
--Technical Staff
--Dept. of Computer Science
--(609) 452-6339
--beck@princeton.edu

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 16:33:01 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: And You Thought You Were Paranoid...

In article <7080011@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes:
>In such a situation, you would have no inkling that there was anything
>wrong. The only way to get out of such a situation would be to physically
>replace disk packs. And you would only do that if you got suspicious. But
>why would you get suspicious, since all the commands are giving you a rosy
>picture... ? (probably high disk usage would be one clue, but then the bad
>guy was probably smart enough to have tampered with du and df so you wouldn't
>see the high disk usage; your partitions would just get full and you would
>either blame it on the BSD file system hogging that 10% free space :-) or
>those huge incremental backups that you keep on disk; or to give you some
>free space, the worm could silently truncate files that hadn't been touched
>for three months or so).

Even easier -- use the 10% free space area to hold the virus's files,
then adjust the used-block count.  The penalty is somewhat worse disk
performance, and the possibility of detection when the disk is fsck'd,
but how many people worry about reports that the free block count has
been adjusted when there are no reports of broken files?

I agree, though, that the next stage of development for virus and worm
programs is to augment offensive techniques (replication methods) with
improved defensive techniques: evading detection by attacking the tool
programs like ps, and limiting execution of the offensive code so that
runtime and disk usage look normal and negligible.
 -WBE

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 16:44:49 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

A better implementation of shadow passwords is not to replace
the encrypted password field with * or something obvious, but to
replace it with the correct number of random characters. Let the
wouldbe cracker TRY and decrypt something that isn't encrypted!

--rick

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 01:16:27 PST
From:      hjs@lindy.Stanford.EDU (Harry Saal)
To:        tcp-ip@sri-nic.ARPA
Subject:   Does anyone have packet traces taken during Viral spread phase?

I would be very interested in receiving any network packet traces taken
while the recent worm hopped about and (re)infected multiple machines
connected by LAN connections/routers.  We would like to see to what
degree the externally visible network traffic stood out from the 
"normal" traffic.  The goal would be to be able to provide earlier warnings
of anomalous behaviour than having a system choke itself to death, and then
try to take action.  For example, I am interested in any observations
as to whether average activity took a nose dive (as other processes clogged
up) or increased (due to the agressive attempts to spread itself).

Any formats of actual traces are of interest (assuming they are described
in some .h file - like fashion somewhere).

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 17:33:54 GMT
From:      raj@PARIS.ICS.UCI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages

I've been meaning to bring this topic up for quite a while so maybe this is
the time to do it.  We all know (don't we?) that anyone can use telnet to
connect to the SMTP port on a machine and directly type in mail, thus making
it appear as though it comes from anyone they like.  This has been taken
advantage of here at UCI by our undergrads a few times.  (Enough that it
started becoming a bother!)  It seems to me as if we could solve this whole
problem once and for all by simply requiring the originating port for SMTP
deliveries to be a privileged port ( < 512 ).  As a matter of fact, we could
probably require the originating port to be 25 as well as the destination port.
(Afterall, a pair of IP addresses and port numbers fully specify a TCP
connection and why would you want 2 SMTP deliveries between the same pair of
machines at the same time?  Anyway, if you do we can always make it simply
"any port number < 512.")

Now, before people start complaining about how this change isn't backward
compatible, etc., let me finish.  For a period of a year or so everyone could
simply insert a header like:

X-Warning: This message arrived at xyz.site through an insecure port.

into any message originating from a non-privileged port.  This way, people
would know to question the authenticity of that message.  After everyone has
changed their SMTP delivery processes (a very minor change, afterall), we
could all remove this notice and actually reject connections from unprivileged
ports, but this may take quite a while (consider how long it's taking for some
places to change over to using nameservers!).

Well, what's wrong this idea?  I figure there has to be something wrong with
it or else it would have been suggested long ago.

-----------------------------------------------------------------------------
Richard A. Johnson                               raj@ics.uci.edu   (Internet)
UCI ICS Assistant Support Manager                  ucbvax!ucivax!raj   (UUCP)
Postmaster / Network Services       raj@tertius.ics.uci.edu (via Nameservers)

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 17:54:21 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Sperry TCP/IP

Morning all,
	    Does anyone out there have a reasonably good grasp of Sperry's
NET5000 TCP/IP implementation? I'm trying to add static routes to do some
testing and things are not working out well. Probably a severe case of
cockpit error but without adequate documentation it's hard to tell.
		ADV***thanks***ANCE

			Chris VandenBerg
			ACC
			(805)963-9431
			(chris@acc-sb-unix.arpa)

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 18:11:34 GMT
From:      everett@hpcvlx.HP.COM (Everett Kaser)
To:        comp.protocols.tcp-ip
Subject:   Re: Implications of recent virus (Trojan Horse) attack

I would propose that there is a place (in our computer-network-society) for
persons attempting to write (non-destructive!) viruses.  There is no better
means of protecting ourselves from destructive viruses than to be constantly
testing ourselves with non-destructive ones.  Of course, there's two small
holes in this logic:  1) there may be a bug in your non-destructive virus
which turns it destructive, accidentally; and 2) non-destructive viruses may
not find all of the possible holes in the system, ie. a destructive virus
may get into the system in a destructive way, which a non-destructive virus
would never find.

I feel that the risk of hole number 1 is worth the benefits.  If a few 100
people KNEW about these holes in the system that were exploited by the 
recent virus, WHY WEREN'T THEY FIXED?  Making a "game" out of non-destructive
viruses would have an anology to the military's "war games";  try testing
your strategies and tactics in a non-destructive way BEFORE getting into
a destructive situation, and hopefully, in that way, cut your losses.

Perhaps a university or some other organization could be set up as a 
"clearing house" for virus tests.  Something along the line of:
   1) John Doe thinks he sees a hole in the security system.
   2) John creates a program to exploit that hole (in a non-destructive way).
   3) John takes that program (along with appropriate documentation, to the
      "clearing house".
   4) The "clearing house" would review it for possible destructive behaviour.
      (This would not be 100% proof that destruction wouldn't occur, but
       would make the likelihood of it much lower, and provides a means of
       "licensing" the virus author to do the test without alerting the
       defenders (sys-admins) that the test is going to be run.)
   5) The test is run, and if successful, all systems will be tightened to
      avoid future use of the hole.
Remember, appealing to peoples sense of "morality" doesn't work.  There are
always terrorists and anti-social people who will behave amorally.  Either
we can strengthen our own defense, or wait for the terrorists to force us
to do it.

Everett Kaser
!hplabs!hp-pcd!everett

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 18:13:45 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Host Requirements RFC

Arun,

The current draft of the Host Requirements RFC is available for anonymous
FTP from host venera.isi.edu with pathname: 

  pub/ietf-hosts.rfc.txt
  
Bob Braden

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 18:44:00 GMT
From:      sam@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   misquoting . . . .

>From: stev@vax.ftp.com
>>it is bad enough that articles misquote someone, i would like to think
>>that most of them dont know they are mucking it up, rather than not caring
>>or trying to twist things to prove their point.
 
>Although I agree with you in spirit I'd be happy to ship you a
>transcript of CBS's coverage on their evening news report of the
>Hacker's Convention a few weeks ago.

I think when Stev said "articles" in the above quote, he was just referring
to USENET/mailing list articles.  (Stev, beat me about the head and neck if
I'm misquoting you :-)  This spawned the discussion of problems with the
press.

Before I read your (very disturbing) account of CBS's mangulation of the
Hackers' Convention, I was already alarmed by the type and amount of press 
this whole Internet virus has gotten.  In the front page and followup
articles in the Boston Globe today (the Globe is a highly acclaimed,
respectable paper for you non-Bostonians) portrayed this Morris character
as a hackers' folk hero.  It seemed to quote countless people praising him
for his brilliance and ingenuity and suggesting that he did us all a favor
by "exposing" this sendmail bug to the Internet at large, but quoted nobody
who in any way, shape, or form said, "Oh great.  What an asshole."

No wonder there's this stereotype.

Shelli Meyers (who works for but doesn't speak for)
FTP Software, Inc.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 18:47:23 GMT
From:      yeongw@LENNON.NYSER.NET
To:        comp.protocols.tcp-ip
Subject:   Re:  Questions about SNMP

Please send SNMP questions to 'snmp@nisc.nyser.net'.

Wengyik

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 18:53:31 GMT
From:      avr@mtgzz.att.com (a.v.reed)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <76424@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes:
< In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes:
< > "Wormer" Morris has quite a career ahead of him, i'll bet.
< > he has done us all a favor by benevolently bashing bsd 'security'.
< 
< I knew about this sendmail bug at least four years ago, courtesy of Matt
< Bishop (now at Dartmouth). He wrote a paper detailing at least a half dozen
< holes in the Unix system and methods for constructing trojan horses which was
< so dangerous that he responsibly decided not to publish it, but instead to
< give selected copies to people who could fix some of the problems.  He also
< wrote an article for the Usenix newsletter, ;login, which explained how to
< write secure setuid shell scripts--a major source of security holes.  Matt did
< not "benevolently bash" anyone's machines.  His behaviour, while unsung by
< the press and the Usenet community, is an example of the highest in profession-
< al and academic standards.  This is the kind of behaviour that we should be
< extolling.

Really? In my book, a key component of professionalism is "owning
the problem". That means you work it until it gets fixed. "Giving
selected copies to people who could fix some of the problems"
(they didn't) is not enough.  Morris did what was necessary to get
the problems fixed. For that, many of us are grateful. And yes,
some of us LIKE people who "own the problem" until it is solved.

				Adam Reed (avr@mtgzz.ATT.COM)

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 18:54:41 GMT
From:      rick@seismo.css.gov  (Rick Adams)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
No one that I know of was aware of these "gaping holes". All of the people
I know of would have fixed it immediately had they know.

Why are you presuming that they were ignored?

The sendmail problem was a bug. No more than that. The person who
turned loose the worm chose to exploit the bug rather than
report it.

An even worse bug in the ftp daemon was found last week. It was fixed
immediately. No one needed to trash some systems to prove that the
bug exisited. A simple piece of mail explaining things got the
problem fixed.

Dont attempt to rationalize an act that was at best unnecessary and
bad judgement and at worst was malicious.

If the intent was malicious, wouldn't you try and explain it away as
an accident? You have no way of knowing.

---rick
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 19:02:42 GMT
From:      khb@SUN.COM (Keith Bierman - Sun Tactical Engineering)
To:        comp.protocols.tcp-ip
Subject:   Re: Crackers and Worms

In article <829@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes:
>Just a note regarding the recent illness of the internet, etc.  I am sure
>that the perpetrator will be found and almost certainly punished in some
>way.  But I for one thank the guy.  
          ^^^^^^^^^^^^^^^^^^^^^^
> stuff deleted
 
>You just can't convince some people that something is possible until it is
>too late.  I have seen some postings on the net about "Other people know
>how to do this too, but we are too polite to do it".  Well, that is not
>sufficient.  If you know it can happen, why was this gaping hole left in?
>Lucky for us it was a reasonably responsible person who did this instead of
>a juvenile "cracker" who thought "Oh boy, wouldn't it be neat to crash
>every machine on the internet and delete all their files."  Obviously things
>could have been a lot worse.  The fact that these holes were left in and not
>fixed is a problem.  Those who were aware of the problem and did not do
>anything about it are just as guilty as the person who did.
>

I know how to get drunk and drive a truck right through a schoolyard.
This would serve to demonstrate why we shouldn't serve such beverages,
and why schools should be protected with huge fences (concrete) and
armed guards.

Of course not everyone wants to live that way.

Note that only universities and research instuitions got infected.
"real" companies have armed guards patrolling the net. This costs $$

This infestation will result in more public hysteria, and will raise
the cost of maintaining the net. Arbitrary levels of security are
possible, but do we wish to bear the costs ?

For comparison, consider: Do we want armed guards at every freeway
on-ramp ? Every corner ?

People who unleash viruses should be shot, or otherwise done away with.

(btw: the excuse that it was an experiment is pretty lame, would we
feel sympathy for a biological reseacher who did the same thing ?
Experiments should remain in the lab. Not the "real" world).

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 19:03:24 GMT
From:      chiba!khb@sun.com  (Keith Bierman - Sun Tactical Engineering)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <829@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes:
>Just a note regarding the recent illness of the internet, etc.  I am sure
>that the perpetrator will be found and almost certainly punished in some
>way.  But I for one thank the guy.  
             ^^^^^^^^^^^^^^^^^^^^^^
> stuff deleted

>You just can't convince some people that something is possible until it is
>too late.  I have seen some postings on the net about "Other people know
>how to do this too, but we are too polite to do it".  Well, that is not
>sufficient.  If you know it can happen, why was this gaping hole left in?
>Lucky for us it was a reasonably responsible person who did this instead of
>a juvenile "cracker" who thought "Oh boy, wouldn't it be neat to crash
>every machine on the internet and delete all their files."  Obviously things
>could have been a lot worse.  The fact that these holes were left in and not
>fixed is a problem.  Those who were aware of the problem and did not do
>anything about it are just as guilty as the person who did.
>

I know how to get drunk and drive a truck right through a schoolyard.
This would serve to demonstrate why we shouldn't serve such beverages,
and why schools should be protected with huge fences (concrete) and
armed guards.

Of course not everyone wants to live that way.

Note that only universities and research instuitions got infected.
"real" companies have armed guards patrolling the net. This costs $$

This infestation will result in more public hysteria, and will raise
the cost of maintaining the net. Arbitrary levels of security are
possible, but do we wish to bear the costs ?

For comparison, consider: Do we want armed guards at every freeway
on-ramp ? Every corner ?

People who unleash viruses should be shot, or otherwise done away with.

(btw: the excuse that it was an experiment is pretty lame, would we
feel sympathy for a biological reseacher who did the same thing ?
Experiments should remain in the lab. Not the "real" world).





Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 19:19:34 GMT
From:      morgan@polya.Stanford.EDU (Robert L. Morgan)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris


I could only sigh as I telnet'ed to the various machines that I use
here on campus to change my passwords last Friday morning (along with
most other users, no doubt), hoping that some "bored graduate student"
wasn't sucking up the cleartext passwords as they passed across our
various braodcast LANs.

The recent viral event makes it very clear that those of us who
promote the use of network-attached computers in their current
insecure state are on the same moral ground with, say, the automotive
engineers and management who manufactured and sold the exploding
Pintos of a few years back.  There is a conspiracy of silence
(acknowledged by those posters who "knew about the bug four years
ago") that we all participate in whenever we design, produce,
purchase, or install such systems without raising the issue of
security.  

Project Athena (among others) has shown that order-of-magnitude
improvements in security are possible without terrible penalties in
performance or usability, but is anyone listening?  I hope people will
keep the implications of the virus attack in mind as they go about
their daily technological work.  A patch to sendmail, putting Mr.
Morris in jail, or saying the Pledge of Allegiance each morning, are
not the answer.

 - RL "Bob" Morgan
   Networking Systems
   Stanford

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 19:35:10 GMT
From:      dudek@frapray.ksr.com (Glen Dudek)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <1445@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
>In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
>># the hole [in sendmail] was so obvious that i surmise that Morris
>
>According to press reports, RM spent his summers working at AT&T
>on "Unix Communications Software Security". Anyone with a source
>license check to see if he slipped a trojan horse into uucico
>or uuxqt or something?

I was system administrator at Harvard's computer science computing
facility while Robert Morris was an undergraduate there.  I found him
to be an intelligent and responsible person.  He volunteered his
assistance in solving difficult problems in network configuration and
routing, and helped to make Harvard a major Northeast news and mail
gateway.  He did not exploit his knowledge of UNIX security
deficiencies to break into systems or install trojan horses, though he
well could have.

I do think that if he did indeed release this worm, he showed
extraordinarily poor judgement.  However, I would not consider it
justice to punish him as a criminal.  I am convinced he had no
malicious intent (please, no arguing about intent and breaking the law -
I am talking about justice, not the law).

I do not think the world need worry about holes that Robert Morris
could have created - I think we need to worry about the ones he didn't find.

	Glen Dudek
	ex-postmaster@harvard.harvard.edu

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Nov 88 08:59:10 -0800
From:      raj@PARIS.ICS.UCI.EDU
To:        Zheng Wang (Ext: 3701) <zwang%cs.ucl.ac.uk@PARIS.ICS.UCI.EDU>
Cc:        tcp-ip%sri-nic.arpa@PARIS.ICS.UCI.EDU
Subject:   Re: anonymous messages
I asked "Well, what's wrong with this idea?" and I got a one sentence response
from Chris Torek:

	The definition of `secure port' is Unix-dependent.

Well, that takes care of that!  Sorry, I didn't realize that.  Of course,
it should have been obvious at the outset that a PC on the network would
destroy that idea even if it *had* been true before! 

(Of course, I also got some rather childish responses from people at ftp.com
and eaton.com, but I guess a certain amount of that should be expected.)

Thanks for straightening me out.

Richard
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 19:48:00 GMT
From:      TMEN0@UMNADMIN.BITNET (MARK E. NORTON)
To:        comp.protocols.tcp-ip
Subject:   MITEK 2030/2130 Systems

I would like to solicit response from anyone familar with the
MITEK TCP/IP products.  I am particularly interested in experience
with their MCP/FS product which allows an IBM 3270 terminal look
like a VT100 terminal for full screen access.

Thanks.
Mark E. Norton
TMEN0@UMNADMIN.BITNET
University of Minnesota Administrative Information Services

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 19:59:15 GMT
From:      mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC on Internet "Virus", Please

In article <8811071522.AA15390@csc-lons.arpa> scottr@CSC-LONS.ARPA (Scott W. Rogers) writes:
>One suggestion is not to place this RFC in the "public" domain, but to
>have some intity maintain it and only send it on request.  Possible
>checking out the 's credentials/identity of the requestor first!

     There is always the problem of "checking out the credentials" and who
get excluded (when they by rights should be included) and what determined
cracker is going to conive his way past the check.  This has been under
discussion in news.sysadmin concerning the two security mailing lists.  The one
on zardoz is open to any "system administrator" while the one on isis requires
at least one recommendation from the sysadmin on a well recoginized site outside
of your organization.  Neither is likely to be fool proof (the fools are just
to damn ingenious) and I would argue that the crackers have a better grapevine
for getting information than browsing through usnet.  Admittedly, in some cases
security is mandated.  The isis list may well be carrying information for which
there may be no immediate or practical fix or work-around.  It justifiably needs
more security than the list on zardoz which should be dealing with more
practical preventative recommendations and warnings (hopefully no messages of
the "If they do this your dead and there's nothing we can do to stop them!"
sort).

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 20:01:59 GMT
From:      matt@oddjob.uchicago.edu (Matt Crawford)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <76424@sun.uucp>, dre%ember.sun.com (David Emberson) writes:
) I knew about this sendmail bug at least four years ago, courtesy of Matt
) Bishop (now at Dartmouth).  ...  His behaviour, while unsung by
) the press and the Usenet community, is an example of the highest in
) professional and academic standards.

How long have you been at sun?  Or how long has anyone at sun known of
the debug hole?  And yet they kept shipping binaries with the hole open.
This is an example of the lowest in conscientious responsibility to the
customer.
				Matt Crawford

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 21:13:17 GMT
From:      jonwest@rosevax.Rosemount.COM (Jon Westbrock)
To:        comp.protocols.tcp-ip
Subject:   ICMP Network Mask Request/Response


	Could someone who has a synopsis of Network Mask Request and 
	Network Mask Repsonse ICMP messages similar to those of RFC 792 
	please send it to me.  I am looking for the same information that 
	is provided in RFC 792.  Thanks.
-- 
Jon Westbrock, Rosemount Inc.                          +1 612 828 3057
Domain: jonwest@Rosemount.COM                   Path: uunet!rosevax!jonwest

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 21:18:40 GMT
From:      schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: Questions about SNMP


    I have some questions about SNMP. Who can help me ???
    I thought of Jeff Case, but I don't know his address.
    Is there anybody else?

    Your prompt answer will be well appreciated!!!

Post your question to "snmp@nisc.nyser.net" and normally
one of the authors or another expert will be able to answer
them.

Marty

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 06:25:09 PST
From:      Merton Campbell Crockett <mcc%etn-wlv.eaton.com@PARIS.ICS.UCI.EDU>
To:        raj@PARIS.ICS.UCI.EDU, zwang%cs.ucl.ac.uk@PARIS.ICS.UCI.EDU
Cc:        tcp-ip%sri-nic.arpa@PARIS.ICS.UCI.EDU
Subject:   Re: anonymous messages
X-Warning: This message arrived at xyz.site through an insecure port.

What's an "insecure port"?  Is it a port with a screw loose?  Or is it one
whose connection advances have been repeatedly rejected?  Or, perhaps, one
established by child process which was forked at an early stage by its
parent?
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 22:26:10 GMT
From:      dre%ember@Sun.COM (David Emberson)
To:        comp.protocols.tcp-ip
Subject:   Re: Morris bashers...

In article <3481@hubcap.UUCP>, hubcap@hubcap.UUCP (Mike Marshall) writes:
> 
> if  HE  has  known  about  this hole for four years - why
> didn't he do something about getting the word out? What  has  Mr.
> Emberson  done to help me close the hole? Nothing. Mr. Morris has
> seen to it that the sendmail hole, and several others, are mostly
> fixed  across  the  whole network.
> 
Actually, as I pointed out, Matt Bishop (and I presume others) did alert
the Berkeley folks about the sendmail bug.  I did not know about the one
in fingerd.  I thought the bug in sendmail was fixed in 4.3BSD.  It seems
that Ultrix and SunOS are mostly 4.2 based.

> DISCLAIMER: If Mr. Emberson has spent the last four years  trying
> to  get  everyone  he  knows  to  turn off "debug" on their send-
> mails... my apologies to him.

I have much better things to do with my time, which was one of my points.

			Dave

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Nov 88 22:35:27 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

In article <8811012301.AA08441@ETN-WLV.EATON.COM> mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) writes:
>...more specifically "why?".  In a rhetorical vein, why does
>EMACS, in general, use standard control characters as application dependent
>function characters?  Why would any application?

Basically, because it is very useful for an application which can involve
text entry to have command characters which cannot be mistaken for text.
This avoids the need to have some sort of mode switch to distinguish text
from commands.  Users quite reasonably tend to feel that all printable
ASCII characters are legitimate text, so a command character must be
a control character, or a sequence thereof.  Moreover, commands get typed
a lot, so it's got to be something simple, preferably a single keypress.

The ASCII standards give most of the control characters quite specific
meanings; in particular, communications systems are **NOT** guaranteed
to be transparent to a lot of them.  Perhaps unfortunately, most real
communications hardware is pretty transparent.  This is a bit less true
than it used to be -- XON/XOFF in particular is a lot more common than
it was ten years ago -- but is still accurate overall.  So it is very
tempting to use ASCII control characters as command characters, and
there is little incentive to hardware manufacturers to provide better
alternatives.  (There is no reason why holding down control and hitting
O should not send something like ESC O, which networks *are* required
to be pretty much transparent to, but existing keyboards don't do that.)

It's an awkward decision for people writing interactive software, text
editors in particular.
-- 
The Earth is our mother.        |    Henry Spencer at U of Toronto Zoology
Our nine months are up.         |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 22:40:09 GMT
From:      scott@attcan.UUCP (Scott MacQuarrie)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Crackers and Worms


There is a product available from AT&T's Federal Systems group called
MLS (Multi-Level Security) which provides B1-level security in a System V 
Release 3.1 environment. I have seen the product on a 3B2, it's availablity
from other vendors would probably require work by those vendors. (Yes Henry,
we might even help them do that :-) ).

Scott MacQuarrie
AT&T Canada Inc.
uunet!attcan!scott

p.s. Opinions are my own.


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Nov 88 22:48:53 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: virulence of the recent virus

In article <6704@venera.isi.edu> cracraft@venera.isi.edu (Stuart Cracraft) writes:
>As a system maintainer, the two best things you can do to increase
>your ability to sleep at night are:
>
>	* enable password aging
>
>	* enable complex passwords

Both are mistakes.  See "UNIX Operating System Security", by F.T. Grampp
and R.H. Morris (the elder!) in the Bell Labs Technical Journal, Oct 1984.

>... If you enable aging, for example, once every
>month or two, every user who logs into your system will be required
>to specify a new password.

On the spur of the moment, which means that he often will make up a poor
password, or simply alternate between two passwords.  "The goal is
laudable.  The algorithm, however, is bad, and the implementation, from
a security standpoint, is just awful..."  (Grampp&Morris)

We thought about this for some time, and concluded that it is better to
gently remind users that their password is getting a trifle old, rather
than forcing them to change it.

>...This particular one requires
>that the user specify a password with complex characters in it, 
>either non-alphabetic, or numeric mixed with alphabetic and of
>at least a certain length (10 characters seems like a good size).

Things like this may be useful in moderation; for example, preventing
overly-short passwords is certainly a good thing.  However, it's very
hard to construct a simple algorithm that reliably ensures good passwords.
You may be discouraging users from choosing inventive passwords by putting
arbitrary barriers in their paths.  Grampp&Morris describe a successful
attack on systems using the above algorithm:  passwords consisting of the
20 most common female first names, followed by a single digit, let them 
onto every single one of the several dozen machines they surveyed.

(Incidentally, Unix truncates passwords to 8 characters, so requiring
10 is pointless.)
-- 
The Earth is our mother.        |    Henry Spencer at U of Toronto Zoology
Our nine months are up.         |uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 23:04:59 GMT
From:      dwaitzma@bbn.com (David Waitzman)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC on Internet "Virus", Please

People have been talking about needing credentials to get access to
certain mailing lists.  I agree with those that say that that won't
work.  I think that Robert Morris, the alleged wormer, has (had) all
the right credentials.

-david

From SNL, 11/5/88:
"Remember: When you link up to a computer, you link up to every computer it
has ever linked up to."

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 23:08:00 GMT
From:      alb@notecnirp.Princeton.EDU (Adam L. Buchsbaum)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <17823@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes:
>      This is serious.  The knowledge that this person had the opportunity to
>tamper with the master source code for UNIX is very worrisome.  A major 
>examination of all AT&T-provided security related code is in order.
>
>      We may not be at the end of this yet.
>
>					John Nagle

Personally, I'd be much more concerned with software that was
written by people who have been clever enough to have not yet
been caught...

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 88 23:19:34 GMT
From:      OLE@CSLI.Stanford.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   X.29 <-> TCP/IP


Hans Barz,
	(I tried sending this to  whwb@cgch1.uucp and got a mailer
error, this might have some general interest though).

	The folks at UCL have done a lot of work on this, JANET uses
X.29 and there is a gateway at UCL which allows you to run a PAD program 
and get out on the X.25 network. I don't think it is a product per
se, but you can get more info from UCL. Send a message to Bruce@ESS.CS.UCL.AC.UK

Ole
-------

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 00:28:25 GMT
From:      jfh@rpp386.Dallas.TX.US (John F. Haugh II)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <17823@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes:
>      This is serious.  The knowledge that this person had the opportunity to
>tamper with the master source code for UNIX is very worrisome.  A major 
>examination of all AT&T-provided security related code is in order.

Not just security related code - but ALL code.

A trojan horse in awk or sed would be just as deadly.  I'm casting my vote
with some other poster who suggested taking a fine toothed comb to all the
UUCP code.

Meanwhile, I'm working on a replacement login so I can have a shadow password
file on this machine.
-- 
John F. Haugh II                        +----Make believe quote of the week----
VoiceNet: (214) 250-3311   Data: -6272  | Nancy Reagan on Artifical Trish:
InterNet: jfh@rpp386.Dallas.TX.US       |      "Just say `No, Honey'"
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 01:18:03 GMT
From:      hd@kappa.rice.edu (Hubert D.)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

I'm on the other side of the fence.  The death bell of 
commercial network software may be tolling.  I wonder
if my site will install ANY code we don't have source for.

We've been looking at software to connect our PCs and MACs
to SUNs and VAXn.  Now, with the possibity of holes and 
backdoors left in place by software vendors,  I don't see
how one can trust object code for communications software
anymore.  I'm going to take a hard think on wheather to
go commercial or install/modify/develop public domain
packages such as KA9Q, NCSA or PCIP (MIT & CMU).

Hubert Daugherty
hd@rice.edu
References: <8811071557.AA03126@hamal.cs.rochester.edu>
Sender: 
Reply-To: hd@kappa.rice.edu (Hubert D.)
Followup-To: 
Distribution: 
Organization: Rice University, Houston
Keywords: 

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 02:43:04 GMT
From:      jass@titan.rice.edu (Jaspal Subhlok)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Can ANU NEWS be obtained by anonymous FTP?

I am looking for a news server to read NNTP news using CMUTEK IP/TCP
software under VMS.  Are there any (ANU NEWS 5.5?) out the waiting
to be FTPed?

Thanks, Hudel

Please reply by direct mail, either to above address or HUDEL@RICECSVM.BITNET

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 03:25:16 GMT
From:      seibel@cgl.ucsf.edu (George Seibel)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <76424@sun.uucp> dre%ember@Sun.COM (David Emberson) writes:
>In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes:
>> "Wormer" Morris has quite a career ahead of him, i'll bet.
>> he has done us all a favor by benevolently bashing bsd 'security'.
 
>I knew about this sendmail bug at least four years ago, courtesy of Matt
>Bishop (now at Dartmouth).  He wrote a paper detailing at least a half dozen
>holes in the Unix system and methods for constructing trojan horses which was
>so dangerous that he responsibly decided not to publish it, but instead to
>give selected copies to people who could fix some of the problems.  He also
>wrote an article for the Usenix newsletter, ;login, which explained how to
>write secure setuid shell scripts--a major source of security holes.  Matt did
>not "benevolently bash" anyone's machines.  His behaviour, while unsung by
>the press and the Usenet community, is an example of the highest in profession-
>al and academic standards.  This is the kind of behaviour that we should be
>extolling.

In all due respect, why?   It didn't seem to be very effective in closing
the hole in sendmail.   Now that everyone is coming out of the woodwork
exclaiming that they've known about this bug for years, I can't help but
wonder why it wasn't fixed.  There were a lot of people running around
a couple of weeks ago under the blissful assumption that their computers
were reasonably secure - they had done all the "right" things, vis a vis
file protections, setuid scripts and the like, and all the while, *anyone*
with the appropriate knowledge (and apparently a lot of people had it)
could have done *anything* they wanted to your machine!   Perhaps that
was no great surprise to many readers of this newsgroup.  Fine.  If that's
the way people want it, then let's be up front and print a warning on
each copy of system software that ships:  "Congratulations!  You just
bought a fine copy of Unix.  Don't keep any files you care about on it."
If we have security holes on our machines that are well known, and we
do nothing to patch those holes, we are asking for trouble.

George Seibel

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 03:26:34 GMT
From:      bzs@ENCORE.COM (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Food for thought...


Is it just possible that we have tolerated a mail system which has
grown so complicated that a program like sendmail with its generalized
regular expressions pattern matchers and massively complicated rules
(and several other complex "support" programs to figure out paths,
like pathalias) is about the simplest program which can do an adequate
job acting as a gateway?

Maybe it's time to start asserting some authority and saying that by
DD/MM/YY only host@legal.domain.name will be accepted and to hell with
all this punctuative creativity. Let creative people find ways to
conform to a standard.

I'll let sendmail speak for itself...(there are over 300 such lines
in a typical config file):

# more miscellaneous cleanup
R$+			$:$>8$1				host dependent cleanup
R$+:$*;@$+		$@$1:$2;@$3			list syntax
R$+@$+			$:$1<@$2>			focus on domain
R$+<$+@$+>		$1$2<@$3>			move gaze right
R$+<@$+>		$@$>6$1<@$2>			already canonical

Complexity breeds error.

(note: This is *not* a bash at sendmail, I honestly have never been
able to think of a much different way to effectively handle the
current miasma of addressing schemes.)

	-Barry Shein, ||Encore||

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 08:28:34 est
From:      eggers@dirac.cc.nd.edu (Mark D. Eggers)
To:        jwegl@ddn-wms.arpa, sun-nets@BRILLIG.UMD.EDU, tcp-ip@sri-nic.arpa
Subject:   Re:  Sun to IBM Full Screen Operation
We use SIM3278 as well, and have found some annoying things. Basically,
you are trying to get a block mode device (the IBM) to act like a
character oriented device (a Wyse terminal). First of all, I think that
SIM3278 handles Wyse 50s directly. You might try direct terminal
emulation. Some of the problems may be due Wyse 50 --> VT 100 --> 3278
translations.

Now once you get the actual keys working, you may find that SIM3278
does not do such a wonderful job, except for CICS applications (we use
it for NOTIS - an online library catalogue and it works fine). Deletes
do not show up until you press the return key, and for many terminal
types, you must press a return key after pressing a function key in
order for it to take effect.

What you may want to investigate is tn3270 for your Suns, available
via anonymous ftp from ucbarpa.berkeley.edu. Your Sun basically ends
up looking like a 3174 controller (complete with type-ahead). Function
keys, delete and insert, PA1, etc., all work as they would on a real
IBM terminal (ack . . .). I use this on a microVAX II running Ultrix 2.2
on a daily basis, and have not gone back to SIM3278 yet.

Don't get me wrong, SIM3278 is a great product (provides for multiple
session, 3270 over TELENET, etc.), but if you have a Sun, you might
as well use tn3270.

Mark Eggers, Network Communications Analyst, University of Notre Dame

--- Standard disclaimers: I don't speak for anyone except myself,
			  and sometimes I wonder about that.
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 09:34:52 CST
From:      fin@uf.msc.umn.edu (Craig Finseth)
To:        raj@PARIS.ICS.UCI.EDU
Cc:        zwang%cs.ucl.ac.uk@PARIS.ICS.UCI.EDU, tcp-ip@sri-nic.ARPA
Subject:   anonymous messages
With the large number of workstations, personal computers, and other
hosts outside of the control of "official, responsible" (note the
quotes) people, you already *must* assume that *all* mail is suspect.

Requiring sendmail to send on a privileged port would force it to run
as setuid root.  There are several efforts to collect the parts of
sendmail that must run privileged (in particular, opening the port to
listen on) into the initialization code, then have sendmail downgrade
itself to enhance security.  Your proposal is in conflict with those
efforts.

Unfortunately, security is a multidimensional problem and it isn't
possible to always win across all dimensions.  *sigh*

Craig A. Finseth			fin@uc.msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 03:50:33 GMT
From:      honey@mailrus.cc.umich.edu (peter honeyman)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   the master source code for UNIX

John B. Nagle observes:
>	... The knowledge that this person had the opportunity to
>tamper with the master source code for UNIX is very worrisome.  A major 
>examination of all AT&T-provided security related code is in order.
>
>      We may not be at the end of this yet.

rtm worked in research.  e.g., he ported bsd tcp/udp/ip to streams,
back when only eighth edition unix had streams.  i believe this was the
first example of a multiplexing stream handler.  it's a pretty neat hack.

rtm had access to the master source code as in master race, but did not
develop in system v at murray hill.

	peter

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 03:51:06 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs


A quick comment on the distribution of bug fixes.  One hopes
that other vendors will NOT follow the example of SGI and
just post patched binaries to Usenet.  They had shipped a
complete uuencoded binary in comp.sys.sgi; such a practice
leaves entirely open the possibility that some could introduce
a trojan horse along the way.  Of course this leaves open
the question of whether any of us *really* read through the
various PD sources we import...  Scary this virus and what
it may lead to.

				Rick Spanbauer
				SUNY/Stony Brook

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 09:04:24 EST
From:      stev@vax.ftp.com
To:        raj@PARIS.ICS.UCI.EDU, tcp-ip@sri-nic.arpa
Subject:   Re: anonymous messages
*It seems to me as if we could solve this whole
*problem once and for all by simply requiring the originating port for SMTP
*deliveries to be a privileged port ( < 512 ).  As a matter of fact, we could
*probably require the originating port to be 25 as well as the destination port.
*-----------------------------------------------------------------------------
*Richard A. Johnson                               raj@ics.uci.edu   (Internet)
*UCI ICS Assistant Support Manager                  ucbvax!ucivax!raj   (UUCP)
*Postmaster / Network Services       raj@tertius.ics.uci.edu (via Nameservers)


wrongo. bullshit. just because your bsd machine believes that some
ports are only for the "superuser" to open doesn't mean my pc does.
or my TOPS-20. or my MVS. there is public domain source for a telnet
running on IBM type and MAC pcs. any of them could be trivally adjusted
to send from a low port.

making faulty assumptions is a good way not to get the security you are 
looking for. if you *really* want this, resolve the name they pass you 
in the HELO and see if the address matches the one you are talking to.

one other thing, you should only print the warning message if they
try and send mail, alot of people are just trying to check an alias
or mailing list.


stev knowles
ftp software
stev@ftp.com
617-868-4878


-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Nov 88 09:08:40 EST
From:      H. Craig McKee <mckee@mitre.arpa>
To:        orion.cf.uci.edu!paris.ics.uci.edu!venera.isi.edu!cracraft@ucsd.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: virulence of the recent virus
>As a system maintainer, the two best things you can do to increase
>your ability to sleep at night are:
>
>	* enable password aging
>
>	* enable complex passwords

Reference: 
National Computer Security Center, Department of Defense
Password Management Guideline, CSC-STD-002-85, December 1985.

One of the recommendations is the use of a pass-phrase, rather than a
"random" password.  What you do is create a list of about 20,000 
legitimate words (4-6 char. in length); then use a random number
generator to select a three-word pass-phrase for each user.  The idea is
(1) the pass-phrase is more random than a character sequence chosen by a
user; (2) the pass-phrase, being pronounceable, is more easily rememberd;
i.e., there is a reduced tendency to write the complex character string
on the terminal/blackboard/etc.

Regards - Craig
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Wed,  9 Nov 88 12:39:28 -0500 (EST)
From:      "Craig F. Everhart" <cfe+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: anonymous messages
Your plan assumes at least two things:
        (a) that spoofers don't have access to privileged accounts on *any*
machine that might send mail, and
        (b) that people maintaining SMTP/TCP mailers would eventually change
their SMTP senders to send from ``privileged'' ports.
Neither of these is particularly true.  But most compromising is the effect
you'd get if (b) were true, the convention became widespread, and yet (a) were
false: all random spoofers would need is to be a sysadmin on some dinky
workstation, and all the ``protection'' you thought you had would vanish.
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 04:48:43 GMT
From:      seibel@cgl.ucsf.edu (George Seibel%Kollman)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <11226@cgl.ucsf.EDU> I write:

>file protections, setuid scripts and the like, and all the while, *anyone*
>with the appropriate knowledge (and apparently a lot of people had it)
>could have done *anything* they wanted to your machine!

Oops.. not *anything*, perhaps *some* things... the sendmail bug doesn't
provide root access; more likely 'daemon' or something of that sort.
One of our local hosts did have the root password cracked in the recent
worm attack, but that was due to poor choice of root password rather
than any of the myriad *other* security holes we learned about courtesy
of Mr. Morris.  My appologies for the misinformation.

George Seibel

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 05:21:39 GMT
From:      ajt@mace.cc.purdue.edu (Andrew J Thomas)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Viruses and VMS



  Most of you are probably aware of the worm ("virus") that spread
around the network last week.  The worm spread by three methods:
password guessing, a sendmail bug, and a fingerd bug.  

  Any VMS systems running TCP/IP software may be vulnerable to
future viruses/worms.  There are two things to check for: the smtp
server, and the finger server.

  We are running the Wollongong TCP/IP software (no eunice).  
The smtp server does not have the debug mode enabled, so it is not 
subject to attack.  This can be checked by telneting to smtpd port 
and typing 'debug'.  If it accepts the debug command, you have a 
potentianl security hole.

  The second bug is in the finger server. The finger server can
read in an optional line of username(s).  The bug is that it doesnt
check to see if the line exceeds the buffer size.  If it does, it
overwrites memory.  You can check this by telneting to the fingerd
port and entering a line longer than 512 chars.  If you get no finger
response, or get an error message, you have a potential problem.
I am not sure how it could be exploited.  

  The Wollongong fingerd program has this bug.  I was unable to get 
the fixed BSD fingerd.c to work.  However, I did come up with a 
solution that seems to work.  I copied [netdist.user]finger.exe 
to [netdist.serv]fingerd.exe.  This change takes effect as soon
as the file is copied, no need to reboot.  I've done this on our
system and it works fine.

  Why does this work?  The Wollongong fingerd has a "feature" 
that causes it to ignore usernames parameters (even though it can 
overrun the buffer reading them) and will just give a list logged on
users, even if information about one user is requested.  Since the 
finger program will not read input, it wont overrun the buffer.  
Its default ouput is the same as fingerd, but without the bug.

  The usual disclaimers apply to this solution.

  I don't know about the CMU TCP/IP code.  Since it is written in 
bliss, and not just a straight port of BSD to VMS, it may not have
any problems.  If anybody knows for sure, I would like to know, and
I am sure others would also.

					Andy Thomas
					ajt@bilbo.bio.purdue.edu
					ajt@j.cc.purdue.edu

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 05:57:40 GMT
From:      leres@ace.ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Virus: SunOS patches

> The following modifications have been approved by Sun Microsystems
> Customer Support to fix the current Internet Virus problem.  This is a

It's interesting to note that it took Sun 5 days to "approve" Berkeley's
patch to sendmail which appeared in comp.bugs.4bsd.ucb-fixes the morning
of November 3rd. (Berkeley's fix to fingerd appeared early November 4th.)

		Craig

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 06:39:44 GMT
From:      net1!hutch@ucsd.edu  (Jim Hutchison)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <44438@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:
>No one that I know of was aware of these "gaping holes". All of the people
>I know of would have fixed it immediately had they know.

>Why are you presuming that they were ignored?

I'm not presuming they were ignored.  *Many* people have been aware of this
particular sendmail bug.  That was not the purpose of the article.  The fact
is, that bugs happen.  This was a sendmail & finger bug.  Before, it was
an ftp bug (and a cute one that was).  Before that, ...

Do you get the picture?

>The sendmail problem was a bug.

O.k. so it was a maintenance feature. :-)  One man's answer to buggy humans.

>Dont attempt to rationalize an act that was at best unnecessary and
>bad judgement and at worst was malicious.

I am not rationalizing about this bug in any positive fashion.  I'm
stating an odvious fact which you are insisting on ignoring.

>If the intent was malicious, wouldn't you try and explain it away as
>an accident? You have no way of knowing.

Malign or accidental, it was still incautious to send out a worm without
thinking about the FBI coming to visit. :-)  Actually, if I did it, I'd
probably confess and plead diminished capacity do to sleep psychosis.

My apologies in advance for any distress these thoughts may cause to
any and all of you folks who did not put this title in your kill file.
/*    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!cs!net1!hutch
		    		ARPA:	JHutchison@ucsd.edu
     These are my opinions, and now you have your perceptions of them. */
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 13:39:03 CST
From:      Glenda Stubblefield <stubblef@ALMSA-1.ARPA>
To:        tcp-ip-request%sri-nic.arpa@ALMSA-1.ARPA
Cc:        stubblef@ALMSA-1.ARPA
Subject:   Virus Questions
All --

We were infected by last week's virus on our VAX 750 running
4.3.  We also have a VAX 780 running 4.3 and several Sperrys
running Unisys Sys V.  The virus seemed to be confined to our
VAX 750 but we are concerned about any possible migration to any
of our other systems.  Basically, what we saw on the 750 was a
tremendous slow down of our system with all kinds of rsh and
compile processes running, using up resources.  We also had quite
a lot of files in /usr/tmp. 

I received a call yesterday from someone who said that he had heard
on the national news that 5.2 had also been infected by this virus.
Does anyone out there know anything about this?  Is there something
we can look for, other than the symptoms that hit our 750?  We
received all the messages about the patch to sendmail and to
fingerd, but haven't heard much after that.  Is anything else going
on that would help us assure ourselves that we have done everything
we should to protect our systems?  We have some questions that are
being thrown around like; "Is there something hiding out there that
is going to jump up and bite us later".

All of our machines are connected through a LAN, and we have
ethernet on all machines.

I would sure appreciate any help/suggestions anyone can offer. 

Thanks,

Glenda Stubblefield
CSDA
St. Louis, MO
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 08:12:35 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Unix 8-character passwords


	From: auspex!guy@uunet.uu.net  (Guy Harris)

	>... specify a password with complex characters in it, 
	>either non-alphabetic, or numeric mixed with alphabetic and of
	>at least a certain length (10 characters seems like a good size).

	Except that UNIX systems tend to pay attention only to the first 8
	characters of the password.

There is, of course, a perfectly good reason for this limit, and it
should be mentioned:  The Unix password encryption algorithm is to use
a `salted' DES to encrypt a constant string using the password as a
key.  DES keys are 56 bits long; ASCII is a 7 bit code; and 8 times 7
is, of course, 56.  It is therefore obvious that there are no passwords
that cannot be specified in at most eight characters, and any more are
theoretically superfluous.  (The `salt' above is to discourage
brute-force attacks using hardware DES implementations.  It is used to
shuffle the E box in some manner.  I am not a cryptographer; I leave
the details to those who are.)

Nonetheless, there are some ASCII characters that are inordinately
difficult to type (for reasons which I would rather not argue on the
TCP-IP list [I myself am firmly in the `Emacs camp': unescaped in-band
flow control is wrong :-) ]).  There is also a question of
implementation of the password reader: can one type a sequence with an
imbedded ASCII NUL?  I would rather that the password reader accept an
arbitrarily long password, and use some mapping function to compress
longer passwords into eight 7-bit `bytes' for use by the modified DES
encrypter.  This longer password would still be `the same' as some
shorter one, but the shorter one might be impossible to enter.  At
worst, you will require people with long passwords either to type the
whole thing every time, or to figure out the equivalent eight character
string.

Chris

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Nov 88 13:31:44 est
From:      encore!pinocchio!bzs@talcott.harvard.edu (Barry Shein)
To:        sam@vax.ftp.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   misquoting . . . .

>>From: stev@vax.ftp.com
>>>it is bad enough that articles misquote someone, i would like to think
>>>that most of them dont know they are mucking it up, rather than not caring
>>>or trying to twist things to prove their point.
>
>>Although I agree with you in spirit I'd be happy to ship you a
>>transcript of CBS's coverage on their evening news report of the
>>Hacker's Convention a few weeks ago.
>
>I think when Stev said "articles" in the above quote, he was just referring
>to USENET/mailing list articles.  (Stev, beat me about the head and neck if
>I'm misquoting you :-)  This spawned the discussion of problems with the
>press.

I think not.  The discussion was about stuff from postings getting
quoted in the press, specifically something by Van Jacobsen. If it
is then we've all lost the thread of this discussion.

	-Barry Shein, ||Encore||
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 08:52:32 GMT
From:      dmr@alice.UUCP
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: rtm and uucp

References: <1445@anasaz.UUCP> <772@mailrus.cc.umich.edu>

Pursuant to the responses of Honeyman and Mitchell to the worries
of Moore and Nagle:

Robert Morris (rtm, Morris Minor, the little enchilada) spent two
summers, several years ago, in our group at Bell Labs.  During
the first, his major accomplishment was a complete rewrite of
the uucp and accompanying software.  As Peter noted, his version
was considerably more secure than previous versions, and some
of his insights influenced HoneyDanBer uucp.  We ran it on our machines
for nearly a year thereafter, but dropped it in favor of HDB,
mainly because HDB was rapidly gaining favor within AT&T, and Robert's
version had no superiority sufficient for us to push it or keep
it going in the absence of its author.  I believe it was
free of intentional trapdoors, unlike sendmail.
In any event, the code is long gone except from backup tapes.

The second summer, his major product was a streams implementation
of TCP/IP that is still the basis of the Eighth/Ninth edition
version of that module.  It has since been reworked considerably,
mainly to remove the vestiges of the socket mechanisms (he started
from the Berkeley code), but again, we have never found any evidence
of funny business that wasn't in what he started with.

None of the work he did is in any product, and he didn't have
any opportunity to tamper with the master source code--
that is really quite far away from Research.

		Dennis Ritchie

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed 9 Nov 88 13:55-EST
From:      Richard Mlynarik <MLY@XX.LCS.MIT.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Shein's ``thought virus'', or, The Risk of Monocultures
Ecologists have known for some time of the many disadvantages of
single-species ecosystems.  The spread of the Sendmail `worm' is a
good illustration of the ravages which a single, well-targeted disease
can inflict upon such an ecosystem.

If I were to try on an ``old guard'' hat (which scarcely fits me) I
could also note that monocultural ecosystems are (naturally) low in
diversity, may be wildly unstable and tend to inhibit the evolutionary
development of hardier or more sophisticated strains.


Anyway, it was fun watching the virus -try- to execute unix shell
commands on -my- workstation!  [I suppose a more effective virus would
have checked each victim's HINFO first -- though I've heard many
administrators of monocultural domains claim that there is no need for
HINFO (or WKS) records, because `everybody knows' that every machine
runs unix.]
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 09:16:27 GMT
From:      hjs@LINDY.STANFORD.EDU (Harry Saal)
To:        comp.protocols.tcp-ip
Subject:   Does anyone have packet traces taken during Viral spread phase?


I would be very interested in receiving any network packet traces taken
while the recent worm hopped about and (re)infected multiple machines
connected by LAN connections/routers.  We would like to see to what
degree the externally visible network traffic stood out from the 
"normal" traffic.  The goal would be to be able to provide earlier warnings
of anomalous behaviour than having a system choke itself to death, and then
try to take action.  For example, I am interested in any observations
as to whether average activity took a nose dive (as other processes clogged
up) or increased (due to the agressive attempts to spread itself).

Any formats of actual traces are of interest (assuming they are described
in some .h file - like fashion somewhere).

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 09:56:33 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   passwords

There has been some discussion regarding passwords and how people use
'silly' ones such as their name, etc.  Left to thier own initiative, people
will not come up with passwords which maximize their effectiveness.

At Los Alamos, and here at Unisys, a program is available to generate
pronouncable passwords, but composed at random.  These password programs
can be made to run inplace of the option of inputting your own.  Each
time you type the 'passwd' command, the system gives you a new one.  If you
don't like it, you can get another until you find one you lik  These
passwords are 8 characters long and difficult to guess, if not impossible,
by a human, although I am sure that a machine could try.  Along with passwords
should be some monitoring of attempts to login.  If the frequency is high
then some attempt should be made to shut the login feature off for some
period of time.  At Los Alamos, with password checking, any attempt to login
in that results in more than 3 failures results in that login name being
'blacklisted' and no further attempts are allowed.

I stongly encourage everyone to use such a password generator and not
allow people to generate their own passwords.  

Password aging is also something that could and probably should be done.
If it is manual, once a year is probably enough.  This allows people to
memorize their passwords for a reasonable period of time.  They can always
request a new password if they believe that their password has been
compromized.  Better would be to age the password based on usage, rather
than time.  Even better would be smart cards which changed passwords
each time one logged on, a one time password.  Further, encryption of
data based on a smart card and exchange of keys for periods of data short
compared to decryption attack capability would be even better.

There are lots of things that computers could do for us to make the systems
we use more secure and add very little incovenience to our life style on
the Internet or in the Academic environment.  We just have to implement them.

dennis

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 13:26:23 GMT
From:      larry@pdn.UUCP (Larry Swift)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
>It seems the phrase `shadow password file' is not well known, so here
>is a definition:
>
>It means the encrypted passwords themselves (and any other `sensitive'
>information) is not kept in /etc/passwd, which is readable by everyone,
>but rather in some other file that is not readable except by root
>(and/or by other privilege of your choice).  The typical implementation
>is to rename the real password file /etc/passwd as something else
>(e.g., /etc/pw.shadow), and replace /etc/passwd with a copy that has
>the password field replaced with something unusable (`*').  Programs
>that really need a user's password run privileged, and are changed to
>refer to the shadow file; others use the usual file, but have no access
>to the encrypted password.  Updates must happen to both files.
                             ^^^^^^^
Updates of what??  Passwords?

You still haven't explained what use /etc/passwd is, especially if the
passwords in it are unusable!

(I'm not a Unix guru, but curious nevertheless.)

Larry Swift                     UUCP: {peora,uunet}!pdn!larry
Paradyne Corp., LF-207          Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981           She's old and she's creaky, but she holds!

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 14:06:35 GMT
From:      folta@tove.umd.edu (Wayne Folta)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <389@ksr.UUCP> dudek@ksr.com (Glen Dudek) writes:
>
>I was system administrator at Harvard's computer science computing
>facility while Robert Morris was an undergraduate there.  I found him
>to be an intelligent and responsible person.  He volunteered his
>assistance in solving difficult problems in network configuration and
>routing, and helped to make Harvard a major Northeast news and mail
>gateway.  He did not exploit his knowledge of UNIX security
>deficiencies to break into systems or install trojan horses, though he
>well could have.
>

Is anyone sure that Morris didn't plant any trojan horses at Harvard?
From the popular press accounts (admittedly the popular press is naive
and sensationalist) Morris had passwords recorded in his account for
machines at MIT and Harvard.  Is this so?  If so, why did he have them?
If so, did his buddies at Harvard give them to him, or did he steal them?

I am sure that Glen Dudek speaks with authority about Morris' helpfulness,
intelligence, and general good nature.  But how can he authoritatively
state that Morris did not compromise Harvard's systems?



Wayne Folta          (folta@tove.umd.edu  128.8.128.42)

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 14:08:11 GMT
From:      folta@tove.umd.edu (Wayne Folta)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris


This is a very difficult case.  If Good Morris is let off because he is
sincere and meant no harm, what about the 2000 Evil Morrises that lurk
in every high school and university in the land?  The next guy could
claim that his destructive program was not meant to be destructive, that
he (or she) only meant to overwrite the systems' message of the day, and
a bug resulted in destroying a filesystem.  (Morris is like a crime buff who,
to prove that it can be done, smuggles a gun onto a plane and hijacks it
to Canada.  He has shown a problem in the system, but he has created the
defense for every would-be hijacker in America.)

And remember, at least two of the well-known Macintosh viruses were not
meant to harm anyone's system, but unexpected side-effects caused crashes.
Morris' program wasn't meant to get loose, but it did.  It wasn't meant to
destroy data but...



Wayne Folta          (folta@tove.umd.edu  128.8.128.42)

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 14:41:05 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: Implications of recent virus (Trojan Horse) attack

If you want to suggest ongoing testing of small viruses in order to be
prepared for the big, dangerous ones, that's fine.  One might even
call it noble.  But such testing should be done on ISOLATED networks
in order to preclude the little jewels from going where they're not
intended.  I don't yet accept the idea that the latest worm was
released `by accident'; but even if so, it was grossly careless.

Once you have a physically isolated network, there is of course no
reason to make the test viruses and worms non-destructive, aside from
the time you'll cost yourself in restoring your system following each
local simulated attack.  But knowledge of that restoral cost would be
useful data to have, perhaps as a function of the virulence of the attack.

I would be very angry with anyone deciding to arrogate to themselves
the position of "official network virus tester," and thereby give
themselves permission to abuse my systems from Far Away.

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 15:42:58 GMT
From:      bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: legality of filesystem greps

In article <2066@spdcc.COM> eli@spdcc.COM (Steve Elias) writes:

>> glr@WHEATIES.AI.MIT.EDU (Jerry Roylance) writes:
>>>So the first step might be to (quietly) grep unix filesystems for...
 
 bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes:
>>This would yield circumstantial evidence, at best.
>>Any information found this way would be obtained illegally, at worst,
>>unless you have a search warrant against a specific user's files.
>
>	do you consider Cornell's search of Morris' files to be illegal?

I don't know, and what I consider doesn't matter.  "I'm a programmer,
not a lawyer, Jim!"  I shouldn't have spoken so confidently.

I just tried to point out that it might be something to consider,
usually in conference with the "L-word people."  They, and the courts,
are the only ones to trust in such questions.  Has anyone asked one?

Also, in reference to my pointing out the occasionally ironic
differences between administrative philosophies and policies between
different organizations even within the same institution (in this
case, AI and Athena at MIT), I have received several pieces of private
mail indicating that I may have pushed some sensitive buttons at MIT.
Of course, each organization has different goals and different
policies toward reaching those goals.  No harm was intended, of
course, and I apologize for any feathers I ruffled.

Time to get more careful again.  Two overly authoritative-sounding
statements in the same note, each causing a fracas - that's a personal
record :-(

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 16:21:36 GMT
From:      ekrell@hector.UUCP (Eduardo Krell)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <17823@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes:

>      This is serious.  The knowledge that this person had the opportunity to
>tamper with the master source code for UNIX is very worrisome.  A major 
>examination of all AT&T-provided security related code is in order.

This is nonsense. He worked at the research center in Murray Hill, which
has nothing to do with the organization in charge of the official System V 
distribution in Summit, NJ.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 16:24:27 GMT
From:      doug@rphroy.UUCP (Doug Caldwell)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   tn3270 on WIN/TCP for VMS

Does anyone have information on the availability of tn3270 for VMS.  Especially
for use with WIN/TCP, however, any implementations would be worthwhile. 
Perhaps replys should be posted to the net in case other sites may be
interested.  Thanks in advance.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 16:59:53 GMT
From:      mcrware!droid@uunet.uu.net  (Andy Nicholson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <76559@sun.uucp>, khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes:
> I know how to get drunk and drive a truck right through a schoolyard.
> This would serve to demonstrate why we shouldn't serve such beverages,
> and why schools should be protected with huge fences (concrete) and
> armed guards.
> 
> Of course not everyone wants to live that way.
> 
> Note that only universities and research instuitions got infected.
> "real" companies have armed guards patrolling the net. This costs $$
> 
> This infestation will result in more public hysteria, and will raise
> the cost of maintaining the net. Arbitrary levels of security are
> possible, but do we wish to bear the costs ?
> 
> People who unleash viruses should be shot, or otherwise done away with.
> 
I see my points were misunderstood.

1) It could have been worse
2) This was an attack made possible by glaring BUGS in system security
3) BUGS should be fixed when discovered
4) I do not in any way condone or support the irresponsible or destructive
	acts of others

In regards to the drunk driving analogy, tell me this:
Do you stand idly by while situations exist to allow less socially responsible
persons than yourself to engage in irresponsible behaviour?
Do you vote against people who try to pass laws against drunk driving?
Or do you encourage people to make it difficult to get drunk and drive?

I do not condone violent or malicious behaviour, but if potential victims
don't do all they can to protect themselves, or at least take reasonable
precautions, then they are targets for maladjusted individuals.  You lock
your house and car don't you?  Do you compile production versions of code
with "back doors"?  Do you avoid dark back alleys at night?

I "thank" RTM (if he really did it, remember, innocent until proven) because
even though in apparently youthful enthusiasm and a lack of intelligent
restraint he released a worm or virus that was not actively malicious - it
did not attempt to destroy people's work.  I "thank" him because he did
this before a purposefully destructive person did it.  I do not "thank" him
directly for committing an irresponsible act, I'm just glad we got off
easy - this time.

What I hope happens from all this is - 
1) System administrators are aware of the need for security.  There will
	always be that element of society that delights in destruction.
2) Once proven guilty, the person who released the worm is punished.  I just
	think they should go easy on him since there was no (apparent) malicious
	intent.  My softness goes away if maliciousness can be proved.
3) Youthful or immature persons who are unable to cope with the frustration
	of being ignored will learn that doing something like this to bring
	attention to their point of view is not socially or morally acceptable.
4) Youthful or immature people who feel like being malicious in any activity
	will be punished for socially unacceptable behaviour.

I guess if you are perfect and did not do *anything* you would now consider
immature when you were younger, my congratulations.

Note that I make some assumptions about motives, etc., but I can only base
my point of view on the limited info available at this time.
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 17:46:17 GMT
From:      gsg!segedy@decvax.dec.com  (Catherine Segedy)
To:        tcp-ip@sri-nic.arpa
Subject:   Lance, Unisoft
Is there anything I should know about combining a Lance ethernet chip, Unisoft+
software, and a 68010 board?  Ie.  Should this combination work ok if I
just use the ethernet software the same way I would anywhere else?  If there
is anything funky I should know about, can you please let me know?  Please
mail to me and I'll summarize if anyone else is interested.
thanks in advance,
					Cathy Segedy

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
decvax!gsg!segedy
harvard!gsg!segedy

I am not a liberated woman because I have ALWAYS been free.
			Thanks MOM, thanks DAD, for raising me right!

my views are my own and are not necessarily those of my employer, my
co-workers, or my teddy-bear!!
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 18:07:35 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
>.... a description of a 'shadow' (i.e. a dummy) password file
>
>The typical implementation is to rename the real password file>
>/etc/passwd as something else (e.g., /etc/pw.shadow), and replace
>/etc/passwd with a copy that has the password field replaced with
>something unusable (`*').

A more sneaky approach would be to replace the password field with
something that looked like an encrypted password although it didn't
cipher into anything significant. If you did that, the bad guy would
waste his/her time on the usual password file attacks without getting
anywhere. Putting something unusable (like `*') as the encrypted
password would just tell the bad guy not to bother with that approach.
That may or may not be a good thing.

		Jim
-- 
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 18:21:22 GMT
From:      wrl@Ford-cos2.ARPA (Bill Lewandowski)
To:        comp.protocols.tcp-ip
Subject:   MMDF - Remote Mail Program

Hi All,

I would like to know if anyone can point me to a person, place
thing (company) that can give me information on the Remote Mail
program called "MMDF". As I understand it, a host can receive
mail for an address, example  "Harry%Sun-Cos@Ford-Cos2.arpa".
Ford-COS2 would hold the mail and then Sun-Cos would
call Ford-Cos2 and then retrieve the mail via an 
async line dial-up (I could be wrong though).

I know that the Army is a big user of this program (routine).

I would appreciate and information on MMDF or if anyone out there
knows of a program thats about like this, I would really
appreciate hearing about it.

Bill Lewandowski
Ford Aerospace Corp
(719)594-1899
wrl@ford-cos2.arpa

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 18:36:07 GMT
From:      guy@auspex.UUCP (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet VIRUS alert

>I agree with the first poster.  It is a BIG security hole.  I can understand
>the justification for piping incoming mail to a process, but this should be
>done via the 'aliases' file, not the To: line.

I suspect the second poster agrees with you; the example he gave is
probably implemented via the "aliases" file.  The notion of delivering
mail to a program is not flawed; the problem is that this should only be
at the discretion of the recipient, not the sender. 

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 19:39:03 GMT
From:      stubblef@ALMSA-1.ARPA (Glenda Stubblefield)
To:        comp.protocols.tcp-ip
Subject:   Virus Questions

All --

We were infected by last week's virus on our VAX 750 running
4.3.  We also have a VAX 780 running 4.3 and several Sperrys
running Unisys Sys V.  The virus seemed to be confined to our
VAX 750 but we are concerned about any possible migration to any
of our other systems.  Basically, what we saw on the 750 was a
tremendous slow down of our system with all kinds of rsh and
compile processes running, using up resources.  We also had quite
a lot of files in /usr/tmp. 

I received a call yesterday from someone who said that he had heard
on the national news that 5.2 had also been infected by this virus.
Does anyone out there know anything about this?  Is there something
we can look for, other than the symptoms that hit our 750?  We
received all the messages about the patch to sendmail and to
fingerd, but haven't heard much after that.  Is anything else going
on that would help us assure ourselves that we have done everything
we should to protect our systems?  We have some questions that are
being thrown around like; "Is there something hiding out there that
is going to jump up and bite us later".

All of our machines are connected through a LAN, and we have
ethernet on all machines.

I would sure appreciate any help/suggestions anyone can offer. 

Thanks,

Glenda Stubblefield
CSDA
St. Louis, MO

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 19:40:24 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages

>From: raj@PARIS.ICS.UCI.EDU
>
>I've been meaning to bring this topic up for quite a while so maybe this is
>the time to do it.  We all know (don't we?) that anyone can use telnet to
>connect to the SMTP port on a machine and directly type in mail, thus making
>it appear as though it comes from anyone they like.  This has been taken
>advantage of here at UCI by our undergrads a few times.  (Enough that it
>started becoming a bother!)  It seems to me as if we could solve this whole
>problem once and for all by simply requiring the originating port for SMTP
>deliveries to be a privileged port ( < 512 ).  As a matter of fact, we could
>probably require the originating port to be 25 as well as the destination port.
>(Afterall, a pair of IP addresses and port numbers fully specify a TCP
>connection and why would you want 2 SMTP deliveries between the same pair of
>machines at the same time?  Anyway, if you do we can always make it simply
>"any port number < 512.")
>
	Many services (rsh, etc.) require the port number to be in the range
	512 to 1024.  Under UNIX this is considered a privleged port, the
	lower ports are reserved for servers.

	One potential problem I see, what if someone tries to establish a
	connection to send you mail while your busy trying to talk to another
	system.  If you are using port 25 to send with, who's listening for
	mail?

	Because the 1024 bit is not standard, some implementations of TCP
	allow any old program to use lower port numbers...

	Also this is great, until someone with root on another machine
	tries to pull another fast one.  Of course if you monitor
	your machine closely you would notice the attempt...

>Now, before people start complaining about how this change isn't backward
>compatible, etc., let me finish.  For a period of a year or so everyone could
>simply insert a header like:
>
>X-Warning: This message arrived at xyz.site through an insecure port.
>  ... text deleted

	"insecure"?  Of course many people in government circles (check my
	address) are distinctly paranoid at the moment...

	What exactly would this buy us?  If it was really a mail item it
	doesn't matter, if an attack nobody gets the mail!  Just have
	the mailer log ports too.

Joel

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 20:46:52 GMT
From:      bill@UHCCUX.UHCC.HAWAII.EDU (William J. King)
To:        comp.protocols.tcp-ip
Subject:   Re: Crackers and Worms

Well,
   What would prescribe as just punishment for the Wiz of Cornell?

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 20:51:06 GMT
From:      bill@UHCCUX.UHCC.HAWAII.EDU (William J. King)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

No problem, Ultrix encripts the passwords nicely! 
.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 21:13:43 GMT
From:      rick@seismo.css.gov  (Rick Adams)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <1242@ucsd.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes:
> I'm not presuming they were ignored.  *Many* people have been aware of this
> particular sendmail bug.  That was not the purpose of the article.  The fact
> is, that bugs happen.  This was a sendmail & finger bug.  Before, it was
> an ftp bug (and a cute one that was).  Before that, ...

I have not been able to find ONE person who claims to
have known that sendmail compiled with DEBUG on would have allowed
anyone with SMTP access to run an arbitrary program on their machine.

Yet I keep hearing that "*Many*" people were aware of it. Lots of
people knew that sendmail had a debug mode, but I still haven't found one
that will admit that they knew you could run an arbitrary program.
The ability to run the program is the bug, not the fact that sendmail
has a debug mode.

The fact that you can run an arbitrary program is such an obvious
security hole that I can't believe anyone wouldn't report it if they knew.

So, name 5 of these many people and I'll drop the issue. (I WILL ask
them why they didn't think it was worth sending to Berkeley as a bug)

The "fact" that "many" people were aware of this sendmail bug is still
totally unsubstantiated. Now's your chance.

---rick
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Nov 88 06:04 PST
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Paranoia**2 (UNIX source?)
>       This is serious.  The knowledge that this person had the opportunity to
> tamper with the master source code for UNIX is very worrisome.  A major
> examination of all AT&T-provided security related code is in order.
>
>       We may not be at the end of this yet.

How many "worms" or other "users" of the sendmail bug were there
before this one? (The final? one).

As it sounds like the worm ran as root on many systems, didn't
EVERYONE have a chance at the master source code for UNIX?  How
well protected were the sites which hold "distribution" sources
like AT&T or Berkeley?

What's going to be in the next versions shipped?

Also how do you know that RTM really wrote the worm?

I'm not really disagreeing, it just seems that noone has pointed
out that ANYONE could have planted ANYTHING on any "open" system
before the incident.

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 22:07:20 GMT
From:      pavlov@hscfvax.harvard.edu (G.Pavlov)
To:        comp.protocols.tcp-ip
Subject:   Re: Morris bashers...

In article <76593@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes:
> 
> > DISCLAIMER: If Mr. Emberson has spent the last four years  trying
> > to  get  everyone  he  knows  to  turn off "debug" on their send-
> > mails... my apologies to him.
> 
> I have much better things to do with my time, which was one of my points.
> 
    Great.  But time enough to waste discussing Mr. Morris :-)

    It is hard to accept that our Unix system vendors promote this half-baked
    attitude.  But given the number of people who have stepped forth to pro-
    claim that they, too, knew about this hole and were kind enough not to
    muck around with our systems really makes me wonder who takes responsibi-
    lity for what.

    I run an end-user shop.  I adopted Unix for several reasons, a big one
    being the flexibility it gives me in selecting hardware and bargaining
    with vendors.  In turn, I expect that I and my people have to invest
    a lot of time in understanding what we are working with, arcane manuals
    and all.  Fair enough.  But to learn that our current and (maybe) future
    vendors distribute software with known and easily-fixed security bugs is
    disheartening in the least.

    There is, to me, a touch of insanity in this security issue.  I have seen
    innumerable messages during the past three years, which state that yes,
    there are problems, but no, we will not discuss them because that will
    simply invite potential destruction and havoc.  So instead, we learn 
    about them after they are mass-broadcast through the press.

    Is this the only way ?  Or does everyone like me have to spend whatever
    Unix saves us on developing/paying for the necessary expertise to protect
    ourselves ?  

     greg pavlov, fstrf, amherst, ny
    

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 22:22:43 GMT
From:      jqj@HOGG.CC.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris


	Date: 7 Nov 88 20:06:23 GMT
	From: dre@sun.com
	Subject: Re: a holiday gift from Robert "wormer" Morris
	To: tcp-ip@sri-nic.arpa
	Message-Id: <76424@sun.uucp>

	I knew about this sendmail bug at least four years ago,
	courtesy of Matt Bishop (now at Dartmouth).  He wrote a paper
	detailing at least a half dozen holes in the Unix system and
	methods for constructing trojan horses which was so dangerous
	that he responsibly decided not to publish it, but instead to
	give selected copies to people who could fix some of the
	problems.

This raises another interesting question:  what is the responsibility
of the major Unix vendors vis. such network security problems?  If
these security holes have in fact been known by people in SUN and DEC
(not to mention Berkeley) for years, why weren't they fixed?

I believe that the ONLY way we are going to see most of these Unix
security problems resolved is to beat on the vendors to fix them in
their next releases.  We are being totally irresponsible if we use
the Unix from vendor X, know about a major security hole in X's Unix,
and don't SPR it.  X is being totally irresponsible if they don't
fix problems SPRed, and quite irresponsible not to be fixing problems
that are "common knowledge".

A test:  will the next releases of SunOS and Ultrix include
   -	a sendmail without the "debug" bug
   -	a fixed fingerd
   -	a fixed ftpd
   	...etc.?

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 22:39:27 GMT
From:      forrest@CSA3.LBL.GOV
To:        comp.protocols.tcp-ip
Subject:   An Obvious Security Problem?

I am a complete novice at matters relating to networking and haven't
read the Telnet RFC so I may be missing something obvious.

Assume the following network organization:


A <------------------> M <------------------> Z

(Node M is actually one or more gateways.) Couldn't a bad guy on M
monitor the TCP/IP traffic looking for Telnet connections and then
follow through the exchange of login names and passwords, thereby
capturing a node/login and password pair? (I realize that the
path from A to Z is dynamic and that this might not always be
possible.)

Jon Forrest
Lawrence Berkeley Lab
FORREST@LBL.GOV

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 22:41:14 GMT
From:      bill@UHCCUX.UHCC.HAWAII.EDU (William J. King)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

Perhaps the Computer Science programs should:
    1.  require students to take ethics, humanities and social science
        courses.
    2.  restructure their programs such the early years are not simply
        set up to flunk out all but the 'compulsive' hackers.  Fortunately
        these programs do NOT succeed, and ' a few good men & women' get by.
Furthermore:
    3.  lets not celebrate movies such as 'War Games' where the hacker kid
        breaks the law numerous times AND gets off.
    4.  Lets engineer better operating systems!
    5.  More distribution of binary systems and less source code.
     

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 88 22:57:41 GMT
From:      zjat02@cra2.uucp (Jon A. Tankersley)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC on Internet "Virus", Please

This is interesting.  I knew about the isis list, and even got some information
on it, but never seemed to get on the list.  Guess administring 100+ UNIX 
systems isn't enough, or maybe not having source..... Not really sure, never
got the rejection notice.

But I never heard about the zardoz list.  Someone needs to publicize some of
this a little more.  Could boths lists condsider this a request?

-tank-
#include <disclaimer.h>		/* nobody knows the trouble I .... */

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 00:00:37 GMT
From:      hutch@net1.ucsd.edu (Jim Hutchison)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In <11226@cgl.ucsf.EDU> seibel@hegel.mmwb.ucsf.edu.UUCP (George Seibel) writes:
> [...] If that's
>the way people want it, then let's be up front and print a warning on
>each copy of system software that ships:  "Congratulations!  You just
>bought a fine copy of Unix.  Don't keep any files you care about on it."

You would prefer VMS where you can read the documentation to find out how
to break security?  Or how about a system with no features?

If you boadcast a bug, and its fix/patch, you take responsibility for that
patch.  You also risk letting loose all sorts of mayhem on systems where
the system manager is lazy or on vacation.  Binary sites are particularly
limited in the number of fixes they can apply.  So out go the fixes quietly,
and perhaps only locally.  Here we are.

Do you have a good answer, or are you just going to indulge yourself in
a good screaming fit?

>If we have security holes on our machines that are well known, and we
>do nothing to patch those holes, we are asking for trouble.

True.  But not real.  Many people spend a great part of their waking
hours monitoring and fixing the system, locally and for others.  Don't
be viscious and ignore their hard work.

>George Seibel
/*    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!cs!net1!hutch
		    		ARPA:	JHutchison@ucsd.edu
     These are my opinions, and now you have your perceptions of them. */

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 00:11:44 GMT
From:      leong+@ANDREW.CMU.EDU (John Leong)
To:        comp.protocols.tcp-ip
Subject:   More trap doors?

Two quickies now that the Virus has sort of blown over ...

[1]  It looks from the various postings that the SENDMAIL trap door is known by
some but not others.  It seems almost certain that there are lots of other trap
lying around and different people are aware of different subsets.  It will be
nice if someone will collect a list of potential exposures and appropriate cures
and make it accessible by "responsible" people.

[2]  Does anyone  have any means to know if other "moles", "sleepers", "worms"
and other nasties have creeped through various trap doors waitng to do
unspeakable things prior to this fiasco?  For whatever they are worth, there are
Virus snooper and buster software available for PC's and Mac's.  Are there
similar things for the Berkely UNIX world?

[I call bad guys "moles" if they bury themselves deeply into ones system and
then execute tasks on behalf and under the control on some remote entities.
"Sleepers" are bad guys that, lie dormain until waken by specific external or
internal event (i.e. requiring no further external stimulus) and have a wild
party on ones system.]

John Leong (leong+@andrew.cmu.edu)

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 01:57:10 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet VIRUS alert

# I agree with the first poster.  It is a BIG security hole.  I can understand
# the justification for piping incoming mail to a process, but this should be
# done via the 'aliases' file, not the To: line.  [...]

And so it is.  Try your example (To: "|foo") and you'll see.

The "|programname" syntax is only supposed to work from /usr/lib/aliases and
from ~/.forward.  It will definitely not work in a header address -- it just
doesn't go through the right part of the code at that point.  And it would
ordinarily not work in a RCPT TO command except that it was allowed to when
debug mode was enabled.  Berkeley's fix to sendmail turns off the DEBUG
command; the proper thing to do is to stop allowing RCPT TO:<|sed -e ...>
just because debug mode happens to be enabled.  (Which is what I did to the
version I run here.)
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 02:03:45 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: Viruses and VMS

#   We are running the Wollongong TCP/IP software (no eunice).  
# The smtp server does not have the debug mode enabled, so it is not 
# subject to attack.

Even better than that, the SMTP daemon in VAX WIN/TCP is not sendmail.

Disclaimer: WIN is no doubt a trademark of Wollongong; VAX is probably owned
by Digital; I am a spokesman for neither.  Your mileage may vary.  Void where
prohibited.  Etc.
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 10:04:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   EMail server alternative
From what I have seen, this point has not been made to the general
community, so it may be worth mentioning, by way of closing the barn
door after the worm has turned (those of you familiar with Dave Farber will
recognize his linguistic influence...) that there is another mail transport
package available as an alternative to sendmail.

MMDF (which used to stand for Multi-channel Memo Distribution Facility and
may, still) has been in operation for 9 years and is used as the core to
a number of mail networks, most notably CSNet.  While I developed the original
version, at the University of Delaware for Farber, the Army, and NSF (CSNet),
the last 6 years has seen massive improvements made by a collection of 
people, originating with Doug Kingston, then of BRL, Steve Kille, still of
UCL, and Dan Long, still of BBN.  I am told that there is a small community
of dedicated souls continuing to maintain and enhance it.

Like sendmail, MMDF allows mail to be sent to processes.  Unlike sendmail,
this can only be done to pre-registered addresses or by the recipient.

That is, the MMDF maintainer can register an alias that maps to a process or
the mail recipient can have an arbitrary process invoked on the message
contents.

There are a number of other sercurity related features, such as filtering
mail according to network pairs, host pairs, or host/net combinations.

Dave

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 02:11:25 GMT
From:      vixie@decwrl.dec.com (Paul Vixie)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Packet filtering for 4.3BSD ?

# I have a TCP/IP gateway running 4.3BSD, and I've just been told that it
# has to be able to filter packets based on UDP and TCP port numbers, and
# possibly on source and destination IP addresses.  Has anyone already modified
# 4.3BSD to do this sort of thing?  If so, I'd like to see the code...

In principle, this is not that hard to do.  Issues are:

1. speed -- every packet is going to go through the filter, it has to be an
  FSM or some other very efficient mechanism;

2. managability -- the language you speak to the filter in (telling it what's
  allowed and what's not) has to be readable.  Something built along the lines
  of sendmail.cf would be easiest to implement but would be (another) crime
  against reality.

3. minimal change -- the hook in the kernel has to be very narrow, since you
  will want to be able to pop the filter into future versions of TCP (CSRG
  promises many changes in the next release of their code, and streams-based
  TCP implementations are going to get more popular).  Portability is also
  a concern, for the same reasons.

Like I said, in principle it's not that hard.  But if anyone actually
implements something and/or publishes a paper on it, I'd sure like to
hear about it.  SMOP and all that.
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 02:14:10 GMT
From:      gww@SUN.COM (Gary Winiger)
To:        comp.protocols.tcp-ip
Subject:   Re: password aging (from worm discussion)

In article <8811070715.AA05179@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
>
>At any rate, we intend to implement shadow password files here (at U of
>MD CSD) if Berkeley does not get to it first.  The way the worm breaks
>Unix passwords is by efficiently implementing the Unix `salted' DES
>encryption (possibly the worm's author simply used Bob Baldwin's code),
>
>We already enforce `hard to guess' passwords---dictionary checking is
>in 4.3BSD-tahoe, and we had been using similar checking earlier---and,

Chris,
	Some time in Jan, I posted a set of mods to 4.3 that I did while at
ELXSI (with their permission) to implement shadow password files, password
aging, and stronger password criteria.  The were posted to alt.sources
with a note in comp.bugs.4bsd.  I also sent a copy to Keith Bostic.  You
may  wish to look at that.  If it doesn't meet you needs, it might serve
as a starting point and illustrate a possible approach.  If you'd  like to
get a copy, drop me a note and I'll return the shars by mail.

Gary..
gww@Sun.COM

P.S. I'll be traveling  from 14 - 20 Nov. so replies won't happen until 21 Nov.

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 02:43:49 GMT
From:      kovar@husc4.HARVARD.EDU
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert Morris

In article <10791@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes:
>It is very easy in the aftermath of something like this to indulge in
>the devil theory of crime -- that all bad things must come from evil
>minds.  The more you find out about rtm I believe the more you will find
>he has in common with the people criticizing his behavior.  He has done
>significant work in computer security, including warning people for
>years about the security holes that made the worm possible.  He has
>worked as a sysadmin for an arpanet host.  He is a serious student of
>computer science and was making contributions to the field at an age
>when most of us were trying to learn Pascal.  He's also one hell of a
>great guy, and no one seems more appalled by the effects of his actions
>than he is.
 
>We can argue about the advisability of what he did, but I urge you to
>resist the temptation to pigeon-hole someone you don't know on the basis
>of fragmentary information.
 
>Jim Matthews

  I may be a really nice guy but if I, by accident, kill someone by driving
recklessly, the state of MA is going to toss me in jail for manslaughter.
And I'd expect as much. Nice people are just as responsible for their
actions as "evil" people. If we fail to prosecute someone just because
they appear to be nice, brilliant, et al, then what's to stop many others
from doing similar things and claiming "I'm just as nice as RTM! Let me
go."

  With the press holding RTM up on high many a hacker is going to say,
"This is how I get recognition! This is how I get a job!" And, surprise!,
it'll work. Set an example and set it before things get out of hand.
If at all possible, punish RTM to the fullest extent of the law. It may
be more than he deserves but unfortunately (?) someone must set the
example and show that such anti-social activities are not acceptable.
 
  Perhaps a suitable punishment, at least in this case, is just denying
RTM access to any systems that connect to any other systems. You pollute
our nest and we're going to toss you out of it.

-David Kovar
 Technical Consultant
 Harvard University

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 11:12:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   NetBios, TCP, SMB, History
The use of NetBios over TCP has been a very interesting merging of work
in the research and hard-core commercial worlds.  Some of the benefits of
the merging were cited in the notes sent late last month and early this
month, but there are a few points that should be clarified:

1.  Netbios mostly uses TCP, not UDP.  UDP is used for NetBios datagrams
and various "management" tasks, such as name registration and lookup.  This
applies to all of the vendor implementations that were in existance two
years ago.

2.  Netbios does not allow file sharing.  Let me repeat this:  Netbios is only
a facility for the sending of uninterpreted bits.  It carries NO semantics,
such as file structure.  This function is performed through a protocol that
runs on top of Netbios, called Server Message Block (SMB).  As I understand
the history, Sytek did the original NetBios, for IBM and Microsoft did the
original SMB, also for IBM.

3.  Ascribing to vendors the intent of using Netbios over nationwide
networks, as the reason for puting Netbios over TCP, sounds great but does not
appear to apply to any of the original vendor implementations.  Most, in fact,
did not allow any access to a non-broadcast network.  Of those that did, only
one did it in a "natural" fashion.  The standard approach was to hard-code
some NetBios names as mapping to a specific IP address, which thereby might
be on another network.  Only one used an internet name server, with fully
dynamic registration and lookup.  (I.e., the only hard-wired information was
the IP address of the server.)  Getting this sort of feature into the
standard that finally emerged was a very, very hard-fought battle.  The
original intent of the standards group was to limit the functionality to
broadcast nets (read:  a single LAN) only.

4.  So what was the reason?  Simple.  For the PC market, Netbios was the
ONLY network service/"protocol" standard.  It vastly outweighed whatever was
in second place.  So, if a vendor wanted to hit the PC-to-PC networking
market, they implemented NetBios.  Why do this over TCP?  Because that was
the protocol of choice for most of the vendors.  IBM published to functional
specifications for the service, but not the underlying protocols.  Hence,
vendors were free to choose their own.  Most networking vendors in that
market had experience with XNS and/or TCP and chose one or both and the
underlying framework, onto which they added their own NetBios protocol.
The only requirement was that all PC applications had to see the same
Int 5C NetBios service.  (Simply put, if it worked on the original Sytek
implementation, it was supposed to work on the vendor's implementation.  The
application, of course, does not see that actual protocol.)

Dave Crocker

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 04:14:30 GMT
From:      cherry@husc4.HARVARD.EDU (Michael Cherry)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert Morris

In article <565@husc6.harvard.edu> kovar@husc4.UUCP (David Kovar) writes:
>In article <10791@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes:
>>We can argue about the advisability of what he did, but I urge you to
>>resist the temptation to pigeon-hole someone you don't know on the basis
>>of fragmentary information.
>
>If at all possible, punish RTM to the fullest extent of the law. It may
>be more than he deserves but unfortunately (?) someone must set the
>example and show that such anti-social activities are not acceptable.

It is difficult to agree however it is analogous to a brilliant University
Molecular Biologist experimenting on a biological virus but through
inadequate precautions results in a large number of dogs in North America
becoming infected. The released virus could be completely harmless - but
I don't think this country would want or should allow this act to go
completely unpunished.

Mike Cherry
Systems Analyst
cherry@mgh-coffee.harvard.edu
J. Michael Cherry    Systems Analyst/Manager   Department of Molecular Biology
cherry@mgh-coffee.harvard.edu                  Wellman 9, Mass General Hospital 
cherry%mgh-coffee@husc6.bitnet                 Boston, MA 02114   (617) 726-5955

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 04:18:15 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

> According to press reports, RM spent his summers working at AT&T
> on "Unix Communications Software Security". Anyone with a source
> license check to see if he slipped a trojan horse into uucico
> or uuxqt or something?

Morris wrote an entirely new version of uucp, one that a higher degree
of inherent security than any of its predecessors.  It was in fact
installed as the production uucp on a number of research machines for
several years.  Ultimately, it was supplanted by Honey DanBer uucp
because it wasn't hardened enough against real-world failures.  At
Morris's request, I went over the code in great detail; there were
no holes visible -- and I repeat, I studied his code thoroughly.
In any event, to the best of my knowledge that version of uucp was
never released.


		--Steve Bellovin

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 04:53:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   passwords

Concerning pseudo-random, semi-pronounceable password generation,
please see RFC 972.  The original algorithm was written in BASIC by
Paul D. Merillar and Arthur A. Key.  The implementation in our PWDGEN
server, a variation of our local CHGPWD program, came from Sandia
Labs, written in FORTRAN, and uses a system-wide 36-bit seed rather
than a clock-based seed.  Marshall Rose converted that program to C...
From your message, it seems that the algorithm has found its way
around, and that's good to see.

From the source code:

    Basically "random pronounceable words" are built by alternating
    Vowels and Consonants.  However, there are "Digraphs", and these
    are presorted according to END, MIDDLE, and START positions.  Not
    going into combinatorial analysis, with seven characters the
    "possible" combinations exceed 20 Million.  (I haven't computed
    how many are possible with eight characters...)

--Frank

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 05:39:02 GMT
From:      lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Worms and fixing blame

> In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes:
>> "Wormer" Morris has quite a career ahead of him, i'll bet.
>> he has done us all a favor by benevolently bashing bsd 'security'.
 
> Date: 7 Nov 88 20:06:23 GMT
> From: ember!dre@sun.com  (David Emberson)
> Subject: Re: a holiday gift from Robert "wormer" Morris
> 
> I knew about this sendmail bug at least four years ago, courtesy of Matt
> Bishop (now at Dartmouth).  He wrote a paper detailing at least a half dozen
> holes in the Unix system and methods for constructing trojan horses which was
> so dangerous that he responsibly decided not to publish it, but instead to
> give selected copies to people who could fix some of the problems.
> ...  His behaviour, while unsung by the press and the Usenet community,
> is an example of the highest in professional and academic standards. 
> This is the kind of behaviour that we should be extolling.

I work as a customer service manager at a TCP-IP networking company.
My wife is a corporate MIS person. She asked me about technical aspects of
the worm, and expressed a wish to see severe criminal charges pressed against
the perpetrator. IU asked her on what grounds since there apparently was no
provable malicious intent and no "real damage". rather, I suggested, SUN
Microsystems might be liable for releasing operating systems software with
undocumenated functionality creating a security hole, and companies and/or
government institutions that had chosen to run poorly documented software
available "for free" from a research facility should accept responsibility
for whatever befalls them if they do not review the software that they make
themselves dependent on.

I suggested as a parallel, that no company would be likely to install without
test and review a payroll package found floating around on a computer bulletin
board, and if they did, and the IRS sued they for improper calculation of
withholdings, they would have only themselves to blame. I think she agreed.

The DEBUG code apparently was intended for use internally in the sendmail
development group, and should have been turned off at product release.
It is sortof understandable that a university would not have a clear idea
about quality control, and not have an independent review before release.
It is much less acceptable that the same seems to have been the case
at SUN. As far as I can ascertain, the ULTRIX engineering group was aware of
the problem, and the Ultrix systems, on which I have looked, all seem to
contain a sendmail compiled without DEBUG.

If the claim mentioned above (that UCB's CSRG (sp?) was explicitly made
aware of this problem several years ago) is true, it seems to me that a
claim could be made that UCB was negligent in not instituting procedures
to address this problem. David Emberson lauds Mr Bishop for being a
responsible person who brought the problem to the attention of the people
who were in a position to correct it, rather than creating a media event;
but look how effective that was ????

As a minumum, everybody who buys system software should add the following
clause to their purchase orders: "The system shall identify each user by
a unique user identification, and password validation shall be used to
ensure that no unauthorized access occurs". This will ensure that you can
hold the vendor liable for losses you might incur in a situation like this.

UCB, of course would likely refuse to accept this responsibility, thus
making the problem with non-commercial software explicit.

/ Lars Poulsen
  Advanced Computer Communications
 (Employer name for identification only; my employer knows I have opinions
  but disclaims responsibility)

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 12:08:10 GMT
From:      hartvig@freja.dk (Hartvig Ekner)
To:        comp.protocols.tcp-ip
Subject:   RFC1001 & RFC1002 wanted

Hello, 

Does anybody have a machine readable version of RFC1001 and RFC1002 that
they would be willing to send me? I know that I can get them from DDN
Network Information Center, but it is very expensive if you live in
Europe. BTW, I sav somebody mention NetBios on top of ISO TP4 or datagram
service, does anybody know if there is some standard way to do this?

Thanks in advance,

Hartvig Ekner      ...mcvax!diku!hartvig 

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 13:20:58 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .

By the way a very good article on the computer whiz which opens with
the correct definition of the word hacker appeared around page A20 of
Nov 7, 1988 New York Times.  I've circulated this around various administrative
types here at Rutgers.

_Ron

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 13:29:10 GMT
From:      elbereth.rutgers.edu!ron.rutgers.edu!ron@rutgers.edu  (Ron Natalie)
To:        tcp-ip@sri-nic.arpa
Subject:   On UNIX secuurity
There were and still are a large number of UNIX security bugs that
are passed around under the table to knowledgable UNIX system administrators.
Unfortunately, that whole idea is entirely passe.  No longer is UNIX run
by a group of guys that sit up at night talking to each other at USENIX's.
It's big business.  The major reason that the bugs were not publicized more
widely was it was felt that people didn't want to make this obscure information
more available since most people wouldn't be able to fix them without source.
Many of the vendors (I'm not talking about Sun specifically here) don't care
to track carefully what even the concientious research people are trying to
do.  Blatent bugs still exist in the recent release of one O/S even after they
FIXED it to stomp on the morris-worm.  Knowledgable system administrators
ought to know enough to beat on the vendors, but even at Rutgers there aren't
that many knowledeable system adminstrators.  UNIX workstations exist in non
technical and non-academic departments, even in technical departments they
are owned and operated by people who are lucky if they know how to change
the root password on their own machines (for example I had to point out
a glaring problem to a workstation owned by a dean here).

At least now with the nationwide publicity this has caused, we've got
many of these guys asking the cental support facility what they need to
do about security, so I guess it may be a good thing.

-Ron
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 13:33:47 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Crackers and Worms

...and I have worked on IBM's B2 product, but I fail to see what that
has to do with the discussion.  A bug in either product can cause it
to fail to do what it is supposed to do.  In the development group the
Trusted System Programmer frequently has backdoor functions to bypass
the Mandatory Access Control on the test system that one hopes are never
installed in the field (this is much akin to the exploited DEBUG bug
in the BSD systems).  And any secure workstation that's plugged into
a network is very suspect.  I believe NCSC won't even talk to you if
you put an ethernet card in the workstation.

-Ron

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 13:46:36 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

I don't know why you say that.  Many of the infected sites had source
for sendmail.  As a matter of fact, we had done some local modifications
to it and were mildly familiar with the code and we were still hit.
We were still hit after I had ripped out all the ifdef DEBUG code out
of an earlier release of sendmail due to an even more BLATENT security
bug that the one recently divulged.  We got a new release with the earlier
bug fixed and people figured that we didn't need to go to the effort of
ripping all that stuff out again.

-Ron

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 13:48:53 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Morris bashers...

Guys - at this time nothing has been proven about who started this
virus.  From a libel standpoint the words "alleged" or "as stated in
the ABC press" are highly recommended.

Mike

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 14:04:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Paranoia**2 (UNIX source?)

>       This is serious.  The knowledge that this person had the opportunity to
> tamper with the master source code for UNIX is very worrisome.  A major
> examination of all AT&T-provided security related code is in order.
>
>       We may not be at the end of this yet.

How many "worms" or other "users" of the sendmail bug were there
before this one? (The final? one).

As it sounds like the worm ran as root on many systems, didn't
EVERYONE have a chance at the master source code for UNIX?  How
well protected were the sites which hold "distribution" sources
like AT&T or Berkeley?

What's going to be in the next versions shipped?

Also how do you know that RTM really wrote the worm?

I'm not really disagreeing, it just seems that noone has pointed
out that ANYONE could have planted ANYTHING on any "open" system
before the incident.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 14:17:55 GMT
From:      aplcen!aplcomm!stdc.jhuapl.edu!jwm@mimsy.umd.edu  (Jim Meritt)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <829@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes:
}I'll bet the KGB are laughing their asses off.
Bet they're not:  They see what a kid without malacious intention can do,
and then they look at their rather pitiful computer systems, look at our
trained personnel WITH malicious intent, and probably shudder....


Disclaimer:  "It's mine!  All mine!!!"   
					- D. Duck
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 15:38:40 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   UNIX bashing (Re: a holiday gift from Robert "wormer" Morris)

In article <11226@cgl.ucsf.EDU>, seibel@cgl.ucsf.edu (George Seibel) writes:
> In article <76424@sun.uucp> dre%ember@Sun.COM (David Emberson) writes:
> >[Matt Bishop (now at Dartmouth)] wrote a paper detailing at least a half
> >dozen holes in the Unix system...

UNIX in general or things like sendmail that are specific to BSD?

> "Congratulations!  You just
> bought a fine copy of Unix.  Don't keep any files you care about on it."
[ because we're not going to fix any security holes ]

You see, this is the sort of response we're going to get from this sort
of confusion. UNIX is not just BSD. The latest release of System V has
many security improvements... some of which were apparently made at the
urging of Robert Morris himself.

Another consideration.

Most of the individuals who buy computers run MS-DOS, a file manager and
program loader that doesn't begin to try to keep viruses out. It can't,
for obvious reasons. For all its faults, UNIX is a lot more secure than
the alternatives available to the general public.

The typical virus in an unprotected DOS or OS is at most a few K of
code... many only a few hundred bytes. This worm required a leader that
was nearly a hundred lines of 'C' code by itself.

Let's keep a sense of proportion.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation
"Have you hugged  U  your wolf today?"     uunet.uu.net!ficc!peter
Disclaimer: My typos are my own damn business.   peter@ficc.uu.net

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 15:42:48 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

In article <2120@kalliope.rice.edu>, hd@kappa.rice.edu (Hubert D.) writes:
> We've been looking at software to connect our PCs and MACs
> to SUNs and VAXn.  Now, with the possibity of holes and 
> backdoors left in place by software vendors,  I don't see
> how one can trust object code for communications software
> anymore.  I'm going to take a hard think on wheather to
> go commercial or install/modify/develop public domain
> packages such as KA9Q, NCSA or PCIP (MIT & CMU).

	Huh?  If you let anyone on your Ethernet cable with a PC you've
	basically just given up any hope for security.  Even active
	methods like Kerberos will not protect you from people who
	just listen to eg TCP sessions on the cable.  

> Hubert Daugherty
> hd@rice.edu

				Rick Spanbauer
				SUNY/Stony Brook

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 16:21:19 GMT
From:      adm!nlm-mcs!vax2.nlm.nih.gov!mjr@nyu.edu  (Marcus J. Ranum)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <44440@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:

>The fact that you can run an arbitrary program is such an obvious
>security hole that I can't believe anyone wouldn't report it if they knew.

I think that part of the problem is that the kind of people (like I
used to be) who actively ferret out such information collect it in
their bag of tricks and DON'T share it. A good recent example is all
the frustrated posters with the "well, what the #@!!@#!@ is the stupid 
bug with the #!/bin/sh" and the countless deliberately vague answers.

It also doesn't help that there isn't a unified stance on the net as to
whether it is evil to post a security hole to force vendors, etc, to fix
things, or whether it is better to waste countless hours calling tech
support hotlines and being told "it'll be fixed in the next release".
Both going through "proper channels" and "screaming fire" are less than
optimal, but I think this attack indicates that the current approach
doesn't work too well either.

One approach would be for an organization to step forward and offer to
be a clearinghouse for security-related information, distributing it to
a list of KNOWN responsible individuals. (which is roughly what HAS
happened, this time). I don't know how such a set-up could be arranged,
and there is still the problem of getting the people with the secrets
to share them.

I had HEARD of a sendmail bug, and knew it had something to do with
DEBUG mode - but I didn't know the details, since my sources would all
start giggling and getting shy when I asked. We need some SAFE way to
clear such information so that fixes can be issued. I used to think
that it was "job security" and all a part of trying to be a "guru", but
working as a system administrator and legitimately "having root" took
all the fun out of it. In fact, the worst punishment I could imagine
for someone like the wormer would be to make them professionally
responsible for a large campus network :-)


--mjr();
"Strange women lying in ponds, distributing swords is no basis for a system
of government. Supreme executive power derives from a mandate from the masses,
not from some farsical aquatic ceremony."
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 16:29:04 GMT
From:      cadeta!galbp!wittsend.LBP.HARRIS.COM!mhw@gatech.edu  (Michael H. Warfield)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <832@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes:
>I see my points were misunderstood.

>1) It could have been worse
>2) This was an attack made possible by glaring BUGS in system security
>3) BUGS should be fixed when discovered
>4) I do not in any way condone or support the irresponsible or destructive
>	acts of others

     Yeah but:

     5) When faced with the results of his little experiment, he tucked tail
and ran like hell.

     How much time and effort would he have save all of us if he had
announce what he had done, admitted his mistake, and provided any and all
assistance he could to stopping it.  His gravest irresponsibility was in
running for cover and letting everyone else suffer from his stupidity!
The damage done was in lost time and productivity (to say nothing of the
network traffic and expense this sucker has generated, JJ@PORTAL would be
proud!).  We may never know the final ramifications of his mistake.  If he
had come forward immediatedly he may have got flamed but I doubt he'd be
under criminal investigation.  If and ONLY IF he had assisted in cleaning
up the mess he made would he deserve any thanks.  And yes this sure could
have been one hell of a lot worse so let's not encourage the next guy by
making this one out to be any more than he is.  Any thanks he may have
deserved by limiting his experiment's destructive power was forfeited when
ducked and ran for cover.

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 16:36:42 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  Morris bashers...

Lets settle the ftpd issue once and for all.

Here are the headers from Bostics message announcing a fix for the
ftpd bug:

From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
Subject: V1.65 (security problem in ftpd.)
Message-ID: <8810312317.AA14287@okeeffe.Berkeley.EDU>
Date: 31 Oct 88 23:17:05 GMT

Note that this was days BEFORE the first sign of the worm.

Therefore, clearly the worm had nothing to do with getting ftpd fixed.

--rick

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 17:10:31 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Harvard HSDN


To repeat:

Harvard University is publishing a RFI for a High Speed Data Network
(>=100MB/sec) that will connect together many of Harvard's 300+ buildings.

The RFI addresses the physical design of the backbone network and the
building links, the electrical design, a management structure and center,
interfaces with Harvard's new ISDN phone system, and supporting software.

Vendor's wishing to get a copy of the RFI should send me their postal
address and phone #. Harvard will NOT accept any response from vendors
that did not receive a hard copy from us ( We will be accepting written
questions from the vendors and will be sending the questions and our
responces to all vendors that have told us that they will be responding.
The requirement for a hard copy is to insure that we have accurate
addresses for the vendors and to insure that all vendors get exactly
the same information. )

The hard copy has been given to the USPO for all of those who have
already sent me their addresses, if you have done so and do not find
a copy in the mail box in the next few days, please get in touch with me.

For those of you are interested, a copy of the postscript files required
to print out a copy of the RFI are now available for anonymous ftp from
husc6.harvard.edu in pub/hsdn.rfi. ( There is a also a formatted ASCII
version for those who do not have access to a postscript printer. )


Scott Bradner
Harvard University			sob@harvard.harvard.edu
33 Kirkland St.			or	...!{harvard,wjh12,talcott}!sob
Cambridge, MA 02138			SOB@HARVUNXW.BITNET

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 17:20:09 GMT
From:      sms@ETN-WLV.EATON.COM (Steven M. Schultz)
To:        comp.protocols.tcp-ip
Subject:   Re: And You Thought You Were Paranoid...

> From: nic.MR.NET!tank!nucsrl!naim@ub.d.umn.edu  (Naim Abdullah)
> Organization: Northwestern U, Evanston IL, USA
> Subject: And You Thought You Were Paranoid...
> Message-Id: <7080011@eecs.nwu.edu>
 
Naim Abdullah writes...

> In PRINCIPLE "ls -l" is not enough. The worm had root priveleges,
> it could have 
> installed a modified /bin/ls so that if one of the files being listed
> was fsck, vmunix, ls, telnetd etc (the tampered binaries) /bin/ls
> would always show predetermined sizes. In that situation, "ls -l" wouldn't
> be enough.
> 

	This is not quite correct, 'sendmail' had changed uid to "daemon"
	(1 on the system here) NOT "root" when executing the worm. 
	The worm had NO super user privileges - that would be a serious 
	flaw to have 'sendmail' running as "root" at that stage in the
	delivery process. If the system directories and binaries aren't 
	writeable by a 'daemon' uid process there shouldn't be a lot 
	that could be damaged.

 		      Steven Schultz
 		      CONTEL Federal Systems IMSD
 		      31717 La Tienda Westlake Village CA 91359-5027
 
 		      Internet: sms@etn-wlv.eaton.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 17:42:08 GMT
From:      emory!arnold@gatech.edu  (Arnold D. Robbins {EUCC})
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <44440@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:
>I have not been able to find ONE person who claims to
>have known that sendmail compiled with DEBUG on would have allowed
>anyone with SMTP access to run an arbitrary program on their machine.

Didn't Paul Vixie say he knew it? If not, I apologize in advance.

>The fact that you can run an arbitrary program is such an obvious
>security hole that I can't believe anyone wouldn't report it if they knew.

The bug is actually in the sendmail.cf file; we are running a sendmail.cf
file written from scratch, and our vax systems, even though they had
debug compiled in, did not accept the To: address used to run commands.
So, we did not get hit, although we're just one hop up SURAnet from GaTech.
-- 
Arnold Robbins -- Emory University Computing Center
DOMAIN:	arnold@unix.cc.emory.edu (finally!)
UUCP:	{ decvax, gatech, skeeve }!emory!arnold		BITNET:	arnold@emoryu1
PHONE:	+1 404 727-7636
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 18:04:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   EMail server alternative

From what I have seen, this point has not been made to the general
community, so it may be worth mentioning, by way of closing the barn
door after the worm has turned (those of you familiar with Dave Farber will
recognize his linguistic influence...) that there is another mail transport
package available as an alternative to sendmail.

MMDF (which used to stand for Multi-channel Memo Distribution Facility and
may, still) has been in operation for 9 years and is used as the core to
a number of mail networks, most notably CSNet.  While I developed the original
version, at the University of Delaware for Farber, the Army, and NSF (CSNet),
the last 6 years has seen massive improvements made by a collection of 
people, originating with Doug Kingston, then of BRL, Steve Kille, still of
UCL, and Dan Long, still of BBN.  I am told that there is a small community
of dedicated souls continuing to maintain and enhance it.

Like sendmail, MMDF allows mail to be sent to processes.  Unlike sendmail,
this can only be done to pre-registered addresses or by the recipient.

That is, the MMDF maintainer can register an alias that maps to a process or
the mail recipient can have an arbitrary process invoked on the message
contents.

There are a number of other sercurity related features, such as filtering
mail according to network pairs, host pairs, or host/net combinations.

Dave

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 18:04:30 GMT
From:      andrew@alice.UUCP (Andrew Hume)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <17823@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes:
> >According to press reports, RM spent his summers working at AT&T
> >on "Unix Communications Software Security". Anyone with a source
> >license check to see if he slipped a trojan horse into uucico
> >or uuxqt or something?
> 
>       This is serious.  The knowledge that this person had the opportunity to
> tamper with the master source code for UNIX is very worrisome.  A major 
> examination of all AT&T-provided security related code is in order.
> 
>       We may not be at the end of this yet.
> 
> 
> 					John Nagle

come on. this is so prepostrous that i feel obliged to respond.
morris has never worked on System V code which is probably what you mean
by the master source. he has worked on Research Unix but given Ken Thompson
used his Turing Award lecture to advertise a trojan horse he put into
research unix; you would have to be very naive to trust research unix.
(although there are currently no known trojan horses or viruses.)

more importantly, morris has been doing this in an open way; penetrating systems
from the outside, not via trojan horses. in a peculiar (but obvious to me) way,
he is doing the honourable thing; attacking systems via their own foibles,
and not ones he has added. and we have heard peter honeyman acknowledge
morris's contribution towards the current uucp.

so think a little before raising panics and denigrating people's character.

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 18:45:28 GMT
From:      pst@comdesign.cdi.com (Paul Traina)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Morris, the law, and hist state of mind -- get real.

Look, this is getting out of hand.  Maybe I feel the way I do because my
network was not infected.

In a >criminal< case,  state-of-mind is a very important factor when
assessing guilt.  We've heard from some reliable folk who say:
	Morris didn't realize the dammage potential from the worm
		(cpu megabog)

	Morris tried to stop it by himself, but he got bitten by it
		(his net was too clogged to get out)

	Morris then called other people and told them to get the word out.

He was shocked.  He knew his ass was in the can.  He was scared of having
a lynch mob outside his door,  so he "hid out."  I'm not saying he did the
right thing.  I'm not going to comment about the benignness of the worm,
and I can't speak for the people who spent 48 sleepless hours trying to
figure out what it was doing.

However, to the people like me,  who don't have a "big" reason to hate
Morris,  I say "Lay off the guy."  We all make mistakes.

			He did not do it on purpose.
			He *was* negligent.
			He *should* have done more to spread the word.
			He was *scared* of the reaction.
			He is intelligent, and has made *valuable*
				contributions to the net.


------
Paul Traina				To believe that what is true for
{uunet|pyramid}!comdesign!pst		you in your private heart is true
pst@cdi.com				for all men, that is genius.

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 19:12:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   NetBios, TCP, SMB, History

The use of NetBios over TCP has been a very interesting merging of work
in the research and hard-core commercial worlds.  Some of the benefits of
the merging were cited in the notes sent late last month and early this
month, but there are a few points that should be clarified:

1.  Netbios mostly uses TCP, not UDP.  UDP is used for NetBios datagrams
and various "management" tasks, such as name registration and lookup.  This
applies to all of the vendor implementations that were in existance two
years ago.

2.  Netbios does not allow file sharing.  Let me repeat this:  Netbios is only
a facility for the sending of uninterpreted bits.  It carries NO semantics,
such as file structure.  This function is performed through a protocol that
runs on top of Netbios, called Server Message Block (SMB).  As I understand
the history, Sytek did the original NetBios, for IBM and Microsoft did the
original SMB, also for IBM.

3.  Ascribing to vendors the intent of using Netbios over nationwide
networks, as the reason for puting Netbios over TCP, sounds great but does not
appear to apply to any of the original vendor implementations.  Most, in fact,
did not allow any access to a non-broadcast network.  Of those that did, only
one did it in a "natural" fashion.  The standard approach was to hard-code
some NetBios names as mapping to a specific IP address, which thereby might
be on another network.  Only one used an internet name server, with fully
dynamic registration and lookup.  (I.e., the only hard-wired information was
the IP address of the server.)  Getting this sort of feature into the
standard that finally emerged was a very, very hard-fought battle.  The
original intent of the standards group was to limit the functionality to
broadcast nets (read:  a single LAN) only.

4.  So what was the reason?  Simple.  For the PC market, Netbios was the
ONLY network service/"protocol" standard.  It vastly outweighed whatever was
in second place.  So, if a vendor wanted to hit the PC-to-PC networking
market, they implemented NetBios.  Why do this over TCP?  Because that was
the protocol of choice for most of the vendors.  IBM published to functional
specifications for the service, but not the underlying protocols.  Hence,
vendors were free to choose their own.  Most networking vendors in that
market had experience with XNS and/or TCP and chose one or both and the
underlying framework, onto which they added their own NetBios protocol.
The only requirement was that all PC applications had to see the same
Int 5C NetBios service.  (Simply put, if it worked on the original Sytek
implementation, it was supposed to work on the vendor's implementation.  The
application, of course, does not see that actual protocol.)

Dave Crocker

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 20:53:52 GMT
From:      bart@videovax.Tek.COM (Bart Massey)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Packet filtering for 4.3BSD ?

In article <45@gnome6.pa.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
> # I have a TCP/IP gateway running 4.3BSD, and I've just been told that it
> # has to be able to filter packets based on UDP and TCP port numbers, and
> # possibly on source and destination IP addresses.  Has anyone already modified
> # 4.3BSD to do this sort of thing?  If so, I'd like to see the code...
> 
> In principle, this is not that hard to do.  Issues are:
> 1. speed
> 2. managability
> 3. minimal change 
> Like I said, in principle it's not that hard.  But if anyone actually
> implements something and/or publishes a paper on it, I'd sure like to
> hear about it.  SMOP and all that.

One of the lesser known pieces of useful code I discovered recently is the
BSD "packet filter" code which has been around since at least 4.2D, and is
currently in /usr/src/new/enet in the 4.3 distribution.  With fairly minimal
changes (mainly to the ethernet driver for your machine) you should be able
to get it to do everything you want and satisfy 1-3 above...  Its chief use
currently is for filtering off and generating V packets for UNIX V servers,
but it's really much more general-purpose than that...

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					UUCP: ..tektronix!videovax!bart
					DOMAIN: bart@videovax.tek.com

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 22:02:45 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  VIRUS discussion quenched? (was Re: Virus)

> Read a disturbing report in the Sunday paper (Pittsburgh Press, pA16),
> attributed to 'Press news services; LA Times, ....
> ..., was a 'gag order' really issued?  By whom?
> To what parties?

Funny that this came out on Sunday.  Last Friday morning 4 November,
Mike Muuss at BRL was called (at home!) by the LA Times.  I had also
been given local approval to talk to the Baltimore Sun when we learned
that "all inquiries by the press to DoD employees were to be directed
to the Media Desk, DoD."  So, that's what we stated doing.  You can't
blame them for being concerned about what was said early on.  I have not
checked to see if this directive is still in effect, but we did turn down
another LA Times reporter this Tuesday.

This past weekend, we finished pulling all of the routines that Berkeley
and MIT had not yet done (at least last we saw) back to source code.  We
can now second remarks made on this list with complete confidence, that:

1) The *only* methods of penetration used the the worm were the sendmail
   debug option, and the fingerd deamon.  It would try to exploit rsh, but
   not by using any hiddend bugs, just by trying for "open" systems.  If it
   succeeded in breaking any local passwords it would then try "rexec" to
   login with that user and password.

2) It did no writes whatsoever except to its own temp files, so you need
   not be concerned about it corrupting anything on your machine.

3) All requests for source code will be ignored.

It was to the InterNets credit how rapidly everone figured out and stopped
this worm.  The work by Berkeley and MIT is particularly noteworthy.
Since I have not asked the individuals I wont mention any names, but I
would like to thank the people that we worked around the clock with at:
Berkeley, Naval Academy, Harvard, Seismo, Argone, Pentagon, and the MILNET
Monitoring Center.

- Phil

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 22:21:23 GMT
From:      rvireday@pldote1.intel.com (~Richard Vireday)
To:        comp.sys.apollo,comp.protocols.tcp-ip
Subject:   PC-NFS daemon for Apollo(?)

We are looking for a PC-NFS daemon that can run on the Apollo.
Apollo has told us that such a beasty is not supported by them,
so we are on our own.  

Does anyone have any pointers to such a program?  Please
mail directly or call.  Thank you.

Richard Vireday          
Intel    FM1-87                 PhoneNet: (916) 351-6105
1900 Prairie City Rd.         rvireday@pldote1.intel.com
Folsom, CA 95630

...!{decwrl|hplabs!oliveb|amd}!intelca!mipos3!td2cad!pldote1!rvireday
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Folsom - adj. - 1) of or pertaining to a prehistoric people. 2) Johnny
Cash sang there.

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 22:34:59 GMT
From:      dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: And You Thought You Were Paranoid...

In   article   <7080011@eecs.nwu.edu>   naim@eecs.nwu.edu   (Naim
Abdullah) writes:
    One of our staff members here, was suspicious that the recent
    worm may have planted trojan horses for crucial binaries like
    vmunix, fsck etc.  He used "ls -l" to compare  the  sizes  on
    our  infected  machine with that of an uninfected machine and
    satisfied himself that things were  ok  (actually  he  got  a
    nasty  shock  when "ls -l" showed up different sizes but then
    he remembered he had recompiled stuff to toss out yp and  use
    the BIND stuff and that is why the sizes were different).

    I thought about this and then later remembered Ken Thompson's
    Turing award lecture.  Here is a worst case scenario which we
    were spared fortunately.

    In PRINCIPLE "ls  -l"  is  not  enough.  The  worm  had  root
    privileges,  it  could  have  installed a modified /bin/ls so
    that if one of the files being listed was fsck,  vmunix,  ls,
    telnetd etc (the tampered binaries) /bin/ls would always show
    predetermined sizes.  In that situation, "ls -l" wouldn't  be
    enough.

    [ He goes on to explain the infinite recursion  assuming  the
      cracker is smart and you realize it.  And ... gets modified
      so some other program won't fink, recurisively. ]

Yes, after Ken told me about the C  compiler  and  then  the  NSA
tiger  team broke su and had a setuid root shell squirreled away,
I thought a lot about that.

1).  You need a read-only  copy  of  the  original  distribution.
[Begging the question of can you trust the vendor. ]

2).  Or, in advance build a disk with  trusted  utilities  and  a
unix to use.

3).  Have a package audit program [such as the one I have written
at ATT] that verifies checksums.  Compute check sums in a special
way.  We have a psum that check sums only the text and data  part
of a a.out (no headers or symbols).

4).  Use a better check sum program.  I have an unspoofable check
summer.  It  encrypts  the  file  with  cypher block chaining and
keeps the last [enciphered block] 64 bit result as the check sum.
In normal use it has a built in encryption key.  But one can also
provide a private key.  Hence the set  of  possible  checksum  is
unknowable  in  advance  [  one  could compute check sums for all
possible keys I suppose, but  life  is  short].  Thus  one  can't
diddle a file and fix it to have the correct size and the correct
public checksum and the correct private checksum.

-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm@arpa.att.com

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 88 22:59:21 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@sri-nic.arpa
Subject:   Trailer implementation techniques
I am considering modifying an Ethernet implementation (specifically,
the Symbolics implementation) to support reception of trailer packets.
RFC-893 makes it sound like it should be pretty easy ("about a dozen
lines of [additional] code"), but I don't see it that way.  In fact,
unless I am missing something basic, I'm not sure how to do it
efficiently in any architecture.  Could someone who has implemented
trailers clear up my confusion?

Here's the basis of my confusion.  Suppose a packet has HL bytes of
original headers and DL bytes of data.  The Ethernet driver must get
those HL bytes in front of the data.  The RFC suggests the possibility
of simply remapping pages (not feasible in the Symbolics
implementation, since the driver is in virtual mode).  How would that
help?  If the driver were to simply remap the header page to be ahead
of the data pages there would be a large gap of PL-HL-4 bytes (where
PL is the architecture's page length) between the end of the header
and the beginning of the data.  Is the optimal mechanism to map a new
page ahead of the data page, copy the original header to the END of
the new page, and then unmap the original trailer page?  The RFC
mentions the possibility of zero data copying, which this doesn't
quite achieve, although it's probably close enough (it's better than
not having trailers for any packet whose data is larger than its
headers).

If remapping pages isn't an option, as in my case, how do you get
reasonable performance?  The RFC indicates that this should be
possible, indicating that only the original header needs to be copied.
However, it seems to me that you would need to shift the data over in
order to make room to copy the original header to the beginning.

Another possibility would be for the interface between the layers to
always pass two <pointer,length> pairs, and the packet would be
considered to be the concatenation of the two.  As the packet passes
up the protocol layers the first pointer would be incremented past
that layer's header and the length would be decremented, until the
length reaches zero (which should happen when the data is about to be
mapped into the user address space (which concept doesn't exist on
single-state machines like mine).

The last approach is certainly feasible and efficient in any
architecture, but it is more complex than I was hoping for, since I am
doing this as a local customization to vendor-provided software.  I
was hoping to keep the changes within the link level, and not change
its interface, so that I don't have to change all the network and
transport protocol drivers (at two lines per driver this would exceed
the "dozen lines" of changes).

Please reply to me, not the list/newsgroup; if there's sufficient
interest, I'll post a summary of responses.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 06:07:36 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over FDDI

Suggestion:  Instead of starting packet reception on an even byte boundary, what
if you start it on an odd boundary?  That way the odd header size will allow the
IP and TCP headers to be on an even boundary.  Will this be a problem for your
hardware?

Drew

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 07:41:31 GMT
From:      jim@eda.com (Jim Budler)
To:        comp.protocols.tcp-ip
Subject:   Re:  ^O in EMACS

In article <330@uplog.se> thomas@uplog.UUCP (Thomas Hameenaho) writes:
>In article <266@eda.com> jim@eda.com (Jim Budler) writes:
>>In article <10521@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:

[text deleted, some of my own bitches]

>I don't particularly like the Emacs use of ^S/^Q either. We have however
>learned to live with it, we use hardware handshake! This is really a big win
>anytime. If you have a 19.2Kbaud modem I'll bet it can handle hardware
>handshake. Most machines also handles it provided one use enough wires
>in the cables between the modem and computer.

Well, it's ( or was ) like this. My mac can provide hardware handshake,
provided I use the write terminal emulator. Now it can throttle the
modem at this end, but what about the other end?

Well as a result of my posting here I have learned of another option
to stty that Sun provides, NOT in the manual, by the way. Guy Harris
told me of the 'crtscts' option to stty.

Now my terminal <-> [19.2k] <-> Sun {emacs} is solved.

Thank you, Usenet News. There are even advantages to complaining
here.

jim

-- 
uucp:     {decwrl,uunet}!eda!jim        Jim Budler
internet: jim@eda.com                   EDA Systems, Inc.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 08:16:25 GMT
From:      iglesias@orion.cf.uci.edu (Mike Iglesias)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: tn3270 on WIN/TCP for VMS

In article <4335@rphroy.UUCP> doug@rphroy.UUCP (Doug Caldwell) writes:
>Does anyone have information on the availability of tn3270 for VMS.  Especially
>for use with WIN/TCP, however, any implementations would be worthwhile. 
>Perhaps replys should be posted to the net in case other sites may be
>interested.  Thanks in advance.

It's included in WIN/TCP v5.0, which is coming out now.  WIN/TCP v5.0
runs under VMS v5 only, and only on uniprocessors.  A SMP-ized WIN/TCP
is supposed to enter beta-test soon.


Mike Iglesias
University of California, Irvine

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Nov 88 14:05:29 EST
From:      JoAnn <TKSJMI@UBVM.CC.BUFFALO.EDU>
To:        tcpip mail list <TCP-IP@SRI-NIC.ARPA>
Subject:   callable ftp library

 Hi - a user on campus runs Process Software's tcpip for RT-11.

 It comes with a library that, via fortran calls, allows a user to
 perform ftp commands thru library calls.  So thru FTPINI,FTPGET, FTPPUT,
 etc. he can program a ftp session.

 Is there a similiar library available for other tcpip implementations?

 We run WIN/TCP 3.2 on VMS, BSD 4.3 Unix and IBM TCPIP vers 1.1 on CMS.

 thanks in advance,
 JoAnn
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 11:06:23 GMT
From:      roberto@cwi.nl (Rob ten Kroode)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

In article <4871@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes:
#In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
#>It seems the phrase `shadow password file' is not well known, so here
#>is a definition:

[definition of shadow password files deleted]

#You still haven't explained what use /etc/passwd is, especially if the
#passwords in it are unusable!

There is enough other information (besides the encrypted password) that
is used by various programs. We *do* want to be able to get that information.

Rob.


-- 
                                  | The two rules of Rob:
Rob ten Kroode (roberto@cwi.nl)   | rule #1 : I am _always_ right.
                                  | rule #2 : If I am not right, apply rule #1.
"I'm your icecream man; stop me when I'm passin' by..."  Van Halen

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 13:53:02 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   crackers and worms


>There is a product available from AT&T's Federal Systems group called
>MLS (Multi-Level Security) which provides B1-level security in a System V 
>Release 3.1 environment. I have seen the product on a 3B2, it's availablity
>from other vendors would probably require work by those vendors. (Yes Henry,
>we might even help them do that :-) ).
>p.s. Opinions are my own.

I'm sure its a fine product.  Would it help with this worm?  How?

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 14:50:55 GMT
From:      deke@valhalla.ee.rochester.edu (Dikran Kassabian)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: Morris, the law, and his state of mind


In article <552@comdesign.CDI.COM>, pst@comdesign.cdi.com (Paul Traina) writes:
>Look, this is getting out of hand.  Maybe I feel the way I do because my
>network was not infected.
>
>			He did not do it on purpose.
>			He *was* negligent.
>			He *should* have done more to spread the word.
>			He was *scared* of the reaction.
>			He is intelligent, and has made *valuable*
>				contributions to the net.
But what he did was nevertheless harmful and destructive, and should
not be encouraged.  Leaving him alone sends the wrong message to other
would-be virus hackers.... that its "ok" to spread a virus if you "teach
a valuable lesson".  But its not.  Consider some of the less obvious
consequences of his actions.

Scientists and researchers at a university like mine were unable to use 
their computers and network links during the virus attack, and lost valuable
time.  As always, some were up against deadlines and may well be hindered now
in their chances for getting results before a conference, or in getting a
grant proposal out before deadlines. 

The medical center/teaching hospital at my university is also network
connected.  What if the network overload caused patient monitoring systems
there to be sluggish and inadequate?  Would that be OK because Mr. Morris
"did not do it on purpose"?   As it turns out, this was not a problem here,
but it's not out of the question... it could have happened somewhere.

This is serious business!  Thank goodness you and I take the network seriously
by being good citizens and using our expertise in constructive ways.  Others
should be encouraged to do the same.

>Paul Traina				To believe that what is true for
>{uunet|pyramid}!comdesign!pst		you in your private heart is true
>pst@cdi.com				for all men, that is genius.

      ^Deke Kassabian,   deke@ee.rochester.edu   or   ur-valhalla!deke
   Univ of Rochester, Dept of EE, Rochester, NY 14627     (+1 716-275-3106)

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 15:36:32 GMT
From:      narten@cs.purdue.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Trailer implementation techniques

In article  <30939@think.UUCP> barmar@think.COM (Barry Margolin) writes:
>I am considering modifying an Ethernet implementation (specifically,
>the Symbolics implementation) to support reception of trailer packets.

The idea behind trailers is simple.  Let's minimize the amount of data
copying that takes place when applications on different machines
communicate with each other.  In UNIX (and other systems), data is
copied when it crosses the boundary between user process space and
kernel space.  When performing bulk data transfer, packet headers are
small relative to the data, and data rather than header copying
dominates the cost of packet processing.  If your machine supports
virtual memory, it might be possible to eliminate some data copying by
switching page table pointers.  Specifically, if the data that crosses
the kernel/process boundary starts on a memory frame boundary, and the
date completely fills the frame, the OS could remap page table entries
instead of copying data.  Page table twiddling is semantically
equivalent to copying so long as the data covers a complete frame.

Programs can take steps to issue write operations that operate on
frame-aligned, frame-sized amounts of data.  With library procedures,
this is fairly easy to do.  To permit the reverse case -- copy data
from OS to user space -- special steps are required to force the data
portion of an incoming packet to reside on a frame boundary.  By
default, the data portion of incoming packets won't be alligned
properly.  The trailer protocol attempts to insure that data will be
aligned properly for page table twiddling.

In trailer packets, the 14 byte ethernet header is followed by the
*user* data.  Any other headers (e.g. IP,TCP) are appended at the end
of the packet.  Device drivers are set up in such a way that the
network device DMA's incoming packets into a memory location beginning
14 bytes to the left of the start of a memory frame.  Thus, the start
of "data" (from the ethernet point of vew) begins on a frame boundary.
On receipt of a trailer packet, the device driver rearranges the
packet contents so the header logically appears before the data
portion.  This may involve copying the header to the beginning of the
packet, but most importantly, the *data* part does not move.  If an
mbuf-like data structure is used, no copying is needed.  In any case,
the header is small relative to the data.

As has been pointed out before on this list, the value of trailers is
dubious at best.  The key ideas behind trailers are:

 - remap page table entries instead of copying
 - arrange data in such a way that user data is aligned on frame boundaries
 - transfer user data in multiples of the machine frame size
 - the network carries frame-sized chunks of data

On VAXen, frame sizes are small (.5k). On Suns, they are 8K. Thus,
Suns would need to transfer 8k chunks of data in a single packet to
get any benefit.  Ethernets limit packets to 1.5k.  Thus, Suns get
*no* benefit from trailers.  Other new machine architectures favor
large frame sizes

If your systems emphasize one protocol family (e.g.  TCP/IP), your
system can get the same performance gain without having to actually
use trailer encapsulation.  One simply directs the network device
driver to assume that most packets will have OFFSET = 14+20+20 bytes
of headers (Ethernet/IP/TCP) prepended to the data. The driver then
arranges to DMA incoming packets starting at memory location -OFFSET
from the begining of a memory frame.

Even if the performance win is big (I know of no hard evidence that it
is), each machine must have smarts that allow it to determine which
other machines on the LAN run trailers and which do not.  If one
machine uses trailers to communicate with a machine that does not,
things just don't work.  This is one of famous network features that
(like broadcast storms), each site seems to re-discover independently,
after several hours of hair pulling.

The relevent trailer question is not "how does one implement
trailers", but "why implement them at all".
-- 
Thomas Narten
narten@cs.purdue.edu or {ucbvax,decvax}!purdue!narten

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11 Nov 88 16:58:53 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

In article <4871@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes:
>You still haven't explained what use /etc/passwd is, especially if the
>passwords in it are unusable!

The slightly-misleadingly-named /etc/passwd file also contains the
mapping between login name and internal user number, some information
about the group(s) the user belongs to, the name of his home directory,
the name of his command interpreter, etc.  It's the central "user database"
for the system.
-- 
Sendmail is a bug,             |     Henry Spencer at U of Toronto Zoology
not a feature.                 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 17:35:35 GMT
From:      galbp!wittsend.LBP.HARRIS.COM!mhw@gatech.edu  (Michael H. Warfield)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: shadow passwords?
In article <4871@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes:
>In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
>>.....  Updates must happen to both files.

>Updates of what??  Passwords?

     Updates of anything.  Passwords, userid's, home directories, etc.

>You still haven't explained what use /etc/passwd is, especially if the
>passwords in it are unusable!

     The password file contains alot more than just passwords.  Users are
identified symbolically by many programs by symbolicly relating their numerical
id with their login user name through the password file (say every time you
do a directory with ll).  It provides the users home directory for a wealth of
programs as well.  Many of them do not need to see your encrypted password.
This shadow password file relates the the "orange book" security level C1.
(I think.  I'm playing this one by memory so keep the flames to a dull roar.)
The idea is to restrict the password field to only those programs with
legitimate need.  All other programs see the identical information in all fields
except the encrypted password.

     The password file is even used by mail and news when building the "From:"
entries so we know who sent these things, the full name in the "From:" field
comes from the comment (or GCOS) field in the password file (Yes you can type
them in by hand but who does).

---
Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 18:07:01 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  EMail server alternative


>Like sendmail, MMDF allows mail to be sent to processes.  Unlike sendmail,
>this can only be done to pre-registered addresses or by the recipient.

This is also the way that sendmail is SUPPOSED to work. Thats why
it is a bug that he was able to do it via debug mode.

Try sending mail to a process on a system that doesn't have debugging
compiled it. It wont work. The process has to be specified in the alias file.

---rick

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 18:11:46 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Trailer implementation techniques

In article <5380@medusa.cs.purdue.edu> narten@cs.purdue.EDU (Thomas Narten) writes:
[Summary of RFC-893 ommitted.]
>  This may involve copying the header to the beginning of the
>packet, but most importantly, the *data* part does not move.

That is the crux of my question.  How do you copy the header to the
beginning of the packet without moving the data to make room?  As I
said, remapping page tables is not an option, since the Ethernet
driver is implemented in a process running in virtual mode on
Symbolics machines (packets are just Lisp byte arrays).

>The relevent trailer question is not "how does one implement
>trailers", but "why implement them at all".

That issue is not important to me.  The point is, some of our machines
like to send trailer packets, and we lose when they try to do it to
Symbolics machines.  The Suns and 4.3bsd machine use trailer
negotiation, but Ultrix requires us to specify "-trailers" in the
ifconfig command in /etc/rc.local, and sometimes this gets omitted.
Sometimes I'll realize the problem right away, but other times people
go for days without figuring it out.  I see no reason why the Lispms
shouldn't be able to receive anything the Vaxen like to send (within
reason).  I have NO plans to teach the Lispms how to SEND trailers,
though.

I see this as an instance of "be liberal in what you accept,
conservative in what you send" rule.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 18:45:09 GMT
From:      mkhaw@teknowledge-vaxc.ARPA (Mike Khaw)
To:        comp.protocols.tcp-ip
Subject:   Re: EMail server alternative

Where is MMDF available from, and what does it cost?

Mike Khaw
-- 
internet: mkhaw@teknowledge.arpa
uucp:	  {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 18:53:16 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .


   2. Don't take their questions *too* seriously, they're just poking
   around in the dark (particularly about technical matters.) ...

No kidding.  Someone from the NY Times called HP, asking if we had a
"neural" connection to CSNET.

wunder

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 19:05:29 GMT
From:      TKSJMI@UBVM.CC.BUFFALO.EDU (JoAnn)
To:        comp.protocols.tcp-ip
Subject:   callable ftp library


 Hi - a user on campus runs Process Software's tcpip for RT-11.

 It comes with a library that, via fortran calls, allows a user to
 perform ftp commands thru library calls.  So thru FTPINI,FTPGET, FTPPUT,
 etc. he can program a ftp session.

 Is there a similiar library available for other tcpip implementations?

 We run WIN/TCP 3.2 on VMS, BSD 4.3 Unix and IBM TCPIP vers 1.1 on CMS.

 thanks in advance,
 JoAnn

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 19:38:48 GMT
From:      mcrware!droid@uunet.uu.net  (Andy Nicholson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <6480@galbp.LBP.HARRIS.COM>, mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) writes:
> In article <832@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes EDtzo> >4) I do not in any way condone or support the irresponsible or destructive
> > 4) I do not in any way support or condone the irresponsible
												  ^^^^^^^^^^^^^			
> >	acts of others
> 
>      Yeah but:
> 
>      5) When faced with the results of his little experiment, he tucked tail
> and ran like hell.
> 
>      How much time and effort would he have save all of us if he had
> announce what he had done, admitted his mistake, and provided any and all
> assistance he could to stopping it.  His gravest irresponsibility was in
												   ^^^^^^^^^^^^^^^^
> running for cover and letting everyone else suffer from his stupidity!

> Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
>   (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
> An optimist believes we live in the best of all possible worlds.
> A pessimist is sure of it!

One cannot expect a person who does an irresponsible thing to become
suddenly aware of responsibility.  I am sure that many drunk drivers who are
able leave the scene of an accident they cause.

We can, at best (I am a pessimist and cynic), hope to teach the offender
responsibility and use him as an example to others.  Of course, my personal
feelings are that those who commit irresponsible acts with malicious intent
should be taken out and shot (after being proved guilty, of course).  No
smiley face.

Andy Nicholson  uunet!mcrware!droid
These are my opinions, Microware's policy manual says so.
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 20:57:16 GMT
From:      rick@seismo.css.gov  (Rick Adams)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
At the very least, you should mail the suspected (or proven) problem
to Berkeley. They do listen.

There's no security argument against sending it to Berkeley. Let them
decide to post it or not (if you have doubts yourself).

There is no legitimate reason to keep things like that to yourself.

(and Berkeley is aware of the details of the setuid shellscript bug.
They know of no fix other than to stop using setuid shellscripts. Thats
the bug fix they posted. They chose not to post the bug, but the
only fix they knew)

--rick
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 21:02:12 GMT
From:      jordan@ADS.COM (Jordan Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: EMail server alternative


	Like sendmail, MMDF allows mail to be sent to processes.
	Unlike sendmail, this can only be done to pre-registered
	addresses or by the recipient.

before this turns into the semi-annual sendmail-bash-o-rama, i'd like
to remind the general public that sendmail can be made to do this as
well with changes to 3 lines of code, which jeff forys (among others)
have posted elsewhere.  many of us have been running this way for
years.

/jordan

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 21:22:58 GMT
From:      paulr@prapc2.UUCP (Paul Raulerson)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert Morris

In article <10791@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes:
>In article <1445@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
>>
>>According to press reports, RM spent his summers working at AT&T
>>on "Unix Communications Software Security". Anyone with a source
>>license check to see if he slipped a trojan horse into uucico
>>or uuxqt or something?
 [deleted text]
>It is very easy in the aftermath of something like this to indulge in
>the devil theory of crime -- that all bad things must come from evil
>minds.  The more you find out about rtm I believe the more you will find
>he has in common with the people criticizing his behavior.  He has done
>significant work in computer security, including warning people for
>years about the security holes that made the worm possible.  He has
>worked as a sysadmin for an arpanet host.  He is a serious student of
>computer science and was making contributions to the field at an age
>when most of us were trying to learn Pascal.  He's also one hell of a
>great guy, and no one seems more appalled by the effects of his actions
>than he is.
>
>We can argue about the advisability of what he did, but I urge you to
>resist the temptation to pigeon-hole someone you don't know on the basis
>of fragmentary information.
>
>Jim Matthews

Gee, What a *HELL* of an attitude to take about someone who has just cost a 
lot of people and organizations a terrifically large amount of resources.
To a great extent, this wonderful wacky and extremely open net of ours is
self policing.  People who abuse their privs most often loose them.  Once,
when I was a tad younger, I might have agreed with you about showing more
compassion and understanding, but since I have been running this system at
some cosiderable expense, and deaing professionally with the government for
about 10 years, I feel that this self policing action should be encouraged.

After all, there is nothing in the world stopping Mr. Morris from going
off and starting his own network, as secure as he wishes now is there? But
participation in a group environment means you have to be responsible enough 
to realize that other peoples' resources are NOT your personal private toys
to play with.  I think it is far more humane to have Mr. Morris recognized
by System Adminsitrators everywhere as a security risk, and be denied access,
with threat of legal action is his illegal activites continue, than it is 
to slap him on the wrist and tell those same System Adminstrators that he
CANNOT be denied access because he really didn't mean it and is sorry for
what he did. 

People have to be responsible for themselves, and yes, they have to 
realize everyone makes mistakes and be willing to "forget" them.  However,
there is *always* a price associated with such forgetfulness, and 
Mr. Morris, or whoever the guilty critter was, has yet to pay for 
his play.

This isn't really a personal attack on anyone, it is just more of a
defense of the openess we all share here, and what it may take to 
keep it open.  Anyone wishing to has the matter over some more, your
welcome to mail me and if it seems reasonable, I'll summarize the
opinions and post 'em back as a single message.



-- 
Paul Raulerson & Paul Raulerson & Associates   +---------------------------+
Data/Voice: 1+215-275-2429 / 1+215-275-5983    | OS/who? Why bother? Isn't |
Cis: 71560,2016   Bix: paulr                   | Mess-Dos bad enough?      |
UUCP: ...!rutgers!lgnp1!prapc2!paulr           +---------------------------+

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 22:11:40 GMT
From:      dluong@ARISIA.XEROX.COM (Daphne Luong)
To:        comp.protocols.tcp-ip
Subject:   Telnet binary mode question


How does a Telnet connection work in binary mode? Do we leave everything
as is without adding or deleting a LF when we see a CR?

Suppose if we are in binary mode, are we still supposed to handle commands like ls, date, etc.?

Thanks,
    Daphne

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 23:21:12 GMT
From:      chris@mimsy.umd.edu  (Chris Torek)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
>In article <44440@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) notes:
>>I have not been able to find ONE person who claims to
>>have known that sendmail compiled with DEBUG on would have allowed
>>anyone with SMTP access to run an arbitrary program on their machine.

In article <4992@polya.Stanford.EDU> shap@polya.Stanford.EDU
(Jonathan S. Shapiro) replies:
>Okay. Here it goes. I knew as early as 1984 or 1985 that this
>misfeature existed, and that it got you a root-shell, which certainly
>means you can run an arbitrary program on a remote machine.

Actually, you get a `daemon' shell---not as bad, but, as Keith put it,
`not my idea of a good time'.

>What's more, I reported this problem to DEC, Sun, and Berkeley at the
>time.

Keith Bostic searched Berkeley's bug log for everything relating to
sendmail.  This bug was NOT in the log, which means it was not received
at 4bsd-bugs@Berkeley.edu.

If you send a bug report to 4bsd-bugs@Berkeley.edu and do not get a
reply from `Bugs Bunny', your mail may have been lost; please re-send the
message.  Better to get duplicates than none.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 23:51:53 GMT
From:      booloo@lll-lcc.llnl.gov  (Mark Boolootian)
To:        tcp-ip@sri-nic.arpa
Subject:   ftp/telnet test suite request
---

	I am in need of test suites for exercising two gateways which we have
written:  an ftp gateway server and a telnet gateway server.  The servers
were derived from the AT&T versions and have the same functionality as the
Ultrix versions.  If you don't know of any test suites but have suggestions as
to where else I might look, that information would also be useful.  Please
respond via email as I'm forever behind in reading this group.  Thanks in
advance.

mb
-- 
uucp:  {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo
arpa:  booloo@lll-lcc.arpa
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 88 23:56:52 GMT
From:      childers@avsd.UUCP (Richard Childers)
To:        comp.protocols.tcp-ip
Subject:   Re: And You Thought You Were Paranoid...

In article <7080011@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes:

>In PRINCIPLE "ls -l" is not enough. The worm had root privs, it could have 
>installed a modified /bin/ls so that if one of the files being listed
>was fsck, vmunix, ls, telnetd etc (the tampered binaries) /bin/ls
>would always show predetermined sizes. In that situation, "ls -l" wouldn't
>be enough.

I thought about this a long time ago, back when I first realized that given
a source license, one could be the source of a lot of trouble. I was just
starting as a system administrator, and so I didn't do anything fancy - I
made a script that used checksums generated from binaries off the tape and
stored a backup of the script on another tape.

A variation on this theme reports drift from network mean on the part of
any critical file on any critical machine ( 'critical' meaning 'important
enough for me to install this silly-assed paranoid script on' ) and keeps
backup copies at a secret location. If someone wants to play those games,
they're going to have to work harder than I am already.

>In such a situation, you would have no inkling that there was anything
>wrong.

Assume the worst from the first, then you won't be surprised.

>This kind of paranioa isn't worth it ...

It's saved me hours of work on a monthly basis for years.

>		      Naim Abdullah

-- richard

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 01:46:13 GMT
From:      kent@WSL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages

Only Unix (that is, 4.2-derived systems) reserve ports less than 512.
There's no restriction on, say, an IBM PC running a random
implementation of TCP and Telnet.

chris

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 01:58:45 GMT
From:      clong@topaz.rutgers.edu (Chris Long)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: Morris, the law, and his state of mind

OK, if you think he should be punished, what should the extent of the
punishment be?  I personally feel nothing more than something token
is in order, say a fine and 100 hours of community service.  People
like Mr. Morris do *not* belong in jail.

Cheers,
-- 

Chris Long
Mathematics Department
Rutgers University
New Brunswick, NJ  08903

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 02:04:34 GMT
From:      leres@ace.ee.lbl.gov (Craig Leres)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Virus: SunOS patches

I've had some dialogue with Chuq Von Rospach about this worm patch
thing and have concluded that it should have taken much longer than 5
days for Sun to approve Berkeley's patches. (My back of the envelope
calculations show that this process requires at least 3 years, 3
months, and 5 days.)

I withdraw my previous remarks and commend Chuq Von Rospach and Sun
Microsystems for their amazing effort which shoe horned years worth of
work into a mere 5 days.

		Craig

P.S. If another problem develops which affects tens of thousands of
Unix systems and you can't wait years or even days for a fix, wait a
few hours and I'll bet Berkeley will come up with something.

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 06:09:58 GMT
From:      wesommer@athena.mit.edu (William Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Ethernet spies.

In article <1801@sbcs.sunysb.edu>, somebody logged in as root writes:
>
>	Huh?  If you let anyone on your Ethernet cable with a PC you've
>	basically just given up any hope for security.  Even active
>	methods like Kerberos will not protect you from people who
>	just listen to eg TCP sessions on the cable.  


So, "you can look, but you can't touch".  For the most part, that's
good enough for academia, once you train people to know not to type
passwords in the clear over a network, which is admittedly easier said
than done.

Kerberos allows the networked applications to securely exchange a
session key; this can allow them to encrypt any "sensitive" data they
send, or attach an encrypted checksum to each request in a connection.
There isn't much use of this yet, but I suspect that it will become
somewhat more common in the future.

Given the speed of most software DES encryption implementations, you
pay dearly for encrypting entire packets (with an order of magnitude
of 100s of milliseconds/packet on each end of a conversation).  If
you're less concerned about security, you can always use a weaker but
faster encryption method, such as XORing the data with bits from a
pseudo-random number generator seeded with the session key.

					- Bill
-- 

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 07:10:32 GMT
From:      dmr@alice.UUCP
To:        comp.protocols.tcp-ip,comp.unix.wizards,news.sysadmin
Subject:   Morris Tech Report

Those interested in earlier works of Robert T. Morris,
or interested in network security in general, might wish
to read AT&T Bell Laboratories CSTR #117, "A Weakness in the
4.2BSD Unix TCP/IP Software," by Robert T. Morris,
dated Feb. 25, 1985.  An abstract of the abstract:

	... [E]ach 4.2BSD system "trusts" some other set of other
	systems, allowing users logged into trusted systems to
	execute commands via a TCP/IP network without supplying
	a password.  These notes describe how the design of TCP/IP
	and 4.2BSD implementation allow users on untrusted and
	possibly very distant hosts to masquerade as users on
	trusted hosts.  Bell Labs has a growing TCP/IP network
	connecting machines with varying security needs;
	perhaps steps should be taken to reduce their vulnerability
	to each other.

This technical report, as well as others, may be ordered by writing to

	Ellen Stark
	Room 2C579
	AT&T Bell Laboratories
	600 Mountain Ave.
	Murray Hill,
	NJ 07974

These reports are free of charge.

			Dennis Ritchie
			research!dmr
			dmr@research.att.com

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 16:56:04 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .

In article <8811081844.AA13028@vax.ftp.com> sam@VAX.FTP.COM writes:
>In the front page and followup
>articles in the Boston Globe today (the Globe is a highly acclaimed,
>respectable paper for you non-Bostonians) portrayed this Morris character
>as a hackers' folk hero.  It seemed to quote countless people praising him
>for his brilliance and ingenuity and suggesting that he did us all a favor
>by "exposing" this sendmail bug to the Internet at large, but quoted nobody
>who in any way, shape, or form said, "Oh great.  What an asshole."

Putting aside your description of the Globe as "respectable", I would
like to think that the media's portrayal of Robert as "brilliant" and
"ingenious" comes from the many interviews with people who know him and
have worked with him, all of whom will gladly offer comments describing
him as brilliant, his work ingenious, his manner uniformly helpful,
and his intentions always free of malice.  This particular event is
certainly confusing to those of us who harbor such opinions, but it's
also not enough to sweep them away.

Sherri, I've known assholes, I've worked with assholes, and RTM
is no asshole.

-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 17:42:04 GMT
From:      daveb@gonzo.UUCP (Dave Brower)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   SF columnist on the Worm, suggests new terminology.

Jon Carrol's Wednesday column in the SF Chronicle is an interesting
example of the level of "popular journalism".  It gyrates wildly between
keen insight and gross misinterpretation, arriving at something near a
balanced perspective.

It does suggests a metaphor for these events, in the spirit of the
tcp-ip swamp:  The worm "frogged" the Internet.  We could refer to 
painfully visible spelunking as "frogging".

-dB

----------------

                    "Random Thoughts About the Worm"

As faithful followers of the media and the hypermedia are already aware,
a computer "worm" infected numerous extremely large computer systems
around the country last week.  The worm's name was ":sed
'1,l$/d':/bin/sh," or "sh" to its friends.  It did no real damage, but
it did eat up an enormous amount of column inches and TV air time.

In conversations with people who know more about computers and worms
that I do (approximately half the known world), the following facts
and/or plausible opinions have emerged.

1.  The difference between a worm and a virus is similar to the
difference between a common cold and brain cancer.  A worm does not eat
up or change existing cells; it just fills up empty information cavities
with disgusting gunk.

2.  Interestingly, there is no direct cybernetic evidence that Robert
Morse Jr. is the worm-master.  Computer technology being what it is, the
"telltale files" could have been planted by anyone, including Barry
Manilow.  I make no accusations here; I merely note the possibility.

3.  What allowed the worm to enter the systsems was a programming
structure called a "trapdoor," which is a device built into a computer
system that allows the very smartest people to move more quickly through
the system than the ordinary user.  Such holes exists in virtually every
system, including the ones that allow you to withdraw $100 on Saturday
and the ones that launch large pizzas at Leningrad.

4.  WHATEVER ITS CAUSES, the Worm Event was essentially a benign
occurance.  Given the sophistication of the worm program, it is easily
possible that the worm master could have introduced a curious anomaly
into, say FedWire, which is responsible for transferring $500 billion
(think: half-a-trill) around the planet each and every day.

5.  It is an interesting question, not yet decided, whether members of
the affected networks (like the University of California) could sue UNIX
(from whom they bought the program with the trapdoor that let the worm
begin to burrow) for lost revenues.  Although there is no case law on
the matter, there is also no reason why not.

6.  It is necessary to make a distinction beween "hackers" (who are
simply people who understand computers very well and are unwilling to
accept authoritarian definitions of what they should do with their
knowledge) and "crackers," who invade extant computer system with malign
intent.  It seems probable that the worm-master was a hacker. To blame
him (or, possibly her) for the trapdoor is like blaming Cassandra for
the fall of Troy.

7.  THE MOST IMPORTANT thing to understand is that computer programming
is an extremeley intense art form.  It is also a scientific discipline,
but its addictive fascination lies in its creative component.  Creating
a truly innovative program is (for the artist) exactly like painting the
roof of the Sistine Chapel.

Therefore, the hole that the worm went through may bee seen (in
aesthetic terms) as a big blank piece between the figure of Adam and the
figure of God on said ceiling.  The hacker/artist saw the hole and said,
"I'll bet the original artist meant for the two hands to be touching
there.  How stupid of him to have forgotten to put that in."

So the angry artist, upset at the unlovely disunity, decides to draw a
big frog between God and Adam.  "This," he says to himself, "will
probably call attention to the problem."

- Jon Carrol

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 20:46:57 GMT
From:      bsu-cs!dhesi@iuvax.cs.indiana.edu  (Rahul Dhesi)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <14505@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Actually, you get a `daemon' shell---not as bad, but, as Keith put it,
>`not my idea of a good time'.

But at's jobs to be executed are owned by daemon, so isn't being daemon
just a trivial step away from being root?  Somebody mentioned this
earlier and nobody contradicted him.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 21:14:01 GMT
From:      pasteur!agate!bionet!apple!vsi1!wyse!mips!mash@ucbvax.Berkeley.EDU  (John Mashey)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <2373@aplcomm.jhuapl.edu> jwm@aplvax.UUCP (Jim Meritt) writes:
>In article <829@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes:
>}I'll bet the KGB are laughing their asses off.
>Bet they're not:  They see what a kid without malacious intention can do,
>and then they look at their rather pitiful computer systems, look at our
>trained personnel WITH malicious intent, and probably shudder....

On the other hand, is the state of networking in the USSR such that
6000 machines could easily be infected in a day?....I have no personal
knowledge, but I'd guess not.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 22:54:28 GMT
From:      chris@mimsy.umd.edu  (Chris Torek)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <4713@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>But at's jobs to be executed are owned by daemon, so isn't being daemon
>just a trivial step away from being root?  Somebody mentioned this
>earlier and nobody contradicted him.

Who runs `at'? :-)  (We use MDQS; `at' is a front-end for the batch queue.)

To forestall the inevitable: MDQS is available from BRL.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 23:14:45 GMT
From:      libes@cme-durer.ARPA (Don Libes)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: UNIX bashing (Re: a holiday gift from Robert "wormer" Morris)

In article <11226@cgl.ucsf.EDU>, seibel@cgl.ucsf.edu (George Seibel) writes:
> "Congratulations!  You just
> bought a fine copy of Unix.  Don't keep any files you care about on it."

I already see messages like that.  Whenever I run gnuemacs, I get:

  GNU Emacs comes with ABSOLUTELY NO WARRANTY; type C-h C-w for full details.

Sounds similar if not as overt.  In any case, I'm not the least
surprised when gnuemacs trashes my files/buffers.  (Same for UNIX.)

Don Libes          libes@cme.nbs.gov      ...!uunet!cme-durer!libes

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 88 23:22:10 GMT
From:      weemba@garnet.berkeley.edu (Obnoxious Math Grad Student)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   "Morris did it"--the new excuse?

In article <1570@valhalla.ee.rochester.edu>, deke@valhalla (Dikran Kassabian) writes:
>Consider some of the less obvious consequences of his actions.

OK.

>Scientists and researchers at a university like mine were unable to use
>their computers and network links during the virus attack, and lost
>valuable time.  As always, some were up against deadlines and may well
>be hindered now in their chances for getting results before a confer-
>ence, or in getting a grant proposal out before deadlines.

When I've taught courses that use computers, I told students that under
almost all circumstances, computer downtime would not be an excuse for
lateness.  The one exception I've ever made involved granting everyone
a week's extension.  I've never worked assuming that the machines I use
are 100% reliable.  Do the scientists/researchers at your site do so--
even on critical stuff?  If someone has a grant proposal riding on get-
ting something done by a certain deadline, what happens if there's a
major disk crash at your site?

>The medical center/teaching hospital at my university is also network
>connected.  What if the network overload caused patient monitoring systems
>there to be sluggish and inadequate?  Would that be OK because Mr. Morris
>"did not do it on purpose"?  As it turns out, this was not a problem here,
>but it's not out of the question... it could have happened somewhere.

Are you saying that the patients at your university are in possible trouble
on days when the ARPANET is slow?  That if a machine crashes unexpectedly
that patients have nothing to rely on but prayer?  I find it frightening
that hospitals exist which have perhaps decided to rely heavily on some
computers working according to a perfect schedule.  Don't you?

Hospitals generally have a backup power supply.  For a very good reason.

>This is serious business!

Yes this is *all* serious business.  Computers used primarily for USENET
or hack or what-not can be dead for awhile and merely inconvenience lots
of people.  But now you cite computers where users cannot afford to have
computers to be down for long--do the sites that run them without having
any contingency plans whatsoever?  Such sites are irresponsible.

I find it remarkable that in such a computer-literate group that we all
supposedly represent, and thus all know that "the computer did it" is NOT
an acceptable excuse, that anyone, let alone the apparent horders here,
would quickly adopt "the worm did it".

What is the difference between:

	I'm sorry, Mrs Brown, your husband died because of a
	computer power failure.

and

	I'm sorry, Mrs Brown, your husband died because the
	Morris worm knocked out our computers.

?  To Mrs Brown, I would expect none whatsoever.

And you seem to be implying that the latter is to be blamed solely on RTM;
I believe the hospital that would or should be held culpable in the first
case is just as negligent in the latter, and should not be allowed to pass
the responsibility buck.

ucbvax!garnet!weemba	Matthew P Wiener/Brahms Gang/Berkeley CA 94720

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 03:42:43 GMT
From:      vixie@decwrl.dec.com  (Paul Vixie)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <3380@emory.uucp> arnold@emory.UUCP (Arnold D. Robbins {EUCC}) writes:
# In article <44440@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:
# >I have not been able to find ONE person who claims to
# >have known that sendmail compiled with DEBUG on would have allowed
# >anyone with SMTP access to run an arbitrary program on their machine.
# 
# Didn't Paul Vixie say he knew it? If not, I apologize in advance.

Yes, Paul Vixie did indeed say that he knew it.  Rick Adams and I exchanged
some mail about this, and he pointed out basically that if I knew this was
possible but didn't recognize it as a security hole, the knowledge was
pretty much useless.

At the time I was first digging into sendmail, some time in 1986, I was not
at all sure what it was all for, what it all meant, and whether I understood
any single part of it.  (This seems normal among sendmail proto-hackers :-)).
When I discovered all the various functional changes you could make in debug
mode, I assumed that there was a good reason for all of them and I dutifully
ported and patched and debugged the complete program, with all holes intact.
Even when I found what I thought was a bug, I tried very hard to re-understand
intention and implementation, on the constant assumption that it was supposed
to be the way it was, all details included.

I know better today, of course.  If I had had occasion to poke into sendmail
three weeks ago and notice that
      if (a->q_alias == NULL && !tTd(0, 1) && !QueueRun && !ForceMail)
                             ^^^^^^^^^^^^^
in recipient() in recipient.c, you may safely bet you a** that I'd send off
some mail to Berkeley.  I now feel (somewhat arrogantly, I'm sure!) that I
know what's intended in 90% of the sendmail code.

This points up an interesting dynamic of publicly available source code.  If
the only people who are studying it carefully are those still wet behind their
ears, and these people lack the overall knowledge and confidence to question
what they see, we may all be in a heap of trouble.  I hope we'll all learn to
be a little bit nicer to the next person who asks a "stupid" question...
-- 
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13 Nov 88 20:35:16 PST
From:      kjd%rust.DEC@decwrl.dec.com (Kevin J. Dunlap - DECwest Engineering)
To:        clong@topaz.rutgers.edu (Chris Long  12-Nov-88 0158 GMT)
Subject:   Re: Morris, the law, and his state of mind
 
>>From:  clong@topaz.rutgers.edu (Chris Long  12-Nov-88 0158 GMT)
>>
>>OK, if you think he should be punished, what should the extent of the
>>punishment be?
 
Three years working for the NIC having to deal with the day to day
problem solving and fire fighting that has to be done on a large network.
 
-Kevin
 
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 13:34:52 GMT
From:      jfh@rpp386.Dallas.TX.US (John F. Haugh II)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: rtm and uucp

In article <8409@alice.UUCP> dmr@alice.UUCP writes:
>None of the work he did is in any product, and he didn't have
>any opportunity to tamper with the master source code--
>that is really quite far away from Research.

It would be so nice if someone would undertake a security audit to
insure that work other college students did, which *is* currently
in production, doesn't contain any surprizes.

Our friendly enchilada may not be the only prankster out there ...
-- 
John F. Haugh II                        +----Make believe quote of the week----
VoiceNet: (214) 250-3311   Data: -6272  | Nancy Reagan on Artifical Trish:
InterNet: jfh@rpp386.Dallas.TX.US       |      "Just say `No, Honey'"
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 14:40:11 GMT
From:      sean@cadre.dsl.pittsburgh.edu  (Sean McLinden)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
I feel, in part, responsible for some of this discussion since I commented
that the bug(s) were well known by many system programmers prompting the
response "Well I didn't know about it?" or "Why didn't you tell anyone?"

It is clear from Rick Adams' comments that 'not wanting to tip anyone off'
is no excuse. Even binary-only sites can be protected fairly rapidly if
the appropriate channels are used.

Specifically:

fingerd.c: This bug (the use of gets() with a fixed buffer size), is
commonly used as an example of poor programming technique in C programming
courses. There are a lot of these in user contributed software and a
few more were present in earlier versions of Berkeley unix. It didn't
occur to me to look for it in daemon sources until we detected the worm
because I never really had occasion to look at fingerd, but problematic
nature of that particular programming style is well known. One problem
may be that many people learn C by example, not formal instruction. In
that mode, you look more towards what can go right than what can go
wrong. Perhaps someone could write a book on 'How NOT to program in C!'

sendmail: In the context in which it was intended to be used this is
not really a bug but a gaping hole. In fact, there is nothing wrong
with being able to mail to a process (uucp would be in trouble if
you couldn't). The problem is that the mechanism by which this capability
is controlled should rest in the 'aliases' file or with compile and/or
run time options that can be applied under appropriate conditions by
the system administrator or software developers. Again, the problem is
not the existence of this "feature" but the fact that it was the default
capability on distributed BSD systems.

Again, in the context of a programmer's assistant, this feature was
known by many people. When the worm appeared a grep of the syslog
file was all that was needed to determine what in sendmail (actually
the smtp server, to be precise), was allowing all the trouble to occur.
In that context, what was a convenience became a security hole (please,
I don't want to argue semantics).

Most of my system work is goal-oriented. My default mode is not to
be always thinking "How can I exploit this to invade thousands of
machines across the country?". The best I am capable of is to remember
those things that I have noticed in the past and reconsider then in
light of a new context (that of a security problem). Now I am prompted
to look more closely at sources, not with the idea of making things
more efficient, but with the goal of making them more secure.

In the 14th century Marco Polo brought Chinese technology to the west.
In particular, he brought fireworks which the Chinese had used to amuse
themselves for centuries. It was Western culture that first exploited
this technology for warfare. The Chinese had only peaceful applications
in mind.

It accomplishes little to flame those people who knew the flaws of
BSD anymore than it does to blame the Chinese for modern warfare. Maybe
we should all be a little more suspicious (after what has happened
we probably will be). The point is that that what happened with the
worm could be attributed as much to the mindset of the Unix community
as to Morris' programming skills (probably more so the former). What
seems to be obvious problems in the system are only so in the context
of their exploitation by people with different orientations than
ourselves. It was an oversight (and I, for one, am reassured), that
the potential for harm did not occur to all of us, earlier.

There are people whose job it is not to promote open systems but to do
nothing but determine what are the security problems with any system.
They constantly operate in the mindset of someone attempting to
break a system. They work for industry, DoD, NSA, the FBI, and a lot
of speciality security firms. A better question is: If those people
knew why didn't THEY tell anyone?

Sean McLinden
Decision Systems Laboratory
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 15:32:26 GMT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

>From: kent@wsl.dec.com
>
>A long time ago, in a context far, far away, the standard unit of
>bogosity was declared to be the "lenat". Except that, like the coulomb,
>1 lenat is so large that one normally uses the microlenat.

I give up, who was Mr/Mrs/Ms/Miss Lenat ?   - Craig

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 17:36:24 GMT
From:      beattie@visenix.UUCP (Brian Beattie)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: UNIX bashing (Re: a holiday gift from Robert "wormer" Morris)

In article <720@muffin.cme-durer.ARPA> libes@cme.nbs.gov (Don Libes) writes:
/                                              I'm not the least
/surprised when gnuemacs trashes my files/buffers.  (Same for UNIX.)
/
/Don Libes          libes@cme.nbs.gov      ...!uunet!cme-durer!libes

I'm not the least surprised when the hammer smashes my thumb.

Think about it.
-- 
    _ANYONE_     | Brian Beattie          (703)471-7552
can sell software| 11525 Hickory Cluster, Reston, VA. 22090 
that has already | beattie@visenix.UU.NET
been written     | ...uunet!visenix!beattie

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 17:42:58 GMT
From:      mrd@sun.soe.clarkson.edu (Michael DeCorte)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert "wormer" Morris


Think of the fun everyone is going to have when the politicians and
lawers start chewing on this.  Especially any of them who read CACM.
Can you say regulation?

--

Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676
Internet: mrd@sun.soe.clarkson.edu  // Bitnet:   mrd@clutx.bitnet        
---------------------------------------------------------------------------
Clarkson Archive Server // commands = help, index, send, path
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
---------------------------------------------------------------------------

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 18:11:45 GMT
From:      root@sbcs.sunysb.edu (root)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

In article <881107224915.20c01427@Sds.Sdsc.Edu>, gkn@SDS.SDSC.EDU (Gerard K. Newman) writes:
> >What about machines that have met with tempest specs?
> >
> >					Rick Spanbauer
> >					SUNY/Stony Brook
> TEMPEST is a specification for the controlling of electromagentic
> emissions through which data on a computer system can be compromized.

	Gerard, yes thanks, I know tempest is an EMI spec.  My apologies
	for incorrect usage in the original article - I had mistakenly
	mixed another spec with TEMPEST.

> gkn
> ----------------------------------------
> Internet: GKN@SDS.SDSC.EDU
> Phone:	  619.534.5076

					Rick Spanbauer
					SUNY/Stony Brook

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 18:49:43 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Dumb question: ping w/o icmp support?

Dr. Doug Lenat did his thesis work on heuristic methods of proving simple
mathematical properties.  Doug was not known for tackling easy problems.
Nor for shyness.  And he was the most voracious user of PDP-10 cycles
in the '70s.
Dan
-------

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 00:03 EST
From:      TomZ @ DDN1.arpa
To:        TCP-IP @ SRI-NIC.arpa
Cc:        B602-ALL @ DDN1.arpa, StJohns @ beast.ddn.mil
Subject:   FBI Contact re: November Internet Virus
         Were YOU hit by the November Internet Virus?
 
                      The FBI wants to hear from you!
 
The Federal Bureau of Investigation is attempting to gather critical
information necessary to pursue this case under the Computer Fraud and
Abuse Act of 1986.  (This is the statute that makes it a federal crime
to penetrate a computer owned by or run on the behalf of the Government.)
 
The FBI Case Agent has asked the Defense Data Network Project Management
Office to collect the names of organizations and Points of Contact (names
and phone numbers) that were hit by the Virus.  The Defense Communications
Agency has established an E-Mail address for this collection at:
 
                       INFO-VACC [at] BEAST.DDN.MIL
 
    Points of Contact should expect to be contacted by their local FBI
    agents for dispositions due to the wide geographical area involved.
 
 
                     I * M * P * O * R * T * A * N * T
 
            The FBI needs this information to pursue the case.
 
      If we expect their aid in the future, we need to help them now.
 
PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!
 
/s/
Tom Zmudzinski
DDN Security Officer
(703) 285-5206

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 19:24:53 GMT
From:      law@udel.EDU (Jeff Law)
To:        comp.protocols.tcp-ip
Subject:   Re: rtm and uucp

In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>It would be so nice if someone would undertake a security audit to
>insure that work other college students did, which *is* currently
>in production, doesn't contain any surprizes.
>Our friendly enchilada may not be the only prankster out there ...
I sincerely hope you are not making a general statement about college
students.  I take great pride in the fact that UDel allows some students
to work at the system level, even in system administration, I happen
to be one of those students and have taken slight offense to the recent
messages that seem to knock college students as being like RTM.  Not
all of us write worms and think about how to break security in our spare
time.

-- 
Jeffrey A Law
University of Delaware  PHONE: (302)-451-8005,  (302)-451-6339
ARPA: law@udel.EDU,  UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!law

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 20:26:42 GMT
From:      wisner@killer.Dallas.TX.US (Bill Wisner)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

The latest releases of System V (from AT&T R&D) have a shadow password
file called /etc/private. The time at which a user's password was last
changed is stored in private so password changing can be disallowed unless
a certain time has passed. It also allows mandatory changing after a certain
interval; but then, what doesn't? private can also contain a "dead login
date" after which an account will be unusable.

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 21:01:54 GMT
From:      alb@olden.uucp (Adam L. Buchsbaum)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: rtm and uucp

In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>It would be so nice if someone would undertake a security audit to
>insure that work other college students did, which *is* currently
>in production, doesn't contain any surprizes.

Being just an ignorant graduate student myself, I can't figure out
whether this implies that all college students are suspect, anyone who
is not in college is not suspect, or both?  Perhaps John F. Haugh II
could clarify this for me?

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 22:21:26 GMT
From:      unmvax!turing.unm.edu!mike@ucbvax.Berkeley.EDU  (Michael I. Bushnell)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
In article <44440@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:
>In article <1242@ucsd.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) writes:
>> I'm not presuming they were ignored.  *Many* people have been aware of this
>> particular sendmail bug.  That was not the purpose of the article.  The fact
>> is, that bugs happen.  This was a sendmail & finger bug.  Before, it was
>> an ftp bug (and a cute one that was).  Before that, ...

>I have not been able to find ONE person who claims to
>have known that sendmail compiled with DEBUG on would have allowed
>anyone with SMTP access to run an arbitrary program on their machine.

>The fact that you can run an arbitrary program is such an obvious
>security hole that I can't believe anyone wouldn't report it if they knew.

>So, name 5 of these many people and I'll drop the issue. (I WILL ask
>them why they didn't think it was worth sending to Berkeley as a bug)


Here's one!  I noticed this about two months ago.  You see, I decided
to write some stuff to filter my incoming mail, and installed it as a
pipe in my .forward.  Worked great.  Then two questions occurred to
me: 1) What UID will my forwarder run as? and 2) What if the "|..."
syntax occured in a different context?  

Some experimentation yeilded answers to the second question: only if
it occurs as an alias or forwarding expansion (naive me...).  When
poking around the code looking for the answer to the first question, I
noticed where the cute error message occurs in the second case:

if (a->q_alias == NULL && !tTd(0,1) && !QueueRun && !ForceMail)
{
	usrerr("Cannot mail directly to programs");
	a->q_flags |= QDONTSEND;
}

Hmmm...that little tTd check looks at the debug level!  Knowing about
the SMTP DEBUG command, I checked it out, and indeed it worked.

I reported this to offsite "official" people...I was informed that
this bug was known, but not to tell anyone because of the danger of
someone using it for a virus.
Hmmm.....



                N u m q u a m   G l o r i a   D e o 

       \                Michael I. Bushnell
        \               HASA - "A" division
        /\              mike@turing.unm.edu
       /  \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 22:39:22 GMT
From:      ncoverby@ndsuvax.UUCP (Glen Overby)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Crackers and Worms


In article <1727@cadre.dsl.PITTSBURGH.EDU> sean@cadre.dsl.pittsburgh.edu (Sean McLinden) writes:
>It is clear from Rick Adams' comments that 'not wanting to tip anyone off'
>is no excuse. Even binary-only sites can be protected fairly rapidly if
>the appropriate channels are used.

This sort of thing has been a pretty big issue lately, so I thought I'd chip
in a few comments.  If information about bugs (or, should I say,
"misfeatures") in Unix (or really any OS) should not be publicly disclosed to
protect those who either do not or can not repair them, then HOW should
such "classified" information be distributed to those who want/need it, and
can and will fix the holes?

Not but a few weeks ago there was a "discussion" on one of the news.* groups
about the Security mailing list (there are two of them, but thats irrevalent
here) which is restricted to "trusted" people (those who are "root" on a
"major machine" -- whatever that means).  Now, if information about security
bugs is too risky for distribution among that elite group of "system gods",
then should that information be exchanged over network mail systems at all?
(e.g. to 4bsd-bugs@ucbvax).

I think all of this sort of information should be distributed at least over
the private security forum; Vendor releases just aren't frequent enough to
fix these problems in a timely manner.

Glen Overby
ncoverby@plains.nodak.edu       uunet!ndsuvax!ncoverby
ncoverby@ndsuvax (Bitnet)

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 23:02:46 GMT
From:      ncoverby@ndsuvax.UUCP (Glen Overby)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: rtm and uucp


In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US
        (John F. Haugh II) writes:
>It would be so nice if someone would undertake a security audit to
>insure that work other college students did, which *is* currently
>in production, doesn't contain any surprizes.

Why are you worried only about college students?  We're not the only ones
in this world to commit crimes.

This security audit should go for any software posted to the net or
otherwise available (anon uucp, anon FTP, etc), as well as on a per-vendor
basis (who's to say that ABC computer maker didn't botch something in their
port?).

What you're prescribing is a pretty major task.  I'm sure that if anybody
with Unix Sources is sufficently worried about contamination they will
perform some sort of "audit" and report the bugs back to the Keeper of the
Sorces.

Glen Overby
ncoverby@plains.nodak.edu       uunet!ndsuvax!ncoverby
ncoverby@ndsuvax (Bitnet)

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 23:08:42 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

I've been thinking a lot about that question; tentatively, I don't see how
most ``secure'' machines would have escaped.  Consider, for example, a
B1-level UNIX system -- there are several, such as System V/MLS, undergoing
certification.  What would be accomplished by equipping such a system with
a TCP/IP that adhered to the Trusted Network Interpretation of the Orange
Book?

B1 provides two notable capabilities:  extensive logging, and ``mandatory
access controls''.  The logging might have helped trace the bug, or may
have helped alert system administrators, but obviously wouldn't have blocked
it.  What about the access controls?  Would they have helped?  Probably not,
except in a minor way.

Mandatory access controls prevent a process from reading a file ``more
classified'' than the process's label, or writing to a file less classified
(in order to prevent leakage of classified information).  For the most
part, no such information was used by the worm.  It couldn't have gotten
at hashed passwords -- they're in a shadow file, not /etc/passwd -- nor,
most likely, could it have looked at .rhosts files or .forward files.
But the major means of transmission were the fingerd bug and the sendmail
bug, and unless /etc/hosts were marked classified -- not likely, unless
you want to say that only classified applications can talk over the net! --
attempts to exploit those bugs would not have been affected.

The IP security option(s) can carry classification labelling information.
A process can only talk to a peer at the same level.  If fingerd or
sendmail were eligible to run at the unclassified level, the worm could
have infiltrated itself via those channels.  To be sure, the worm
executable would only have access to unclassified channels -- but that's
all it needs to spread further.  Fundamentally, what we had was a denial
of service attack, which is very difficult to guard against.

The heart of any secure system is a small, simple, ``security kernel''.
*All* access decisions must be made in this kernel; with luck, it's small
enough, and simple enough, that one can have reasonable confidence in
its correctness.  The danger points are in the other ``trusted programs'' --
programs (like mailers) that of necessity must cross security boundaries
of some sort.  But this worm didn't use any trusted programs, nor did
it call the security kernel.  Rather, it exploited bugs -- which we
can't eliminate -- in two network applications, and then behaved as
an ordinary user process.  The TNI would (assuming correct implementation)
have kept the worm out of the classified areas of the system, but would
not have kept the system functional.  (I don't accept the argument that
the sendmail bug was known, and that fingered wouldn't be run by a secure
system.  True but irrelevant -- the real lesson here is that a competent
and determined individual can find bugs; the exact location of these
particular ones is mostly irrelevant.  Remember that this worm did not
use root privileges; as such, arguments about the inherent insecurity
of the UNIX system are not germane.)

I keep looking for a system model that would have blocked this sort of
attack.  Except for some sort of ``fairness scheduler'' -- one that would
have kept any one user, such as daemon or nobody from chewing up the
whole CPU -- I don't see one.  I'd like to, though.

		--Steve Bellovin

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 23:24:04 GMT
From:      elsie!ado@cvl.umd.edu  (Arthur David Olson)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Crackers and Worms
> I'll bet the KGB are laughing their asses off.

That depends on whether kremvax was running 4.3BSD or Ultrix.
-- 
Ultrix is a trademark of Digital Equipment Corporation.
KGB is a trademark of the like-named San Diego radio station.
-- 
	Arthur David Olson    ado@ncifcrf.gov    ADO is an Ampex trademark.
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 23:39:38 GMT
From:      hbo@sbphy.ucsb.edu (Howard B. Owen)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: "Morris did it"--the new excuse?

In article <16915@agate.BERKELEY.EDU>, weemba@garnet.berkeley.edu 
(Obnoxious Math Grad Student) writes...

>   ...             I've never worked assuming that the machines I use
>are 100% reliable.  Do the scientists/researchers at your site do so--
>even on critical stuff?   ...

   Scientists at my site know that computers and networks go up and down. 
Nevertheless, they tend to depend on both to get their work done. One group
here does a lot of montecarlo type work. They use Cray time at SDSC. If the
internet link is down, their work stops. Without supercomputers, and the
high speed networks to connect them, a lot of physics research simply wouldn't
happen. It doesn't matter that computers aren't 100% reliable; they are the only
tool for the job.

   While I agree with the idea that tool reliability should be carefully
considered when undertaking a job, I don't think failure to do so contributed
greatly to the damage done by the recent unpleasantness. The blame for lost
computer time and disrupted research lies not with unreasonable expectations
on the part of users, but with the originator of the worm.

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 88 23:48:50 GMT
From:      ucsbcsl!comdesign!canary!pst@ucbvax.Berkeley.EDU  (Paul Traina)
To:        tcp-ip@sri-nic.arpa
Subject:   The Internet Worm & the NRA
The ultimate method of stopping further worm attempts:

	remove ld from the system

Ummm.. does this mean the ACM will start some defense (just like the NRA):

	"Make owning a copy of ld a criminal offsense, and only criminals
	 will own ld."

With respect to the NRA :-)

------
Paul Traina				To believe that what is true for
{uunet|pyramid}!comdesign!pst		you in your private heart is true
pst@cdi.com				for all men, that is genius.
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 02:00:38 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip,comp.unix.wizards,news.sysadmin
Subject:   RTFM!  (Morris Tech Report)

i think Mr. Ritchie may be on to another meaning for the
often ignored acronym about The F-ing Manual.

i wonder...  since this report is free of charge...  would it be 
appropriate for someone to post it to this mailing list?  

then we could all RTF(RTM)M without inundating the ATT documents
person with hundreds of requests...

In article <8419@alice.UUCP> dmr@alice.UUCP writes:
>Those interested in earlier works of Robert T. Morris,
>or interested in network security in general, might wish
>to read AT&T Bell Laboratories CSTR #117, "A Weakness in the
>4.2BSD Unix TCP/IP Software," by Robert T. Morris,
>dated Feb. 25, 1985 ...... These reports are free of charge.
>
>			Dennis Ritchie
>			research!dmr
>			dmr@research.att.com


-- 

 
  	harvard!spdcc!eli

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 02:12:39 GMT
From:      dheap@gara.une.oz ( PSYS)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   A new risk ? (Was Re: Morris, the law, and his state of mind)

In article <1570@valhalla.ee.rochester.edu> deke@valhalla.ee.rochester.edu (Dikran Kassabian) writes:
>
>The medical center/teaching hospital at my university is also network
>connected.  What if the network overload caused patient monitoring systems
>there to be sluggish and inadequate?

	Do you really mean that you have critical patient monitoring systems
running on a user accessible system, subject to clogging & vagaries from
other users, apart from net viruses? I hope you have made a mistake with
this statement, or else it's a first class candidate for comp.risks



-- 
Dave Heap              	         ACSNET: dheap@gara.une.oz                  
Psychology Department,           UUCP: ...!uunet!munnari!gara.une.oz!dheap  
University of New England,       ARPA: dheap%gara.une.oz@uunet.uu.net       
Armidale NSW 2351, Australia   

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Nov 88  9:26:39 MST
From:      Robert Butler <rbutler@yuma-emh1.army.mil>
To:        tcp-ip@sri-nic.arpa
Cc:        rbutler@yuma-emh1.army.mil
Subject:   Virus, Worm or?




The amount of email coming out on this list is very encouraging. More
`listeners' than ever are sticking their opinions out for possible ridicule or
even agreement.
What I'm hearing is a lot of protectionism for a  programmer. Like we need more
of his quality to keep the paranoid security wraps on this middle-aged
Internet. 
Does anyone think `wormer' will get his hands slapped, providing the 
allegations are true?. Regardless of his/her intent there were over six
thousand computers infected and many sub-networks were shut-down just because 
the infection was loose.
The cost to Internet alone will be in the millions of dollars figure (all those
leased lines). Then add in all the lost computer time for another hundreds of 
millions of dollars figure.
Whew, the national debt appears to be shrinking next to `the mistake' whether
intended or not. 
We do not have enough money now without having to pay the tab on this fiasco.
What will this do to the budget deficit we are living with?.
Now what?. Did we learn enough to pay for (non-budgeted) expended dollars?.
My opinion is NO, because I'm smart enough to know that I could lose my ability
to make a living by pulling such a trick, And I do not have a relative in high
Government that would bail me out. 
What ever happend to "Integrity"?. I have a personal integrity that will not
allow me to do what was done. I do believe that I know right from wrong and I 
will not do wrong, by conscious choice. Simplistic hey!.
Integrity! what does it mean in todays society. Well, what I'm hearing is: if
he/she is brilliant, nice, easy going, helpful and just accidently costs me
a years salary, lets just slap their hand, especially if their father is the 
judge. Lets not get angry and exact retribution, really they will learn their 
lesson and do it again. I'm not willing to pay the bill, dammit.
What would a drug dealer do if someone cost him several hundreds of dollars, 
intended or accidentally?. I guarantee that he will make an example for others
that that is not acceptable behavior. Is this the type of mentality or
attitude that we want?.           
Nuff said. I have my fire suit on.

These are my opinions and do not reflect on anyone except ME. RBB
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Nov 88 11:43:26 -0500
From:      "Alan R. Hill" <ahill@CC5.BBN.COM>
To:        Dennis Perry <perry@KAUAI.MCL.UNISYS.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: passwords
Dennis,
	Bravo! If adminstrators follow your advice the network systems
will be 1000 times harder to penetrate.  At least they will have done
the minimum required effort to protect their systems.  Security generally
requires one's best effort to prevent and detect.  It amazes me that we
have to have yearly events of this type to convince people that the
systems need improvement.  I have known about the security holes in Unix
for almost ten years.

Regards,
Alan
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 11:37:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Email server alternative
Perhaps my previous note was a bit too brief.  Its intent was to inform
the community of a mail transport system, for Unix, which was built with
considerable attention to issues of management (scaling and analysis) and
security.  I don't know enough details about sendmail to engage in a
comparison, so the comments are only about MMDF.  (For that matter, I
have not dealt with the MMDF code in detail since I left UDel in '82, so
there may be features added that I have not heard of.)

The system operates off of a single queue, with a "view" of sub-sets, using
sub-directories, for different destination networks/channels.  This gives
very good scaling as the queue grows.

Mail is added to the queue through a submission process which interacts with
the user's interactive agent.  The user agent runs under the user's id.  The
submission process runs under MMDF's separate id.  Most other MMDF processes
run under this un-privilged id.  The local delivery channel starts as
superuser, of course, but it does a setuid to the receiver as soon as it
can.  In particular, any receiver-controlled programs, such as one which
does automatic replies when you are away from the office, run under the
id of that recipient, rather than of MMDF.

During submission, messages are inspected for conformance to various rules,
such as having an authentic From or Sender field.  This can be overridden,
by "relay" accounts, in which case the mail is assumed to be coming from
another machine and to have gone through authentication, already, or else
the message is considered to be anonymous and a header message is attached,
indicating that From/Sender are not authenticated.

(On another list, there was a question about the legality of inspecting
headers -- i.e., reaching inside the envelope -- and there was fear that
this violated an RFC.  It does not, and it is done as part of the enforcement
policy that MMDF was designed to support.)

Dave

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 05:03:00 GMT
From:      TomZ@DDN1.ARPA
To:        comp.protocols.tcp-ip
Subject:   FBI Contact re: November Internet Virus


         Were YOU hit by the November Internet Virus?
 
                      The FBI wants to hear from you!
 
The Federal Bureau of Investigation is attempting to gather critical
information necessary to pursue this case under the Computer Fraud and
Abuse Act of 1986.  (This is the statute that makes it a federal crime
to penetrate a computer owned by or run on the behalf of the Government.)
 
The FBI Case Agent has asked the Defense Data Network Project Management
Office to collect the names of organizations and Points of Contact (names
and phone numbers) that were hit by the Virus.  The Defense Communications
Agency has established an E-Mail address for this collection at:
 
                       INFO-VACC [at] BEAST.DDN.MIL
 
    Points of Contact should expect to be contacted by their local FBI
    agents for dispositions due to the wide geographical area involved.
 
 
                     I * M * P * O * R * T * A * N * T
 
            The FBI needs this information to pursue the case.
 
      If we expect their aid in the future, we need to help them now.
 
PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!
 
/s/
Tom Zmudzinski
DDN Security Officer
(703) 285-5206

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Nov 88 11:08:37 EST
From:      Mike Muuss <mike@BRL.MIL>
To:        Chris Torek <chris@gyre.umd.edu>
Cc:        auspex!guy@uunet.uu.net, tcp-ip@sri-nic.arpa
Subject:   Re:  Unix 8-character passwords
What Chris says is true.  However, the present algorithm uses the
8-byte password as the key to encrypt a known plaintext string.
The algorithm could be easily modified to encrypt, say, the 2nd
8 bytes of the password string (when provided) as the plaintext string.

This would at least provide something for those extra characters to
be used for, without requiring additional bytes to hold the encrypted
passwords (which I doubt is much of an issue anyway).
	Best,
	 -Mike

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Nov 88 11:28:24 EST
From:      Mike Muuss <mike@BRL.MIL>
To:        Harry Saal <hjs@lindy.stanford.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Does anyone have packet traces taken during Viral spread phase?
I don't have packet traces, but I do have some behavior logs as we
monitored a caught Virus in our "test cell" (a VAX running a specially
instrumented kernel).  This shows all attempted network connections,
etc, and is pretty interesting.

From my inspection of the source code, I am convinced that it is
unlikely that network traffic monitoring would have shown much.
Each infection uses at most a few hundred packets, and distinguishing
that sort of load from regular E-mail traffic could be quite tough.
Only for machines with very low average presented network load would
the virus have made much of a difference.

The virus had enough synchronization delays (sleep(5), etc) in it
that even if it was having particularly good luck busting into machines,
the network loads would not have been outrageous.

The place to look here is not in the network, but within each host.
Each host must defend itself at the host/network boundary, and expect
no defensive measures from the network.

	Best,
	 -Mike
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 08:08:49 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages

In article <19432.595013634@paris.ics.uci.edu> raj@PARIS.ICS.UCI.EDU writes:
[Suggests requiring that the source port of an SMTP connection be <512.]
>Well, what's wrong this idea?  I figure there has to be something wrong with
>it or else it would have been suggested long ago.

There's nothing in the TCP spec that says that low-numbered ports are
"privileged".  While this is true on many systems, it is not true on
all, and there's no way that it could be made so.  What about TCP
implementations on personal computers?  You can't even depend on the
source address in the IP header to be correct, and you want to base a
security feature on the port number?

The mechanism you describe is used in Berkeley Unix's rsh and rlogin
protocols.  However, it is only permitted between consenting machines.
The server machine has a list of machines that it believes implements
this level of security.  If you come from a different machine, it
ignores the fact that you are coming from a low-numbered port.  (This
still isn't completely secure, since it ignores the fact that some
systems will allow the user to fake the source IP address, thus
pretending to be coming from a trusted machine; unfortunately, it's
difficult to do better than this.)

This is why this mechanism is not really useful in the general case.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 09:11:18 GMT
From:      gwyn@smoke.BRL.MIL (Doug Gwyn )
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Morris Tech Report

In article <8419@alice.UUCP> dmr@alice.UUCP writes:
>Those interested in earlier works of Robert T. Morris,
>or interested in network security in general, might wish
>to read AT&T Bell Laboratories CSTR #117, "A Weakness in the
>4.2BSD Unix TCP/IP Software," by Robert T. Morris,
>dated Feb. 25, 1985.  ...

I also recommend this CSTR.  By the way, I don't know why the CSTRs
are still being made available for free but I'm thankful that they
are.  Many of them are very good, and they offer one of the few ways
of obtaining some insight into what the Bell Labs computer scientists
are up to.

Our local Internet gurus tell me that the spoofing weakness
described in that CSTR is currently harder to exploit, but not
impossible.  Also an Ethernet seems to be rife with possibilities..

If things get bad enough we may have to resort to end-to-end
encryption all the time.  What a drag.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 14:31:08 GMT
From:      weemba@garnet.berkeley.edu (Obnoxious Math Grad Student)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: "Morris did it"--the new excuse?

In article <978@hub.ucsb.edu>, hbo@sbphy (Howard B. Owen) writes:
>   Scientists at my site know that computers and networks go up and
>down.  Nevertheless, they tend to depend on both to get their work
>done. One group here does a lot of montecarlo type work. They use Cray
>time at SDSC. If the internet link is down, their work stops.

So the work stops.  Is this something that happens once every four
years?  No.  So I don't understand why you bring this up.

>							       Without
>supercomputers, and the high speed networks to connect them, a lot of
>physics research simply wouldn't happen. It doesn't matter that
>computers aren't 100% reliable; they are the only tool for the job.

Again, what's your point?

>   While I agree with the idea that tool reliability should be
>carefully considered when undertaking a job, I don't think failure to
>do so contributed greatly to the damage done by the recent
>unpleasantness. The blame for lost computer time and disrupted research
>lies not with unreasonable expectations on the part of users, but with
>the originator of the worm.

Again, what's your point?  From the user's point of view, it's always
one reason or another why the computers/networks are not available a
certain XX% of the time.  Every time they go down, do your users hunt
around for "whom" to blame?

ucbvax!garnet!weemba	Matthew P Wiener/Brahms Gang/Berkeley CA 94720

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 14:50:22 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages

In article <19432.595013634@paris.ics.uci.edu>, raj@PARIS.ICS.UCI.EDU writes:
> ...  It seems to me as if we could solve this whole
> problem once and for all by simply requiring the originating port for SMTP
> deliveries to be a privileged port ( < 512 )....
 
> Well, what's wrong this idea?  I figure there has to be something wrong with
> it or else it would have been suggested long ago.

According to the spec, there's no such thing as a privileged or reserved
port.  Berkeley has one, but (contrary to appearances) they do not define
TCP/IP...

More seriously, even if there were privileged ports defined, it still
does nothing against someone with a PC, for which the very concept of
trusting anything doesn't make sense.  If you're really concerned about
mail-spoofing, the only real answer is to use some sort of digital
signature or end-to-end encryption.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 16:06:42 GMT
From:      thomas@uplog.se (Thomas Hameenaho)
To:        comp.protocols.tcp-ip
Subject:   Re: Trailer implementation techniques

In article <31039@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
>That is the crux of my question.  How do you copy the header to the
>beginning of the packet without moving the data to make room?

(cons header packet)	:-)

The mbuf strategy is actually something along that line.
-- 
Real life:	Thomas Hameenaho		Email:	thomas@uplog.{se,uucp}
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 16:26:39 GMT
From:      rbutler@YUMA-EMH1.ARMY.MIL (Robert Butler)
To:        comp.protocols.tcp-ip
Subject:   Virus, Worm or?





The amount of email coming out on this list is very encouraging. More
`listeners' than ever are sticking their opinions out for possible ridicule or
even agreement.
What I'm hearing is a lot of protectionism for a  programmer. Like we need more
of his quality to keep the paranoid security wraps on this middle-aged
Internet. 
Does anyone think `wormer' will get his hands slapped, providing the 
allegations are true?. Regardless of his/her intent there were over six
thousand computers infected and many sub-networks were shut-down just because 
the infection was loose.
The cost to Internet alone will be in the millions of dollars figure (all those
leased lines). Then add in all the lost computer time for another hundreds of 
millions of dollars figure.
Whew, the national debt appears to be shrinking next to `the mistake' whether
intended or not. 
We do not have enough money now without having to pay the tab on this fiasco.
What will this do to the budget deficit we are living with?.
Now what?. Did we learn enough to pay for (non-budgeted) expended dollars?.
My opinion is NO, because I'm smart enough to know that I could lose my ability
to make a living by pulling such a trick, And I do not have a relative in high
Government that would bail me out. 
What ever happend to "Integrity"?. I have a personal integrity that will not
allow me to do what was done. I do believe that I know right from wrong and I 
will not do wrong, by conscious choice. Simplistic hey!.
Integrity! what does it mean in todays society. Well, what I'm hearing is: if
he/she is brilliant, nice, easy going, helpful and just accidently costs me
a years salary, lets just slap their hand, especially if their father is the 
judge. Lets not get angry and exact retribution, really they will learn their 
lesson and do it again. I'm not willing to pay the bill, dammit.
What would a drug dealer do if someone cost him several hundreds of dollars, 
intended or accidentally?. I guarantee that he will make an example for others
that that is not acceptable behavior. Is this the type of mentality or
attitude that we want?.           
Nuff said. I have my fire suit on.

These are my opinions and do not reflect on anyone except ME. RBB

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 16:27:39 GMT
From:      jon@ATHENA.MIT.EDU (Jon Rochlis)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages


Privileged ports are a concept whose time has come and (hopefully)
gone.  So has the idea that mail from "root" means you are a system
administrator.  For example, MIT's Project Athena publishes the public
workstation root password in a piece of introductory documentation.
Nothing in the system relies on "root" being trusted.

If you want secure mail, take a look at RFC 1040, "Privacy Enhancement
for Internet Electronic Mail: Part I: Message Encipherment and
Authentication Procedures" by J. Linn.

		-- Jon

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 16:38:10 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords


>  I stongly encourage everyone to use such a password generator
>  and not allow people to generate their own passwords.

Password generators may be ok, but the paswords they generate suffer
from a dreadful sameness, and when you're trying to maintain accounts on
a dozen or more machines without writing anything down...

I strongly urge system administrators to publicize **and enforce**
their rules for choosing passwords, and let folks pick their own.

-s

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 16:43:26 GMT
From:      ahill@CC5.BBN.COM ("Alan R. Hill")
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

Dennis,
	Bravo! If adminstrators follow your advice the network systems
will be 1000 times harder to penetrate.  At least they will have done
the minimum required effort to protect their systems.  Security generally
requires one's best effort to prevent and detect.  It amazes me that we
have to have yearly events of this type to convince people that the
systems need improvement.  I have known about the security holes in Unix
for almost ten years.

Regards,
Alan

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 16:50:51 GMT
From:      tencati%jplgp.span@VLSI.JPL.NASA.GOV
To:        comp.protocols.tcp-ip
Subject:   RE: Re: And You Thought You Were Paranoid...

A "Benevolent Worm"?

Cheers,

Ron Tencati
/JPL

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 17:03:43 GMT
From:      jbn@glacier.STANFORD.EDU (John B. Nagle)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Security mailing list


      I suggest that the security mailing list be posted to a newsgroup,
but with a 60-day delay.  Sites and vendors serious about security will either
have fixed any problem by that time, or they probably aren't going to fix it
at all.  This insures that a false sense of security is not engendered among
system administrators, yet allows a reasonable time for closing newly discovered
problems.
      General knowledge of that 60-day timer will tend to accelerate efforts
by vendors to fix problems, I would suspect.

      Why 60 days?  A monthly update service would be enough to keep systems
operating with the latest security fixes.  30 days would require biweekly
updates to stay current, which is a bit frequent.  Much longer than 60 days,
and the pressure would be off on fixing holes.

					John Nagle

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 17:09:20 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix 8-character passwords

Chris Torek writes:
> ...  It is therefore obvious that there are no passwords
>that cannot be specified in at most eight characters, and any more are
>theoretically superfluous.   ...   Nonetheless, there are some ASCII
>characters that are inordinately difficult to type ...

CR, LF, and the line oriented input editing characters come to mind as
characters that are difficult to include in passwords.
 -WBE

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 17:09:40 GMT
From:      thomas@uplog.se (Thomas Hameenaho)
To:        comp.protocols.tcp-ip
Subject:   Ethernet controllers

We are about to start the design of a fast VME based Ethernet board
(who aren't?), now I wonder what experience people have with the different
Ethernet controllers.

The chips we've been considering is the AMD 7990, i80586 and the Seeq 8003.
Any useable one missed?

The board will have a 68020 and 32 bit wide memory and will be optimized
for speed.

7990:
    Advantages:
	Builtin DMA.
	Can handle the byte-sex of a 68K.
	Fast, can according to AMD use down to 4.1 usec interpacket gap time.
	Lots of implementations using it.

    Disadvantages:
	In-flexible DMA.
	Lousy bus timing, must be isolated from the processor bus.
	16 bits interface.

i80586:
    Advantages:
	?

    Disadvantages:
	Slow (rumors)
	Wrong byte-sex.

8003:
    Advantages:
	No built in DMA. Allows flexible external solutions tailored
		to mbuf like strategies.
	No byte-sex problems.
	Reasonable bus timing.
	Simple.

    Disadvantages:
	Not very used.
	No time-domain-reflectometer
	Simple.

Please E-mail responses to me. I'll summarize if there's any interest
-- 
Real life:	Thomas Hameenaho		Email:	thomas@uplog.{se,uucp}
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 17:13:21 GMT
From:      m5@lynx.UUCP (Mike McNally)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: rtm and uucp

In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>It would be so nice if someone would undertake a security audit to
>insure that work other college students did, which *is* currently
>in production, doesn't contain any surprizes.

Doesn't seem to me that a diploma forms some sort of delineation between 
wickedness and honesty.  Any company that cares about security but only
with respect to those parts of its software that were written by ``college
students'' doesn't deserve serious consideration.  Surely, the majority of
electronic crimes are committed by employees of the victims.

-- 
Mike McNally                                    Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5                    phone: 408 370 2233

            Where equal mind and contest equal, go.

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 17:26:29 GMT
From:      mbt@bridge2.3Com.Com (Brad Turner)
To:        comp.unix.wizards,comp.protocols.tcp-ip,news.sysadmin
Subject:   Re: rtm and uucp

In article <1777@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes:
>
>In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US
>        (John F. Haugh II) writes:
>>It would be so nice if someone would undertake a security audit to
>>insure that work other college students did, which *is* currently
>>in production, doesn't contain any surprizes.
>
>This security audit should go for any software posted to the net or
>otherwise available (anon uucp, anon FTP, etc), as well as on a per-vendor
>basis (who's to say that ABC computer maker didn't botch something in their
>port?).
>
>Glen Overby
>ncoverby@plains.nodak.edu       uunet!ndsuvax!ncoverby
>ncoverby@ndsuvax (Bitnet)

(out of context of course and maybe not 100% exact)
Frank Burns: I wouldn't be so paranoid if everybody wasn't watching me

Let's all put on our paronia pants and do the little "somebody is out to
to get me" dance!

I'm not suggesting that security should be ignored, or that code should
never be looked at after the first successful compile. It's just that I
hate to see everybody join a posse/lynch mob because of ONE (not several,
ONE) incident.  So....

Face it unless you are willing to personally inspect every piece of source
for every executable that's on your machine you're potentially compromising
the security of your system. It's no good to "audit" the code, because how
to you know the auditors can be trusted? Couldn't one dishonest auditor do
more harm then than anybody else. Think about it, one central group in
charge declaring what is and is not fit. A single point of failure!

What it comes down to is the fact that systems these days are far to
complicated for a single person to deal with. You have to trust your
fellow human being at some point in time, otherwise everybody will be
doomed to re-inventing the wheel. Do you personally have the time and expertise
to code a boot load PROM? Then go from there to a monitor program to an
assembley to a compiler to....vmunix...>rest-of-unix<....ad nausem. Then
if you really want to get paranoid, how about the hardware? You're going
to have to design your own CPU, mask it yourself, produce it yourself.
Don't forget the glue logic, make your own 74xxx chips, resistors, caps
etc... Where does it stop???? I give up lets disband society and all go
live in woods where only the wildlife can get ya'.

While I'm on my soapbox (and guilty)...Is it possible that we (the computing
community) have wasted more time discussing/arguing about the worm than
we spent discovering/disecting/erradicating/patching? My personal view
I that the gossip fence has gotten overcrowded and we need to let the 
issue die and quit wasting net bandwidth rehashing every different
flavor of the same argument/issue.

Thanks for your time, have an OK day, and DON'T post a followup.

-brad-
-- 
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner	1330 Ashleybrook Ln.	(919) 768-2097	| I speak for myself
3Com Corp.	Winston-Salem, NC 27103 mbt@bridge2	| NOT for my employer.

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 18:01:06 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

Steve, actually the password generator can be tuned to give passwords
with different 'dialects'.  We used the generator at Los Alamos to
generate over 6000 passwords a year and I don't recall any of mine
being the same or even close.

One should note that if passwords are private, and not shared, the saem
passwords can be used by different people and they are just as secure.
This is similar to key for automobiles, there are only so many locks.
My key probable works in a 1000 different cars, or more, but I don't
know which ones.

But, you are correct if you need your own password on a dozen different
machines.   In those cases, I would use a generator to generate my
'key' and than make the locks all the same, or at least minimize the
number of keys I have to carry.  Again, I think that eventually hardware
smard cards are the answer to our lifestyle problems of too many keys.

dennis

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 18:05:29 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Morris bashers...


Well, let me throw in my opinion here.  With regards to the bugs
used by the virus, I, nor any of my friends at UCB knew about
them.  I don't believe anyone in the CSRG at UCB knew about them.
If we had, one of us would have seen to it that it would have been
fixed.  Just look at the number of security related patches that
UCB has put out on comp.bugs.ucb-fixes in the past year.  People
are serious about fixing bugs in 4.3, but UCB, and I doubt 
anyone else are out there, are auditing code.  

The CSRG releases a RESEARCH operating system called Berkeley
Unix.  It happens to be a very useful release, and many people
use it, but it is not a product.  There is no software
warranty, and it's fairly cheap.  So I don't have problems with
the CSRG about these bugs; they only do best effort work, and
they really don't even need to do that.  Where I do find a LOT
of problems is what the vendor community is doing here.  SUN and
DEC produce 'products' out of Berkeley Unix.  They charge real
money for these products.  Yet Sun for example had a serious
security bug in one of the network utilities that they knew
about for a year (I have the bug report number), and didn't 
issue a patch at all, but waited for 4.0 to fix the problem.
This is ridiculous.  DEC is just as bad.  It's the vendors
who have the responsibility for auditing the code they release.
Go scream at SUN for not finding the bug, not at Berkeley.

Further, you will always get less buggy code from the CSRG
than the vendor community.  Why is that?  The vendor
community normally tracks 4.3 pretty well, though lags
by an inordinate period of time often enough.  If SUN or DEC
finds a bug, they usually tell CSRG about it and
fix it.  CSRG then fixes it internally, and if appropriate,
shortly afterwards releases a bug fix over the network.  They
also get bug reports from others as well.  So CSRG typically
fixes bugs quickly.  SUN and DEC and company don't usually
issue patches; they wait for the next rev. of OS release.  
Further, often times the development people fix the bug in the 
code they are using, not in what the 'software manufacturing' 
group is distributing.  So they need to retrofit the fix.
What it boils down to is that 4.3 has the fixes out soon
after they know about it.  The vendors wait huge periods
of time unless some sort of crisis develops.  You see the
recent postings about ftpd bug fixes to comp.bugs.ucb-fixes?
Have SUN or DEC released patches yet?  Do you really think
that bug is only in 4.3?  The first thing I do when bringing
up a SUN release (I'd do the same thing if I had Vaxstations 
instead of SUNs) is throw away all the vendor distributed network
code and port the latest 4.3 utilities.  They work better 
in general and have fewer bugs (read security problems).
Also, this way I have source code, so when UCB issues a
bug fix, I can fix it in 5 minutes, as opposed to feverishly
beating on my vendor to give me a binary patch that 
probably hasn't even been produced in the company yet.
Folks, for security reasons alone, insist on source code!

Mike Padilipsky has a chapter in his book "Elements of Networking
Style" called "The Myth of Vendor Support".  It's good reading.
Anyone from SUN or DEC want to throw rocks at what I've said?
I'd love to be proven wrong!

Now, about Morris.  Firstly, we don't know if he's responsible
for this thing.  Unless someone has seen a confession, we really
don't know if he's the one yet.  He may well be, but it's
not absolutely clear yet.  But if he is the guy, then the FBI
MUST be able to sucessfully argue a felony case against him
and lock him up.  It makes no difference what his intentions
were or are.  If he did it, he needs to be made an example of.
People playing around occaisionally and attempting to crack
a system out of a sense of novelty is one thing, but something
as large and as well publicized as this virus requires action.
The Internet operates fairly freely, but always has this notion
of a heavy weight somewhere above that can drop on troublemakers
and squash them out of existance.  Otherwise what happens is
that you get a bunch of urchins attacking things all over
the place, and then you have to start restricting the
openess of the network, and thereby lessening it's utility.
So, when people cause this much trouble, they need to be 
vigorously prosecuted.  Fortunately, I believe the laws here
don't require proof of malice, only proof of damage.  And
I'm sure that the various government agencies involved 
spent a pile of money (in terms of people's time) to squash
this thing, so that shouldn't be hard to prove.

Some people are saying that since the virus wasn't intentionally
harmful, that all this fuss is really no big deal, and it should
be fixed, but is not that big of a deal.  As a person who
was fighting it fairly early on, I'd have to say that we didn't
know it wasn't harmful until we saw the decompiled code a few
days later.  When we were trying to purge our systems of
the thing, we had to assume worst case and that the thing
was harmful.  We had no reason to assume it wasn't.  So we
put in a lot of work to squash it.  It was the prudent thing
to do.

And lastly, let's not forget this was a computer problem, not
a network problem.  Sure the network facilited it's travel,
but not all computers on the net were affected.  As my boss
at NASA HQ said, you don't shut down the Interstate highway 
system just because some burgler traveled a freeway on the
way to robbing someone's house.  You beef up security at
the house, not close all the off-ramps.  If you are concerned
about security, make sure your systems are well administered
and managed.  That's the best thing you can do to avoid problems.

					Thanks,
					   Milo

PS All the usual disclaimers about this not being the opinion
of the US Government, Sterling Software, etc... apply here
of course...

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 18:13:34 GMT
From:      retrac@RICE.EDU (John Carter)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages


    In a message on tcp-ip, you proposed that requiring the originating port
for SMTP deliveries to be a privileged port (< 512) would solve "once and
for all" the problem of anonymous mail.  Unfortunately, making the
assumption that low numbered source ports are privileged is not a very good
idea (although Unix does it all over).  Many operating systems (including
the V system) don't have consider low numbered ports "privileged".  I can
trivially create a source port with whatever number I desire and connect to
your machine.  Also, standalone machines (say a PC) can also rather easily
create whatever port number you want.  Unix's assumption that low numbered
source ports for TCP connections are somehow `privileged' is not very safe.

John Carter
Rice University

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88   00:13 EST
From:      BACON%MTUS5.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP @ SRI-NIC.ARPA
Subject:   BITNET mail follows
=========================================================================
HELO MTUS5
MAIL FROM:<BACON@MTUS5>
RCPT TO:<tcp-ip@sri-nic.arpa>
DATA
Date: Tue, 15 Nov 88 00:12:57 EST
From: "Jeffery K. Bacon III" <BACON@MTUS5>
To:   tcp-ip@sri-nic.arpa
Subject: The Robert Morris Christmas Present

It doesn't matter much one way or the other whether someone knew about it
4 years ago, really. Obviously no one thought it to be terribly important
back then, now did they? Of course, everyone does now...And of course now
everyone panicked. That's human nature for ya. We had our SMTP server
shut down entirely -- and we're an IBM site that isn't even listed in
the HOSTS.TXT file yet, fer gosh sakes. Obviously, sometimes the hype
surrounding something is worse than the bug itself.

Think about it this way: You're thinking about security now, aren't you?
I'll bet about 3 months ago you figured you were pretty safe, and not
even worried about it?

Every once in a while, people/institutions need a good kick in the pants
to wake them up to the real world. <faint hint of silver lining on cloud>

Jeffery K. Bacon
Academic Computing Services, Michigan Technological University
bitnet:  bacon@mtus5  |  UUCP:  [rutgers ihnp4 uunet]!umix!anet!bacos
"These opinions are my own; no one else would want them."
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 19:26:30 GMT
From:      jon@ATHENA.MIT.EDU (Jon Rochlis)
To:        comp.protocols.tcp-ip
Subject:   re: Does anyone have packet traces taken during Viral spread phase?


   I would be very interested in receiving any network packet traces taken
   while the recent worm hopped about and (re)infected multiple machines
   connected by LAN connections/routers.

The folks at the MIT Lab for Computer Science had at least an RA81 of
packet headers from one subnet at MIT for Wednesday morning.  We
looked at one point on Friday morning (before we realized the ernie
could wouldn't work) for packets to/from ernie, but found nothing
(which is no longer suprising).

  We would like to see to what
  degree the externally visible network traffic stood out from the 
  "normal" traffic.  The goal would be to be able to provide earlier warnings
  of anomalous behaviour than having a system choke itself to death, and then
  try to take action.  For example, I am interested in any observations
  as to whether average activity took a nose dive (as other processes clogged
   up) or increased (due to the agressive attempts to spread itself).

I have to agree with Mike Muss (among others) who noted at the NCSC
meeting that you're not going to find anything.  The network traffic
generated by this virus was so small as to not be noticeable.  Perhaps
you'll find that infected machines were slow in responding to normal
queries and that might have a effect on traffic levels, but so many
machines were not touched that I doubt it.  And then again, many of
the numbers would be skewed by the numerous shutdowns that occurred.

		-- Jon

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 19:37:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Email server alternative

Perhaps my previous note was a bit too brief.  Its intent was to inform
the community of a mail transport system, for Unix, which was built with
considerable attention to issues of management (scaling and analysis) and
security.  I don't know enough details about sendmail to engage in a
comparison, so the comments are only about MMDF.  (For that matter, I
have not dealt with the MMDF code in detail since I left UDel in '82, so
there may be features added that I have not heard of.)

The system operates off of a single queue, with a "view" of sub-sets, using
sub-directories, for different destination networks/channels.  This gives
very good scaling as the queue grows.

Mail is added to the queue through a submission process which interacts with
the user's interactive agent.  The user agent runs under the user's id.  The
submission process runs under MMDF's separate id.  Most other MMDF processes
run under this un-privilged id.  The local delivery channel starts as
superuser, of course, but it does a setuid to the receiver as soon as it
can.  In particular, any receiver-controlled programs, such as one which
does automatic replies when you are away from the office, run under the
id of that recipient, rather than of MMDF.

During submission, messages are inspected for conformance to various rules,
such as having an authentic From or Sender field.  This can be overridden,
by "relay" accounts, in which case the mail is assumed to be coming from
another machine and to have gone through authentication, already, or else
the message is considered to be anonymous and a header message is attached,
indicating that From/Sender are not authenticated.

(On another list, there was a question about the legality of inspecting
headers -- i.e., reaching inside the envelope -- and there was fear that
this violated an RFC.  It does not, and it is done as part of the enforcement
policy that MMDF was designed to support.)

Dave

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 20:05:36 GMT
From:      robert@SPAM.ISTC.SRI.COM (Robert Allen)
To:        comp.protocols.tcp-ip
Subject:   Re:  "Morris did it"--the new excuse?


	
	>Scientists and researchers at a university like mine were unable to use
	>their computers and network links during the virus attack, and lost
	>valuable time.  As always, some were up against deadlines and may well
	>be hindered now in their chances for getting results before a confer-
	>ence, or in getting a grant proposal out before deadlines.
	
	When I've taught courses that use computers, I told students that under
	almost all circumstances, computer downtime would not be an excuse for
	lateness.  The one exception I've ever made involved granting everyone
	a week's extension.  I've never worked assuming that the machines I use
	are 100% reliable.  Do the scientists/researchers at your site do so--
	even on critical stuff?  If someone has a grant proposal riding on get-
	ting something done by a certain deadline, what happens if there's a
	major disk crash at your site?

    I would expect, and have in fact seen, professors give extensions in those
    cases where the loss of computing facilites CLEARLY had an unrecovereable
    impact on exams/assignments.  In most cases the loss of facilites was not
    CLEARLY to blame, since people often wait until the last minute before
    starting to work.  This is seldom the case with proposals or contracts
    deadlines (in my experience).

	>This is serious business!
	
	Yes this is *all* serious business.  Computers used primarily for USENET
	or hack or what-not can be dead for awhile and merely inconvenience lots
	of people.  But now you cite computers where users cannot afford to have
	computers to be down for long--do the sites that run them without having
	any contingency plans whatsoever?  Such sites are irresponsible.

    My site is rather well equipped with computing facilites.  Most every person
    has a Sun on their desk, and we also have several VAXen.  Even with this
    plethora of equipment, we were UNABLE to continue work for about 2 days
    when the virus hit.  If a group that has adequate facilies cannot survive
    such an outage, then certainly places such as Universities, which usually
    have inadequate quantities of computers, will be very hard hit by such a
    virus as we are discussing.  Short of maintaining a seperate hardware fall-
    back, it is my contention that it is IMPOSSIBLE to have a contingency plan
    other than what was used across the U.S., namely, lots of late night work
    by system staff people who were trying to second guess the designer of the
    virus/worm.

    I have not posted anything about the virus since others were posting plenty.
    Just this once however I'll make my opinion known.

    The designer of the virus clearly intended for it to secretly infiltrate
    other computers, and sit there, using up a quantity of CPU and memory.
    The design of the code that implemented the infecting agent was designed
    to prevent anyone from deducing what the process was doing.  Although
    the virus did crash a few systems from swap space problems, it apparently
    (as far as we know) did nothing overtly malicious.  The reason the virus
    was so damaging, was that the perpetrator DIDN'T TELL ANYONE what it was
    doing.  For that reason we had to keep our systems down until we determined,
    as best we were able, that no trojan horses had been planted.

    If the perpetrator had "gone public" with the code, the fix, or even an
    overview of what the virus DIDN'T do, then perhaps people would be more
    willing to cut the guy some slack.

    I've known more than a few people who broke UNIX security at one time or
    another.  Some of them did it to get even with some system administrators,
    most did it to see if it could be done.  I do not automatically call for a
    pound of flesh from all "crackers" or "hackers" who break security.  In
    this case however, I think that the negligence demonstrated by the per-
    petrator is rather gross.  He was playing with a dangerous thing to start
    with.  He also INTENDED that it `infect' other machines on a semi-permanent
    basis.  He DIDN`t tell anyone how to combat it when it got out of control,
    nor did he come forth to assure people that the virus was benign.  This
    is a mistake that I might expect of a freshman student, but certainly not
    a grad student.  This single fact is the most damning of the perpetrator
    in my opinion.  Finally, I don't think that what he did required any great
    amount of brilliance.  As someone who spent some amount of time in stat
    labs with people who could break security of UNIX at will, I can tell you
    that all that is really required is an inquisitive mind, lots of patience,
    and decent C programming experience.  It also requires a certain kind of
    mind set.  If the perpetrator discovered the sendmail bug and the fingerd
    bug WITHOUT source code access, then I would consider using the word
    "brilliant" to describe him.  As it is, I would say he was a competant C
    and UNIX programmer.

    As for punishment?  I agree with others that jail time is counter productive
    in a case like this.  Community service of some type relating to computers,
    plus perhaps a fine, would be more conducive to getting the point across
    that some of us can't afford to sit around a stat lab (anymore) figuring out
    how to screw the system (not a really great challenge), and we can't afford
    to have our machines down for 2 days at a stretch.

    Robert Allen,
    robert@spam.istc.sri.com

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 20:32:45 GMT
From:      renglish@hpisod1.HP.COM (Bob English)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

> / smb@ulysses.homer.nj.att.com (Steven M. Bellovin) /  3:08 pm  Nov 13, 1988 /
 
> I keep looking for a system model that would have blocked this sort of
> attack.  Except for some sort of ``fairness scheduler'' -- one that would
> have kept any one user, such as daemon or nobody from chewing up the
> whole CPU -- I don't see one.  I'd like to, though.

Since the "damage" that this worm produced was denial of service through
overload, a fairness scheduler would indeed have prevented the damage,
though it would not have prevented the worm from arriving.  Since such a
scheduler would be required in order to avoid denial of service in a
trusted system (I'm not sure what the appropriate level would be), such
a system would have behaved reasonably under the worm attack, though
mail service might have been interrupted for a time.

--bob--

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 20:34:59 GMT
From:      pst@canary.cdi.com (Paul Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

From article <8811141359.AB05134@ucbvax.Berkeley.EDU>, by TomZ@DDN1.ARPA:
< 
<          Were YOU hit by the November Internet Virus?
<  
<                       The FBI wants to hear from you!
[deleted....]
< PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!
< /s/
< Tom Zmudzinski
< DDN Security Officer
< (703) 285-5206

Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
f-cking virus was.  You whould think the DDN's security officer would know
better.

							Paul

(Disclaimer: does the DDN perhaps know something that they're keeping hidden?
	     if so, I take back my implication about them being stupid, and
	     replace it with an accusation along the lines of "Why didn't you
	     tell us, you stupid jerks, as we have to check our non TCP sites."

				*sigh*)

------
Paul Traina				To believe that what is true for
{uunet|pyramid}!comdesign!pst		you in your private heart is true
pst@cdi.com				for all men, that is genius.

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 20:57:14 GMT
From:      dhesi@bsu-cs.UUCP (Rahul Dhesi)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Security mailing list

In article <17841@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes:
>I suggest that the security mailing list be posted to a newsgroup,
>but with a 60-day delay.

This is a good idea.  In the case of the oft-quoted ftpd bug, the above
procedure was roughly followed, and it worked.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 21:27:42 GMT
From:      kent@WSL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   units of bogosity

Mumble. I expected that everyone would recognize the reference (to the
Hacker's Dictionary) and realize immediately that I meant it as a joke.
I *did* mean it as a joke -- I guess it was in bad taste. I apologize.
I had no intention of impugning anyone.

chris

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 22:51:11 GMT
From:      tneff@dasys1.UUCP (Tom Neff)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

In article <10846@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>I keep looking for a system model that would have blocked this sort of
>attack.  Except for some sort of ``fairness scheduler'' -- one that would
>have kept any one user, such as daemon or nobody from chewing up the
>whole CPU -- I don't see one.  I'd like to, though.

How about a daemon to kill orphan processes?  The Morris attack tried to
obscure its origins once installed.



-- 
Tom Neff			UUCP: ...!cmcl2!phri!dasys1!tneff
	"None of your toys	CIS: 76556,2536	       MCI: TNEFF
	 will function..."	GEnie: TOMNEFF	       BIX: t.neff (no kidding)

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 22:51:18 GMT
From:      joshua@athertn.Atherton.COM (Sleaze Hack)
To:        comp.protocols.tcp-ip
Subject:   Re: Morris, the law, and his state of mind

>>>From:  clong@topaz.rutgers.edu (Chris Long  12-Nov-88 0158 GMT)
>>>
>>>OK, if you think he should be punished, what should the extent of the
>>>punishment be?

How about 8000 hours of time working for GNU?  Hacker public service!
If GNU will not take him, then perhaps Berekely (sp?).

Josh
--------                Quote: "If you want a program bad enough, you'll get
Addresses:                      a bad program."
joshua@atherton.com OR         
sun!athertn!joshua  OR                 
{backbone}!{decwrl!hpda}!athertn!joshua  work:(408)734-9822 home:(415)968-3718

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 23:13:36 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

In article <8811090956.AA07706@LANAI.MCL.UNISYS.COM>
 perry@MCL.UNISYS.COM (Dennis Perry) writes:
>
>At Los Alamos, and here at Unisys, a program is available to generate
>pronouncable passwords, but composed at random.  These password programs
>can be made to run inplace of the option of inputting your own.  Each
>time you type the 'passwd' command, the system gives you a new one.  If you
>don't like it, you can get another until you find one you lik  These
>passwords are 8 characters long and difficult to guess, if not impossible,
>
>dennis

	Nice idea.  Can you get this into Berkeley and Sun?  :-)

	When I was at InterOp I stopped by the Sytek booth to look at
their telnet server.  I was not impressed, except by a neat little
gizmo they had for their terminal server administrators.  It looked
like a calculator.  To use it you enter a PIN, like at your favorite
ATM machine.  Then when you log onto a secure port to administer your
Sytek terminal server, the login program gives you a sequence of
numbers.  You enter the numbers into the little gizmo and it gives you
a bunch of numbers back.  You enter these into the login program and
you are in.  Anyone catching this sequence over the net cannot
duplicate it, they don't have the little calculator gizmo and your
PIN.
	There must be a name for this kind of security system.  Anyone
know?
	Is this kind of system available elsewhere?  How secure is
this concept?  I thought it sounded like it might be useful for system
administrators.

	Kent England, Boston University

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 88 23:56:14 GMT
From:      leong+@ANDREW.CMU.EDU (John Leong)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet spies.

Kerberos works fine for appropriately designed network applications.
Unfortunately, a lot of system administrators still uses vanilla Telnet to
interact with servers even though the applications themselves use Kerberos.
Once that happens, highly previleged passwords can easily be picked off the
Ethernet (and easier still off AppleTalk).  Human procedural problems tend to
still be the weak link regardless of technology improvement.

Leong

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 08:29:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  tn3270 on WIN/TCP for VMS
The multi-processor version (SMP) of WIN/TCP for VMS 5.0 is now in beta
test and will be available for controlled release in December and general
release in January.

Dave Crocker
VP, Engineering
The Wollongong Group

P.S.  The information about tn3270 in our 5.0 release was correct.
(Thanks, Mike.)

D/

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 00:58:44 GMT
From:      dre%ember@Sun.COM (David Emberson)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

I wish to clarify my recent statement that I knew about this security hole in
sendmail.  Apparently some people have taken this to mean that Sun Microsystems
knew about a problem in their software and deliberately shipped a sendmail with
a security hole.  This is not the case.

At the time that Matt Bishop told me of this bug (1984), we were both employed
by Megatest Corporation.  I ran the computer engineering group there, and Matt
was a member of the group.  We were a beta site for Berkeley's Unix group.
Matt's research interest is in security, and that is how I found out about this
bug.  It was my understanding that the sendmail trapdoor was reported to
Berkeley in 1984 and fixed in 4.3BSD.

I have been employed by Sun Microsystems since January of this year.  At no
time did anyone in the software group know that the sendmail trapdoor could
be used to breach security.  If the bug had been properly reported, it most
certainly would have been fixed.  When Sun finally did become aware of the
security problems, reaction was swift and effective.  I think the work that
Chuq Von Rospach did in getting patches through the system in only a few
days (through a thorough software QA process) is representative of the kind
of responsiveness that Sun strives for and generally provides.

Paul Vixie of DEC Western Research Labs also posted a note to this network
stating that he knew of the sendmail problem:

>From sun!decwrl!vixie Sun Nov  6 11:36:10 1988
>Subject: Re: a holiday gift from Robert "wormer" Morris
>Organization: DEC Western Research Lab
 
># the hole [in sendmail] was so obvious that i surmise that Morris
># was not the only one to discover it.  perhaps other less
># reproductively minded arpanetters have been having a field
># 'day' ever since this bsd release happened. 
>
>I've known about it for a long time.  I thought it was common knowledge
>and that the Internet was just a darned polite place.  (I think it _was_
>common knowledge among the people who like to diddle the sendmail source.)
>
>The bug in fingerd was a big surprise, though.  Overwriting a stack frame
>on a remote machine with executable code is One Very Neat Trick.
>-- 
>Paul Vixie
>Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600

So, I suppose that it is technically true that the knowledge of this problem
existed both inside of DEC and Sun, but it was never reported via a formal
bug report, so it apparently fell through the cracks at both companies.  In
my case, I thought the problem no longer existed.  So I was very surprised to
see this trapdoor exploited by the worm.  It did not seem to me like I was
impugning the quality of anyone's work to say, "Oh yeah.  I knew about that."
I did not think it necessary to say that my statements are not official
statements of Sun Microsystems, Inc.  I thought that was obvious.  In any case,
I sincerely apologize to the very fine team in Sun's software group for this
misunderstanding.

			Dave Emberson (dre@sun.com)

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Nov 88 09:50:00 PST
From:      Norman Kincl <kincl%hp-iag@sde.hp.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Implications of recent virus (Trojan Horse) attack

>                                                               If a few 100
> people KNEW about these holes in the system that were exploited by the 
> recent virus, WHY WEREN'T THEY FIXED?

But they were fixed by a number of the vendors.  Hewlett-Packard, among
others, shipped sendmail without the debug code enabled.

-Norm Kincl
 Information Architecture Group
 Hewlett-Packard

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 02:17:38 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous messages

In article <31376@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
> The server machine has a list of machines that it believes implements
> this level of security.  If you come from a different machine, it
> ignores the fact that you are coming from a low-numbered port. 

And SMTP could do the same and insert an X-Insecure-Message header on
mail from places it doesn't trust.
 
> still isn't completely secure, since it ignores the fact that some
> systems will allow the user to fake the source IP address, thus
> pretending to be coming from a trusted machine; unfortunately, it's
> difficult to do better than this.)

IP packets coming from the wrong ethernet address should cause a
security alarm (and gateways shouldn't pass such packets on). And note
that you have to do more than drop packets with the wrong IP address
on the ethernet: you also have to pick up returning packets which
will not be sent to your ethernet address, so you have to be in
promiscuous mode.

As Robert Elz <kre@munnari.oz.au> pointed out a while ago, the situation
with electronic mail is no different to other communication media:
anybody can write a letter and sign it Ronald Reagan, or phone someone
and say "Hello, this is the New York State Lottery...". 

It seems likely that the legal sanctions preventing these things would 
apply to electronic mail and faxes if they have been worded with sensible
generality. But I do think that SMTP and sendmail make these things
much too easy. People without any technical competence at all can do
mail spoofing. This means you get to include every idiot at an
educational institution. With a little bit of effort it could have
been restricted to idiots in the Computer Science courses!

Bob Smart  <smart@ditmela.oz.au>

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Nov 88 08:17:34 EST
From:      Chris Torek <chris@gyre.umd.edu>
To:        raj@paris.isc.uci.edu, retrac@rice.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: `privileged' ports
Let me correct budding misinterpretations:

Unix does not `assume that low numbered ports are privileged'.
Berkeley Unix enforces the convention that TCP ports in the range
[1..512] cannot be allocated (`bound') to a local connection by anyone
except the super-user.  It further *allows* (but does not *require*)
users and administrators of the system to trust another Internet
address based on this knowledge.  That is, if I believe that machine
Fred is running the same system, with the same restrictions, and if I
believe that the chance of another machine imitating Fred is low
enough, and if I further trust machine Fred itself not to change
systems or allow non-super-users free access to those port numbers, I
can put machine Fred into my `hosts.equiv' or `.rhosts' file.  But
since an IBM-PC is not so restricted, you can be sure that I will not
put *its* Internet address (or name) into my files; furthermore, if I
think there is a good chance that that PC might spoof Fred, I should
not put Fred into my files either.

The mechanism is a convenience, not a requirement (as the folks at
MIT's Athena project have demonstrated).

Chris
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 03:31:57 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   appropriate punishment for Robert Morris


 joshua@atherton.com (S. Hack) meows:

>How about 8000 hours of time working for GNU?  Hacker public service!
>If GNU will not take him, then perhaps Berekely (sp?).

	( sp ) alright!  it's spelled Bezerkely.

	8000 of gnu work wouldn't be punishment at all.

	if the objective is to punish -- Morris should be
	sentenced to 8000 hours on an ibm PC with MS DOS 3.1,
	and no network.

	of course, at the end of the 8000 hours, Morris (the cat)
	could end up producing a virus that could chow up every
	MSDOS ibmclone computer from here to Vladivostok.

	how's that for public service !?

-- 
spdcc!eli@harvard.edu

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Nov 88 09:04:34 EST
From:      Thomas Narten <narten@purdue.edu>
To:        Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc:        hjs@lindy.stanford.edu (Harry Saal), tcp-ip@sri-nic.arpa
Subject:   Re: Does anyone have packet traces taken during Viral spread phase?
>I have to agree with Mike Muss (among others) who noted at the NCSC
>meeting that you're not going to find anything.  The network traffic
>generated by this virus was so small as to not be noticeable.

Actually, packet traces were interesting.  The difficulty is filtering
out the "normal" traffic.  When looking for anomalies, one doesn't
usually have a clear idea of what is and what is not "normal".

Suspecting that the worm propagated itself via rsh, I watched all TCP
packets send to the "shell" port.  Packets generated by the worm
program stood out clearly.  Most connection attempts were very short,
consisting of the SYN, one or two data packets and a FYN.  From the
trace, it was also obvious that the worm was iterating through a list
of machines.

Another anomaly that caught my attention was the use of non-existant
Internet addresses.  The worm appeared to be generating host names
from the network number by trying random host parts.

Watching packets was quite helpful in identifying infected machines.
Indeed, we never disconnected from the Internet, and only a minority
of the our machines were shutdown to kill off the rogue program.  Once
we had a mechanism for identifying infected machines, it was a matter
of killing off the bogus processes on those machines.

Thomas Narten


-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 04:20:54 GMT
From:      deke@galaxy.ee.rochester.edu (Dikran Kassabian)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: A new risk ? (Was Re: Morris, the law, and his state of mind)


In article <486@gara.une.oz> dheap@gara.UUCP (Dave Heap - PSYS) writes:
>In article <1570@valhalla.ee.rochester.edu> deke@valhalla.ee.rochester.edu (Dikran Kassabian) writes:
>>
>>The medical center/teaching hospital at my university is also network
>>connected.  What if the network overload caused patient monitoring systems
>>there to be sluggish and inadequate?
>
>	Do you really mean that you have critical patient monitoring systems
>running on a user accessible system, subject to clogging & vagaries from
>other users, apart from net viruses? I hope you have made a mistake with
>this statement, or else it's a first class candidate for comp.risks

No, what I REALLY mean is that you only partially quoted me and are now
extrapolating.  The only mistake was the interpretation you imposed on what
I said.  My point is, and was, the "worm" cannot be considered harmless unless
the author KNEW it would do no harm.  He couldn't have known that, and neither
could anyone else.


      ^Deke Kassabian,   deke@ee.rochester.edu   or   ur-valhalla!deke
   Univ of Rochester, Dept of EE, Rochester, NY 14627     (+1 716-275-3106)

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Nov 88 07:55:32 N
From:      virchaux%CLSEPF51.BITNET@CUNYVM.CUNY.EDU (Jacques Virchaux EPFL-SIC)
To:        tcp-ip@sri-nic.arpa
Subject:   Security (virus or other system hole)
These lines I received in June on another list must be considered :

--jack
====================================================================
Subj:   Reporting Security Problems
From:         goldstein%star.DEC@decwrl.dec.com

[extract]

But I know of no law that requires an individual to report security
problems. If I attempt to draw a parallel to other industry, I don't
believe there are any laws requiring private individuals to report,
say, safety problems they become aware of. In general, concealment of
risks is only illegal where the party who hides information stands to
gain from having the information remain secret (e.g., by avoiding a
costly recall campaign or expensive safety improvements in a factory)
or has control over the risk.

But I do think people who find a security problem have a moral
obligation to report it. People who find security problems are in
general professionals or researchers, and carry an obligation to the
advancement and improvement of the art. Reporting problems is part of
that obligation.

[...]

If a security problem exists, someone will find it sooner or later;
I'd rather it were the curious but responsible hacker than someone
malicious.

Do please report the problem to the manufacturer. Easier said than
done, of course. Most major computer manufacturers have large
bureaucracies dedicated to "customer service", and wading through
this bureaucracy and its rules can be tedious. DEC is no exception.
Try starting with the nearest software service office. See if you
can get through to someone technical.

[...]

There is a logical next step one might consider, which is to publish
the problem itself. This I implore you not to do. Please don't even
tell your friends. Yes, you'll get lots of attention and action, but
you'll also cause both the manufacturer but mainly the entire user
base much pain. Think about it. You're the only person (in all
probability) who knows about this problem. If you're a responsible
guy, it'll be safe with you. But there are a lot of not very nice
people in the world, and a lot of copycats. If you publicize a
security problem, you give all these dirtballs a tool to go messing up
the lives of a lot of innocent computer users.

Even publicizing a security problem to "responsible people" carries a
risk. The more people know about the problem, the greater the chance
it will get out somehow.

[...]

                    Andy Goldstein
                    VMS Development
=======================================================================
I agree with him !
                                                Jacques Virchaux
                                        Swiss Federal Institute of Technology
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Nov 88 11:53:00 EST
From:      Jon Rochlis <jon@ATHENA.MIT.EDU>
To:        Thomas Narten <narten@purdue.edu>
Cc:        Rochlis <jon@ATHENA.MIT.EDU>, hjs@lindy.stanford.edu, tcp-ip@sri-nic.arpa
Subject:   Re: Does anyone have packet traces taken during Viral spread phase?

Re: finding infection attempts from packet monitoring info.  It was
easier to spot infected machines by logging in and do a "cat -v
/usr/tmp" ... 

   Another anomaly that caught my attention was the use of non-existant
   Internet addresses.  The worm appeared to be generating host names
   from the network number by trying random host parts.

But that is *not* true.  The virus only picked of target machines that 
were listed as gateways in the routing table, or were listed in one of 
the hosts.equiv, .rhosts, and .forward files.

During the crisis packet traces were not that useful because you
tended to spot things that didn't actually exist (like the above).  We
once thought we not only saw the non-existent ernie packets but
replies as well (wouldn't that have been something).

Once we knew enough about the beastie to get it to infect machines at
will, we infected a target machine and monitored what it did.  That
proved to be quite useful.  As did checking for ernie packets in Wed
mornings logs before we understood that the attempt to send them would
fail.

		-- Jon
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 12:32:35 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

In article <557@comdesign.CDI.COM> pst@canary.cdi.com (Paul Traina) writes:
:From article <8811141359.AB05134@ucbvax.Berkeley.EDU>, by TomZ@DDN1.ARPA:
:: 
::          Were YOU hit by the November Internet Virus?
::  
::                       The FBI wants to hear from you!
 [deleted....]
:: PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!
:: /s/
:: Tom Zmudzinski
:: DDN Security Officer
:: (703) 285-5206
:
:Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
:f-cking virus was.  You whould think the DDN's security officer would know
:better.
:
:[junk deleted which suggested paranoia on the part of the poster]
:------
:Paul Traina

This type of comment is totally uncalled for. 1). Tom was referring
to the TCP-IP mailing group. 2). I have had a couple of occasions to talk
with Tom since this whole thing started and I have found him to be quite
helpful, open to suggestions, and willing to share appropriate information.
I am not opposed to personal flames (though it is not my style), but this
one was simply ungrounded and contributed nothing to our understanding of
the problem.

Sean McLinden
Decision Systems Laboratory

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 15:15:02 GMT
From:      jc@heart-of-gold (John M Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert Morris

In article <566@husc6.harvard.edu>, cherry@husc4.HARVARD.EDU (Michael Cherry) writes:
> In article <565@husc6.harvard.edu> kovar@husc4.UUCP (David Kovar) writes:
> >If at all possible, punish RTM to the fullest extent of the law. It may
> >be more than he deserves but unfortunately (?) someone must set the
> >example and show that such anti-social activities are not acceptable.
> 
> It is difficult to agree however it is analogous to a brilliant University
> Molecular Biologist experimenting on a biological virus but through
> inadequate precautions results in a large number of dogs in North America
> becoming infected. The released virus could be completely harmless - but
> I don't think this country would want or should allow this act to go
> completely unpunished.
> 
Well, now, that depends on what you want for an after-effect.  I'd suggest
that punishing rtm would likely have a deterrent, but that perhaps you
might not really want that, if you think about it.

Consider:  I am a hacker (oops, I mean a professional software engineer :-)
who has discovered an interesting security hole in a widely-used piece of
software.  What should I do with the information?

The obvious suggestion is that I should start by telling my employers and
the vendor(s) about it, so they can fix it.  Well, it has become clear that
many people had been warning of the sendmail "feature" that the worm used
for at least two years, and absolutely nothing was done by any vendor to
fix it.  My experience is that if you just announce that you've found a
problem, you are treated like Chicken Little.  You must demonstrate the
problem, if you want people to listen to you.

OK, so you write up a little demo and send it around.  What happens?  Unless
you are perfect, and your code runs without bugs on all systems (including
some you've never seen), your example will do something like rtm's worm,
and half the world will be calling for prosecution.  You'll use a whole
lot of your time (and money) defending yourself.  You *won't* be thanked
for what you did.  You'll wish you had kept your big mouth shut.

There is, of course, a third course.  You could just add your demo to your
own personal library of security-related code, and quietly let people know
that you have it.  You might then be able to get some interesting (not to
say lucrative) jobs from organizations that have a use for your knowledge.

Think about it.  There are lessons for all of us here.  But is the above
really the lesson you want to teach?

-- 
From:	John Chambers <mitre-bedford.arpa!heart-of-gold!jc>
From	...!linus!!heart-of-gold!jc (John Chambers)
Phone	617/217-7780
[Send flames; they keep it cool in this lab :-]

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 15:28:06 GMT
From:      jc@heart-of-gold (John M Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

In article <1792@sbcs.sunysb.edu>, root@sbcs.sunysb.edu (root) writes:
> Does anyone know whether the sendmail virus was able to infect
> the machines protected by Kerebos?  No flames, please, the question
> isn't a statement against Kerebos per se; I just wonder whether
> clever people will always find ways into "secure" Unix boxes.
> What about machines that have met with tempest specs?
> 
You should be a bit wary of accepting the answers.  I personally know of
several MilNet systems that were infected, but the public answer from their
administrators is "Of course not!"  Ask yourself:  Why should they tell the
truth?  I suspect that nobody (not even those in security agencies) will
ever know how widespread the infection really was.  Considering that no
real damage was done, it's very easy to cover up an infection and pretend
it never happened.

-- 
From:	John Chambers <mitre-bedford.arpa!heart-of-gold!jc>
From	...!linus!!heart-of-gold!jc (John Chambers)
Phone	617/217-7780
[Send flames; they keep it cool in this lab :-]

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 17:00:22 GMT
From:      dsg@mitre-bedford.ARPA (David S. Goldberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

In article <170@heart-of-gold> jc@heart-of-gold (John M Chambers) writes:
>> 
>You should be a bit wary of accepting the answers.  I personally know of
>several MilNet systems that were infected, but the public answer from their
>administrators is "Of course not!"  Ask yourself:  Why should they tell the
>truth?  I suspect that nobody (not even those in security agencies) will
>ever know how widespread the infection really was.  Considering that no
>real damage was done, it's very easy to cover up an infection and pretend
>it never happened.
>
>-- 
>From:	John Chambers <mitre-bedford.arpa!heart-of-gold!jc>

John,

	It is not the case that all MILnet hosts are denying that they were
affected.  Mbunix (MITRE's corporate Ultrix systems for those of you who are
not with MITRE) was attacked, although the worm didn't replicate itself
there (ie the connections were made, but symptoms never felt), and at least
one local Sun network was infected.  I even spoke to a reporter about it, so
I know that we are not denying anything about being hit.  If the question is
whether or not machines containing classified info were hit, then the answer
is probably no, because (granted, as I understand it) those machines are not
even allowed on MILnet or any other wide network.

-dave
--------------------------------------------------------------------------
Dave Goldberg	             ARPA: dsg@mitre-bedford.arpa
The Mitre Corporation        or    dsg@mbunix.mitre.org
MS B020                      UUCP: linus!mbunix!dsg
Bedford, MA 01730
617-271-2460

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Nov 88 17:46:25 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

In article <8811090956.AA07706@LANAI.MCL.UNISYS.COM> perry@MCL.UNISYS.COM (Dennis Perry) writes:
>... At Los Alamos, with password checking, any attempt to login
>in that results in more than 3 failures results in that login name being
>'blacklisted' and no further attempts are allowed.

This feature, of course, opens up a nice "denial of service" attack:  if
you have access to the machine, and know somebody's login name, just try
to login as them three times with nonsense passwords.  Presto, they can't
login until they go see the security people.  Particularly useful if you
have just broken into the system and want to keep the sysadmins off until
you finish doing your dirty work.

>I stongly encourage everyone to use such a password generator and not
>allow people to generate their own passwords.  

Unfortunately, this opens up two other problems.  First, a much higher
probability that passwords will be written down rather than memorized.
Second, some vulnerabilities if the password generator is poorly built,
e.g. if it uses a 16-bit random-number generator!

>Password aging is also something that could and probably should be done.

But done well, not done poorly as it was in Unix System V.
-- 
Sendmail is a bug,             |     Henry Spencer at U of Toronto Zoology
not a feature.                 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 18:07:42 GMT
From:      jds@mimsy.UUCP (James da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus


In article <557@comdesign.CDI.COM> pst@canary.cdi.com (Paul Traina) writes:
>From article <8811141359.AB05134@ucbvax.Berkeley.EDU>, by TomZ@DDN1.ARPA:
>[deleted....]
>< PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!
>[deleted....]
>
>Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
>f-cking virus was.  You whould think the DDN's security officer would know
>better.
>
>							Paul


Sigh.  He was talking about the Internet mailing list "TCP-IP@SRI-NIC.ARPA",
which you happen to be reading.  I imagine from your ignorance you are
reading the list throught the Usenet `comp.protocols.tcp-ip' gateway'ed news
group?

So, tell us more about `those stupid jerks'...  :-|

----------------------------------------------------------------------
path:   uunet!mimsy!jds 				James da Silva
domain: jds@mimsy.umd.edu

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 18:38:50 GMT
From:      der@sfmag.UUCP (D.Rorke)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: a holiday gift from Robert Morris

> >According to press reports, RM spent his summers working at AT&T
> >on "Unix Communications Software Security". Anyone with a source
> >license check to see if he slipped a trojan horse into uucico
> >or uuxqt or something?
> >-- 
> 
> As a matter of fact, one of the things Robert did at Bell Labs (while
> still a high school student, I believe) was fix some of the glaring
> security holes in uucp (AT&T Bell Laboratories Technical Journal,
> 10/84).

The author of the article you reference was not the Robert Morris
under suspicion (although it may be his father).  The biographical
notes at the end of the paper indicate that the Robert H. Morris
who co-authored the paper had been employed at Bell Labs since 1960.

> It is very easy in the aftermath of something like this to indulge in
> the devil theory of crime -- that all bad things must come from evil
> minds.  The more you find out about rtm I believe the more you will find
> he has in common with the people criticizing his behavior.  He has done
> significant work in computer security, including warning people for
> years about the security holes that made the worm possible.  He has
> worked as a sysadmin for an arpanet host.  He is a serious student of
> computer science and was making contributions to the field at an age
> when most of us were trying to learn Pascal.  He's also one hell of a
> great guy, and no one seems more appalled by the effects of his actions
> than he is.

Being a "great guy" is not sufficient.  As members of society we are
also expected to exhibit a reasonable degree of responsible judgement.
Perfectly nice people get roaring drunk, get into their cars, and
unintentionally run over little children.  Although this analogy is lacking
in some ways it is meant to dramatically make the point that nice, well
intentioned people can do irresponsible things that cost the rest of society
a great deal.  Such people must be held accountable for the results of
their irresponsibility.

The person responsible for this virus may in fact be a "great guy" in many
ways and may not have thought there was anything wrong with what he was doing.
If so, he had a very poor understanding of the ethics involved.  Although we
may feel sorry for him we cannot afford to easily excuse such poor judgement.


> We can argue about the advisability of what he did, but I urge you to
> resist the temptation to pigeon-hole someone you don't know on the basis
> of fragmentary information.
> 
> Jim Matthews
> Dartmouth Software Development


Dave Rorke
attunix!der

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 20:02:18 GMT
From:      alexew@watdcsu.waterloo.edu (A.E.Wielhouwer - Computing Services)
To:        comp.protocols.tcp-ip
Subject:   Multi-protocol SLIP alternative


Some time ago there was some discussion regarding work being done on a
serial line protocol which would handle mixtures of network protocols 
( e.g., IP + DECNET + XNS ). Does anyone know the current status of this
project ? 

Thanks in Advance:

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 20:37:30 GMT
From:      zeleznik@wasatch.UUCP (Michael Zeleznik)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

In article <26010@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:
>
> 	When I was at InterOp I stopped by the Sytek booth to look at
> their telnet server.  I was not impressed, except by a neat little
> gizmo they had for their terminal server administrators.  It looked
> like a calculator.  To use it you enter a PIN, like at your favorite
> ATM machine.  Then when you log onto a secure port to administer your
> Sytek terminal server, the login program gives you a sequence of
> numbers.  You enter the numbers into the little gizmo and it gives you
> a bunch of numbers back.  You enter these into the login program and
> you are in.  Anyone catching this sequence over the net cannot
> duplicate it, they don't have the little calculator gizmo and your
> PIN.
> 	There must be a name for this kind of security system.  Anyone
> know?
> 	Is this kind of system available elsewhere?  How secure is
> this concept?  I thought it sounded like it might be useful for system
> administrators.
> 
> 	Kent England, Boston University


This is generally called a one-time-password approach (analogous to
cryptographic one-time-pads), or a personal password generator. There
are different flavors, but the bottom line (as you point out) is that
each login authentication number is different (can't be reused), and
thus there aren't any passwords to keep secret, and you needn't protect
the passwords while they are in use, since they can't be reused.

Racal-Guardata (Orange, CA) makes the Watchword (this previously was the
Sytek 'Passport' that you saw); host system issues a challenge, you type
it into the small calculator with your PIN which gives you a response,
you type that back to the system, and you are authenticated.  Each
challenge from the system is different, along with each response, so any
response can not be reused by anyone.   In addition to your normal PIN,
there is a duress PIN; the Watchword will generate different responses
depending on the PIN, so the remote system can tell if you are being
forced to login, for example.  

We prototyped a version of the Sytek Passport for an application system,
and it worked very nicely.  Only problem was having to have this small
calculator around, which is kind of a pain.  If they put it in a true
credit card unit, it would be great.

Security Dynamics (Cambridge, MA) makes one that is time based, called
the SecurID.  A number on a credit card sized calculator changes every so
many seconds, in sync with software on the host.  Thus, you just type in
the current displayed number.   Again, the numbers are not repeated, so
there is no need to encrypt anything. They claim to handle clock drift
and such, but the last time I thought about this, it seemed there may be
a window of vulnerability if you need to quickly login across a number
of remote hosts.

Another variation on this approach is a hand held device which reads the
challenge directly from the CRT screen (number is encoded by modulating
the light output by sending characters at encoded rates) and gives
you the response which you type in. One manufacturer of this type is
Gordian Systems, Palo Alto, CA, and the device is called the Gordian
Systems Access Key.

These systems are also capable of providing REVERSE authentication,
having the system provide a challenge response pair, which you can
verify on your personal hardware.  Depending on the approach used, this
can either be provided in the product, or would have to be user
implemented.

Even a system like Kerberos could use this in place of the fixed user
password, to eliminate that vulnerability (the time interval while
the password is stored in the user node before it is destroyed; if a
trojan horse grabs it only once...).

All three of these systems are in the NSA's evaluated products list,
under sub-systems, but I have only looked at the condensed versions (in
the INFOSEC Products and Services Catalogue), which don't say much.

Since the authentication values can be very long and very random, most
of the conventional "password" attacks are obviated.   However,
conventional cryptanalytic attacks are possible, and the quality of the
cryptographic algorithm which generates the responses is the key to the
security.  The Watchword uses DES; the SecurID used a proprietary scheme
the last I looked at it; don't know about the others.  The Watchword (if
not the others also) is in a tamper resistant enclosure. I'm not a
cryptographer/cryptanalyst, so I can't really comment on the relative
security of the algorithms.

Clearly, the database of user key data is a major vulnerability, which
must be protected.  The NSA explicitly points this out for the Gordian
Systems product.  From what I remember, the SecurID product had the
authentication server run on a physically isolated PC for that reason.


Michael Zeleznik              Computer Science Dept.
                              University of Utah
zeleznik@cs.utah.edu          Salt Lake City, UT  84112
                              (801) 581-5617

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 20:50:03 GMT
From:      csg@pyramid.pyramid.com (Carl S. Gutekunst)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: SF columnist on the Worm, suggests new terminology.

In article <457@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes:
>Jon Carrol's Wednesday column in the SF Chronicle is an interesting
>example of the level of "popular journalism".

And Dave's posting is an interesting example of copyright violation. It is
AGAINST THE LAW (to say nothing of highly inethical) to reprint coyrighted
works without the permission of the copyright holder. Newspaper articles are
no exception.

I asked Dave (via e-mail) to cancel the posting; he refused. I have cancelled
it myself.

<csg>

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 21:11:13 GMT
From:      jas@ernie.Berkeley.EDU (Jim Shankland)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

In article <8811141359.AB05134@ucbvax.Berkeley.EDU> TomZ@DDN1.ARPA writes:
>The Federal Bureau of Investigation is attempting to gather critical
>information necessary to pursue [the Morris worm] case under the Computer
>Fraud and Abuse Act of 1986.
>...
>    Points of Contact should expect to be contacted by their local FBI
>    agents for dispositions due to the wide geographical area involved.

I'll bet you mean "depositions", not "dispositions".

*My* disposition is usually sunny, except when the FBI comes knocking
at the door.

Jim Shankland
jas@ernie.berkeley.edu

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 22:43:00 GMT
From:      gillies@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Predictable


Plant geneticists learned their lesson long before you're going
to learn yours.

It's not good to completely standardize O/S design, since this reduces
the gene pool, making most of the internet vulnerable to the same
attack.  This problem WOULD NOT have been so serious ten years ago.
Back then, only a small fraction (perhaps 10% ?) of the internet
computers were running UNIX.  ARPA hosts were running things like
TOPS, TENEX, TWENEX, VM, Level-6 O/S, RT-11, NOS, etc...

Sure, it's not a good argument for bashing *UNIX*, but it's a good
argument against making *ALL OS's* run exactly the same software.

Standardized high-yield crops are a great idea.  Until someday, a
plant virus or insect mutates, ruins the worldwide crop, and the whole
world STARVES.  The same goes for computer operating systems.


Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,harvard}!uiucdcs!gillies

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 88 23:27:41 GMT
From:      chk@dretor.dciem.dnd.ca (C. Harald Koch)
To:        comp.protocols.tcp-ip
Subject:   password aging (was Re: virulence of the recent virus)

In article <1988Nov8.224853.16081@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <6704@venera.isi.edu> cracraft@venera.isi.edu (Stuart Cracraft) writes:
>>... If you enable aging, for example, once every
>>month or two, every user who logs into your system will be required
>>to specify a new password.
>
>On the spur of the moment, which means that he often will make up a poor
>password, or simply alternate between two passwords.

On a system somewhere that aged passwords at the beginning of each month,
it was found that many users used the name of the month as their password
to make it easy to remember.

	-chk
--
C. Harald Koch		NTT Systems, Inc., Toronto, Ontario
chk@zorac.dciem.dnd.ca, chk@gpu.utcs.toronto.edu, chk@chk.mef.unicus.com
Note: some sites may still have zorac.dciem.dnd.ca as zorac.ARPA.
"I give you my phone number. If you worry, call me. I'll make you happy."

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 08:25:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Mail addresses with '%'
Sometime back, Bill Lewandowski asked tcp-ip and sun-spots about the origin
of using per-cent (%) in mail addresses and whether he could use dollar
sign ($) instead, due to some constraints.  I don't know the address of
sun-spots, so this is being sent just to tcp-ip.  Bill tells me that he
got many replies, none of which could elucidate the usage.  To my knowledge,
I introduced it into common use, so here is the history:

At the University of Delaware, we began relaying mail, circa 1979, via
The Rand Corp.  They were attached to the Arpanet and UDel was not. RFC733,
the addressing/format standard in effect at the time, allowed the use of
multiple at-signs (@), which would permit specification of routes.  This would
have been just fine for our needs, except that we could not find a single
mail server or user agent that could handle it.  (The test was not exhaustive,
but after five or ten, it didn't matter, since the addressing scheme had to
be universally acceptable.)

This required that the additional routing information be buried -- i.e.,
Arpanet hosts could be allowed to see only the next-hop host, in this case
Rand.  Any additional route information, usually only one more host, the
destination, had to be invisible.

I checked for the set of characters that were not special to mail systmes OR
TO TERMINAL HANDLERS, ETC.  The mail relay software we had developed (MMDF)
had a telephone link protocol that went through un-modified, line-at-a-time
terminal handlers -- e.g., you did not have to put Unix into raw -- so that
I needed to avoid any operating system-specific special characters.  Only
two or three characters passed this test, with per-cent laying claim to some
degree of being common-sense, since it also is used to mean "in care of",
thereby already being established for one kind of mail processing.

All of this was to be a short-term hack, waiting for addressing standards
to add the ability to specify routing information.  Domain names and the
<@a.b.c, foo@d.e.f> syntax of RFCs 821/822, came a few years later.  
Unfortunately, it was too late.  Some places have actually enacted new
standards that specify semantics for per-cent, officially.  Sigh.

Besides adding complexity, the damn character is upper-case, in that you need
to type shift.  This slows down typing.

Once again we learn that there is no such thing as throw-away code..

Dave

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 00:28:42 GMT
From:      pst@comdesign.CDI.COM (Paul Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

From article <557@comdesign.CDI.COM>, by pst@canary.cdi.com (Paul Traina):
> Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
> f-cking virus was.  You whould think the DDN's security officer would know
> better.

You would think that some idiot would think to read twice, examining all
interpretations of a message, before coming back with an obnoxious reply.
Needless to say, some idiot did not.  Appologies to the DDN et al.
-- 
Paul Traina				To believe that what is true for
{uunet|pyramid}!comdesign!pst		you in your private heart is true
pst@cdi.com				for all men, that is genius.

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 00:40:56 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

Steve,

Your observation that the B1 criteria, by itself, would
not have stopped the worm is probably correct (sounds plausible
to me) as far as you've taken it.  But a real security system
goes farther.

The secure portion of Defense Data Ne is currently segregated from the
rest of the internet, and will remain so indefinitely.  In the near
future, the access control system will use an authentication node
who checks to see who you are upon connection opening; then orders
a key distribution node to issue you and your other party a
unique end-to-end password which evaporates at the conclusion
of your session.  

More important than the technical aspects are the personnel management
ones.  If you have a job that does not require access to a secure
system, then you lack a need to know and hence do not get in.
Regardless of clearance level.  Every time I've had a clearance
issued, recertified, upgraded or terminated, I get some indoctrination
regarding the importance of classified information and system integrity
for the structure that we use to contain it (sometimes I give
the indoctrination).

Link encryption, end-to-end encryption, multi-level secure systems,
necessary segregation and personnel management/training/leadership
are all important parts of a classified system and none can do the
job alone.

Rex Buddenberg

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 00:41:09 GMT
From:      kent@tfd.UUCP (Kent Hauser)
To:        comp.protocols.tcp-ip
Subject:   Re: Implications of recent virus (Trojan Horse) attack

In article <101070001@hpcvlx.HP.COM>, everett@hpcvlx.HP.COM (Everett Kaser) writes:
> I would propose that there is a place (in our computer-network-society) for
> persons attempting to write (non-destructive!) viruses.  There is no better
> means of protecting ourselves from destructive viruses than to be constantly
> testing ourselves with non-destructive ones. 

I propose that the ``worm'' be tested on the manufacturer's network.
For instance, the recent Internet virus should have been sent
directly to Sun and Dec (and maybe Berkeley) to *blow away* their 
networks.  I think that if we users were diligent in harassing
the manufacturers, maybe they would expend a little more effort in 
beefing up security!



-- 
Kent Hauser			UUCP: sun!sundc!tfd!kent
Twenty-First Designs		INET: kent%tfd.uucp@sundc.sun.com

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 00:54:30 GMT
From:      leo@WHEATIES.AI.MIT.EDU (Leonardo C. Topa)
To:        comp.protocols.tcp-ip
Subject:   subscription

I would like to be added to your mailing list. Thank you.

Leonardo Topa
Director of Computing
M.I.T., Whitaker College

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 01:51:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet filtering for 4.3BSD ?

Someone (whose name is now lost to me) recently asked
  I have a TCP/IP gateway running 4.3BSD, and I've just been told that it
  has to be able to filter packets based on UDP and TCP port numbers, and
  possibly on source and destination IP addresses.  Has anyone already modified
  4.3BSD to do this sort of thing?  If so, I'd like to see the code...

bart@videovax.Tek.COM (Bart Massey) responded:
   One of the lesser known pieces of useful code I discovered recently is the
   BSD "packet filter" code which has been around since at least 4.2D, and is
   currently in /usr/src/new/enet in the 4.3 distribution.  With fairly minimal
   changes (mainly to the ethernet driver for your machine) you should be able
   to get it to do everything you want and satisfy 1-3 above...  Its chief use
   currently is for filtering off and generating V packets for UNIX V servers,
   but it's really much more general-purpose than that...

Since I wrote much of the "packet filter" code in question, I felt I
should respond.  I'll agree that it's useful, but it would take more
than "minimal changes" to connect it into the gateway function of a
4.xBSD kernel.  I suppose one could modify the ethernet driver to dump
(copies of) all the incoming IP packets into the packet filter, which
would then pass them to a user-level process ... which would have to
implement all the functions of an IP gateway, including routing,
fragmentation, etc.

Alternatively, one could perhaps modify the IP input code to run
forwardable packets through the packet filter, which would also have to
be modified somewhat to pass the packets on to the forwarding code in
the kernel (instead of out to a user process).

Either way, this seems like a lot of work, and I suspect that it would
be almost as easy to build a much simpler and more suitable mechanism
for this purpose.

I'd also like to suggest that this is one more reason why people should
not be using 4.xBSD systems as gateways; I believe that some of the
commercially-available gateway products provide some filtering
functions.

-Jeff

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 02:53:30 GMT
From:      jgm@kokab.cc.deakin.OZ (John Moorfoot)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

In article <26010@bu-cs.BU.EDU> kwe@bu-it.bu.edu (Kent England) writes:
>In article <8811090956.AA07706@LANAI.MCL.UNISYS.COM>
> perry@MCL.UNISYS.COM (Dennis Perry) writes:
>>
>	When I was at InterOp I stopped by the Sytek booth to look at
>their telnet server.  I was not impressed, except by a neat little
>gizmo they had for their terminal server administrators.  It looked
>like a calculator.  To use it you enter a PIN, like at your favorite
>ATM machine.  Then when you log onto a secure port to administer your
>Sytek terminal server, the login program gives you a sequence of
>numbers.  You enter the numbers into the little gizmo and it gives you
>a bunch of numbers back.  You enter these into the login program and
>you are in.  Anyone catching this sequence over the net cannot
>duplicate it, they don't have the little calculator gizmo and your
>PIN.
>	There must be a name for this kind of security system.  Anyone
>know?
>	Is this kind of system available elsewhere?  How secure is
>this concept?  I thought it sounded like it might be useful for system
>administrators.

This sounds like PFX from Sytek. The s/w runs on a PC attached to
a secure port on the host, and each user has a calculator which
generates a response from a prompt issued from the server. It is
as secure as the port to which the PC is attached.

A host program asks the PC for a challenge for a user, and the PC
returns the challenge and two possible responses. The calculator
can be programmed to accept two separate PINs, and will give a
response to the challenge dependant on the PIN entered. This
provides an adiitional degree of security, as the second PIN can
be used (for instance) if the user is under duress.

The PC can be connected to a printer to provide an audit trail of
operations on the PC database, and it can also provide a facility
for disable a user for authentication without deleting the user's
record.

John Moorfoot 		ARPA:	jgm%charlie.oz.au@uunet.uu.net
			UUCP:	...!uunet!munnari!charlie.oz!jgm

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 03:10:02 GMT
From:      erc@unisec.usi.com (Ed Carp)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: SF columnist on the Worm, suggests new terminology.

In article <47235@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
> In article <457@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes:
> >Jon Carrol's Wednesday column in the SF Chronicle is an interesting
> >example of the level of "popular journalism".
> 
> And Dave's posting is an interesting example of copyright violation. It is
> AGAINST THE LAW (to say nothing of highly inethical) to reprint coyrighted
> works without the permission of the copyright holder. Newspaper articles are
> no exception.
> 

Well, that isn't true all the time.  You may reprint short excerpts under
certain circumstances.

> I asked Dave (via e-mail) to cancel the posting; he refused. I have cancelled
> it myself.
> 

Why?  What do you care if someone gets in trouble?  It's not YOUR
hide!
--
Ed Carp	 N7EKG/5 (28.3-28.5)	erc@unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (home) (512) 834-2507
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!erc

"I can't deal with this -- I'm outta here"  --Don Johnson

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 05:03:36 GMT
From:      wbe@bbn.com (Winston B Edmond)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert Morris

In article <168@heart-of-gold> jc@heart-of-gold (John M Chambers) writes:
>Consider:  I am a hacker (oops, I mean a professional software engineer :-)
>who has discovered an interesting security hole in a widely-used piece of
>software.  What should I do with the information?
>
>....  You must demonstrate the
>problem, if you want people to listen to you.
>
>OK, so you write up a little demo and send it around.  What happens?  Unless
>you are perfect, and your code runs without bugs on all systems (including
>some you've never seen), your example will do something like rtm's worm,
>and half the world will be calling for prosecution.

I think it rather unlikely that being imperfect or having a program with bugs
would cause the program to act like a worm if hadn't been mostly written to
be that anyway.  But since you asked, there's another, simpler, solution:
attack the software supplier's host directly.  This doesn't require writing
code to replicate, read host tables, decrypt password tables, etc. -- just
write a file called VIRUS in "/" owned by root or daemon or whatever, and let
the vendor know about it.

Attacking the vendor's host is just as illegal and unethical as writing a
worm that attacks the whole Internet, but it will keep the N-1 other Internet
administrators from calling the FBI.  Before resorting to this, however, a
phone call to the right person at the site to be attacked might be just as
effective.

For the more paranoid among us, we can wonder whether or not such security
holes have already been exploited to modify some vendor's software without
the vendor's knowledge.
 -WBE

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 05:30:55 GMT
From:      rsm@amethyst.ma.arizona.edu (Robert Maier)
To:        comp.sources.wanted,comp.windows.x,comp.protocols.tcp-ip
Subject:   A supdup client for X Windows?

Has anyone written a supdup client that (1) supports graphics and (2)
runs under X Windows?

For those who may not be familiar with it, supdup is a much improved
version of telnet: its wire protocol is terminal-independent, and it
provides a virtual terminal substantially more powerful than the
line-oriented glass TTY that telnet supplies.

I have seen various public-domain supdups written at MIT, but none
that runs under X.  Any suggestions as to where to look?

--
Robert S. Maier
SNAIL: Dept. of Math.; Univ. of Arizona; Tucson, AZ 85721; USA
VOICE: +1 602 621 6893 / +1 602 621 2617
UUCP: ..{allegra,cmcl2,hao!noao}!arizona!amethyst!rsm
BITNET: maier@arizrvax          INTERNET: rsm@amethyst.ma.arizona.edu

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 06:28:13 GMT
From:      pavlov@hscfvax.harvard.edu (G.Pavlov)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <77604@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes:
> 
> So, I suppose that it is technically true that the knowledge of this problem
> existed both inside of DEC and Sun, but it was never reported via a formal
> bug report, so it apparently fell through the cracks at both companies. 

  Note that DEC claims to have closed the door (before the worm).  As far as
  I know, Vaxen running Ultrix did ok. 

   greg pavlov, fstrf, amherst, ny

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 07:29:34 GMT
From:      mike@ists (Mike Clarkson)
To:        comp.protocols.tcp-ip
Subject:   Re: Morris, the law, and his state of mind

In article <241@olive.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Sleaze Hack) writes:
> >>>From:  clong@topaz.rutgers.edu (Chris Long  12-Nov-88 0158 GMT)
> >>>
> >>>OK, if you think he should be punished, what should the extent of the
> >>>punishment be?
> 
> How about 8000 hours of time working for GNU?  Hacker public service!
> If GNU will not take him, then perhaps Berekely (sp?).

Given Stallman's views on security, I'm sure GNU would welcome him with
open arms.

BTW, how many people are still running gnu emacs' movemail suid root?

Mike.
-- 
Mike Clarkson					mike@ists.UUCP
Institute for Space and Terrestrial Science	mike@ists.yorku.ca
York University, North York, Ontario,		uunet!mnetor!yunexus!ists!mike
CANADA M3J 1P3					+1 (416) 736-5611

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Wed 16 Nov 88 15:46:13-EST
From:      RichDeJordy, x295 <RAD@VAX02.AMS.COM>
To:        amdahl!pyramid!comdesign!canary!pst@AMES.ARC.NASA.GOV
Cc:        tcp-ip@SRI-NIC.ARPA, RAD@VAX02.AMS.COM
Subject:   Re: FBI Contact re: November Internet Virus
Someone oibjected to the line "Not everyone is on TCP-IP" as part of a request
for expanded distribution of some informational message, saying that everyone
hit by the virus was, and that the DDN either didn't know what they were saying
or they were hiding something.  

I believe the misconception is this.  TCP-IP was meant as the TCP-IP mailing 
list from SCORE, not the Internet itself.
-------
-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Nov 88 19:06:51 -0500 (EST)
From:      Walter Lloyd Wimer III <ww0n+@andrew.cmu.edu>
To:        tcp-ip@sri-nic.arpa, pcip@louie.udel.edu
Subject:   RFC-1048 compatible BOOTP server now available
An RFC-1048 (BOOTP Vendor Information Extensions) compatible BOOTP (RFC-951)
server is now available for anonymous FTP from lancaster.andrew.cmu.edu
(128.2.13.21).  The new server can be found in pub/bootp.2.0.tar.  This is
an enhanced version of the existing CMU BOOTP server which was derived from
the original BOOTP server created by Bill Croft at Stanford.

New features and changes in version 2.0 include:

o  Full support for the vendor information extensions described in RFC-1048.
o  Faster response time (host lookup via hash table instead of linear search).
o  New termcap-like configuration file format which allows greater flexibility
   in specifying the variable vendor information of RFC-1048.  Host entries
   may refer to other hosts as templates so that redundant information need
   be specified only once.
o  Continued support for the CMU vendor information format.  The server may
   be configured on a per-host basis to always reply with a certain vendor
   information format or to reply based on the client's request.
o  Expanded logging.
o  The server may now be run by inetd or as a standalone program like the
   old version.
o  The configuration and debugging dump files may be specified on the command
   line.


The server has been successfully tested on the following machines:

    IBM RT PC running ACIS 4.3 (4.3 BSD)
    Sun 3/50 running SunOS 3.5
    DEC MicroVAX II running Ultrix 1.1
    DEC MicroVAX II running Ultrix 2.2



Please direct questions, comments, and bug reports to
Walt Wimer <ww0n@andrew.cmu.edu> or Drew Perkins <ddp@andrew.cmu.edu>.



Sincerely,

Walt Wimer
Network Development
Carnegie Mellon University
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 11:04:52 GMT
From:      moran@tron.UUCP (Harvey R Moran)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: Security mailing list

In article <4752@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <17841@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes:
>>I suggest that the security mailing list be posted to a newsgroup,
>>but with a 60-day delay.
>
>This is a good idea.  In the case of the oft-quoted ftpd bug, the above
>procedure was roughly followed, and it worked.
>-- 
>Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi

    I wonder how many more people out there believe that sites without
access to the security mailing list (or possibly even USENET) should
have their risks increased pretty significantly?  How about us binary
liscense sites?

    If you consider the UNIX community to include both binary liscense
sites and sites with no access to USENET, the *most* such a newsgroup
would accomplish is to make a larger group of privileged characters --
i.e. anyone with access to USENET.  It would *not* get the information
to all concerned SA's.

    Please don't take the 60 day suggestion.  I wouldn't want to be
forced to abandon UNIX and use VMS.  Please note that I do not claim
VMS is any more inherently secure than UNIX, just that DEC doesn't
publish break-in methods around the world.  It wouldn't take many
successful break-in's to convince my management to abandon UNIX, or at
least UNIX with *any* communication with the outside world.

         Harvey Moran       moran@tron.UUCP@umbc3.UMD.EDU
                            {wb3ffv,netsys}!hrmhpc!harvey

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 14:59:44 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus - did it infect "secure" machines

In article <713@tetra.NOSC.MIL>, budden@tetra.NOSC.MIL (Rex A. Buddenberg) writes:
.....
> Link encryption, end-to-end encryption, multi-level secure systems,
> necessary segregation and personnel management/training/leadership
> are all important parts of a classified system and none can do the
> job alone.

You raise some good points that are worth stating another way:  DoD does
not trust computer security that much; their policies rely on administrative
measures to complement technical ones.  Thus, computers containing classified
material are not connected to unclassified networks.  If a link must be
established across such a net (such as the public phone network), link-layer
encryption of the appropriate strength is used; that way, security is
guaranteed by the encryption unit, a much smaller, simpler, and hence
more trustworthy device than an entire computer system.

The Orange Book is well-known; there's a little-cited companion book that
deserves equal attention.  It could be called the Yellow Book; it's title
is something like ``Technical Rationale for Applying the Computer Security
Criteria'', and it explains (among other things) how strong a system must
be for a given mix of user classification levels and data sensitivity.
I don't have the book (and hence the charts) handy, but one example is
worth mentioning:  for data classified as TOP SECRET -- MULTIPLE COMPARTMENTS
(a compartment is something like ``atomic submarines'', ``cryptology'', etc.),
even an A1 system may not have users with less than a SECRET clearance on
it.  Put another way, if uncleared users have access to the system, even
an A1 security rating does not permit storage of highly-classified data
on that machine.  That book makes another point:  the computer's security
is rated higher if it was developed only by cleared personnel.  There is
the assumption, of course, that security clearances are in some way related
to trustworthiness, but too often the question of ``who wrote the code''
is overlooked.  Often, people are the weakest link in the security chain;
if members of Congress can be bought (or at least rented), what do computer
operators or janitors in computer rooms cost?  (Aside:  as someone I know
once remarked about ABSCAM, ``I always knew politicians could be bought;
I didn't realize that I could afford one.'')

		--Steve Bellovin

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 15:19:27 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Shein's ``thought virus'', or, The Risk of Monocultures


From: Richard Mlynarik <MLY@XX.LCS.MIT.EDU>
>Ecologists have known for some time of the many disadvantages of
>single-species ecosystems.  The spread of the Sendmail `worm' is a
>good illustration of the ravages which a single, well-targeted disease
>can inflict upon such an ecosystem.

If that analogy holds then why not apply it to, eg, TCP/IP itself?

Surely if we all ran different network protocols the risk of a virus
would be zero'd immediately.

At any rate, I think we all now understand this ecology analogy, I am
waiting for someone to stand up and say that the concept of standards
is wrong because they encourage viruses and propose active
non-standardization with some plan/proposal for implementation.

Perhaps we can have a conference on pro-active non-standardization
somewhere in Babel...

	-Barry Shein, ||Encore||

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 15:21:21 GMT
From:      grt@twitch.UUCP ( G.R.Tomasevich)
To:        comp.protocols.tcp-ip
Subject:   Stopping a worm with a fairness scheduler

In article <9320003@hpisod1.HP.COM>, renglish@hpisod1.HP.COM (Bob English) writes:
> Since the "damage" that this worm produced was denial of service through
> overload, a fairness scheduler would indeed have prevented the damage,

I do not see how.  The worm forked many times, so how could the scheduler
know that collectively all the processes together were being unfair?  My
understanding was that any given process by itself did not consume much
processor time.  Is that wrong?
Does the scheduler consider all the members of a process-group?
What about sites with processor-intensive applications?  I assume Steve
Bellovin considered these questions.
-- 
	George Tomasevich, att!twitch!grt
	AT&T Bell Laboratories, Holmdel, NJ

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 15:36:24 GMT
From:      ejs@GOLDHILL.COM (Eric Swenson)
To:        comp.protocols.tcp-ip
Subject:   FBI Contact re: November Internet Virus


   Date: 14 Nov 88 20:34:59 GMT
   From: amdahl!pyramid!comdesign!canary!pst@ames.arc.nasa.gov  (Paul Traina)
   References: <8811141359.AB05134@ucbvax.Berkeley.EDU>
   Sender: tcp-ip-request@sri-nic.arpa

   ...

   Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
   f-cking virus was.  You whould think the DDN's security officer would know
   better.

This assumptions is certainly not true.  The tcp-ip mailing list is
for discussions about TCP/IP implementations (and viruses) and many
sites are not the least bit interested in this topic (TCP/IP, that
is).   

-- Eric

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 16:13:58 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   misquoting . . . .

*>>From: stev@vax.ftp.com
*>>>it is bad enough that articles misquote someone, i would like to think
*>>>that most of them dont know they are mucking it up, rather than not caring
*>>>or trying to twist things to prove their point.
*>
*>>Although I agree with you in spirit I'd be happy to ship you a
*>>transcript of CBS's coverage on their evening news report of the
*>>Hacker's Convention a few weeks ago.
*>
*>I think when Stev said "articles" in the above quote, he was just referring
*>to USENET/mailing list articles.  (Stev, beat me about the head and neck if
*>I'm misquoting you :-)  This spawned the discussion of problems with the
*>press.
*
*I think not.  The discussion was about stuff from postings getting
*quoted in the press, specifically something by Van Jacobsen. If it
*is then we've all lost the thread of this discussion.

*	-Barry Shein, ||Encore||

sorry, shelli, barry is correct.


the question here is: should i tell reporter-type-people i am not interested
when they want to talk to me about an article? is it better to try and fail
to get the correct information across, or to just try and avoid it all 
together?


stev knowles
ftp software
stev@ftp.com

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 16:25:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Mail addresses with '%'

Sometime back, Bill Lewandowski asked tcp-ip and sun-spots about the origin
of using per-cent (%) in mail addresses and whether he could use dollar
sign ($) instead, due to some constraints.  I don't know the address of
sun-spots, so this is being sent just to tcp-ip.  Bill tells me that he
got many replies, none of which could elucidate the usage.  To my knowledge,
I introduced it into common use, so here is the history:

At the University of Delaware, we began relaying mail, circa 1979, via
The Rand Corp.  They were attached to the Arpanet and UDel was not. RFC733,
the addressing/format standard in effect at the time, allowed the use of
multiple at-signs (@), which would permit specification of routes.  This would
have been just fine for our needs, except that we could not find a single
mail server or user agent that could handle it.  (The test was not exhaustive,
but after five or ten, it didn't matter, since the addressing scheme had to
be universally acceptable.)

This required that the additional routing information be buried -- i.e.,
Arpanet hosts could be allowed to see only the next-hop host, in this case
Rand.  Any additional route information, usually only one more host, the
destination, had to be invisible.

I checked for the set of characters that were not special to mail systmes OR
TO TERMINAL HANDLERS, ETC.  The mail relay software we had developed (MMDF)
had a telephone link protocol that went through un-modified, line-at-a-time
terminal handlers -- e.g., you did not have to put Unix into raw -- so that
I needed to avoid any operating system-specific special characters.  Only
two or three characters passed this test, with per-cent laying claim to some
degree of being common-sense, since it also is used to mean "in care of",
thereby already being established for one kind of mail processing.

All of this was to be a short-term hack, waiting for addressing standards
to add the ability to specify routing information.  Domain names and the
<@a.b.c, foo@d.e.f> syntax of RFCs 821/822, came a few years later.  
Unfortunately, it was too late.  Some places have actually enacted new
standards that specify semantics for per-cent, officially.  Sigh.

Besides adding complexity, the damn character is upper-case, in that you need
to type shift.  This slows down typing.

Once again we learn that there is no such thing as throw-away code..

Dave

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 16:49:05 GMT
From:      stjohns@BEAST.DDN.MIL (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   FBI Contact re: November Internet Virus

I was going to include the message I was replying to, but decided I
didn't need to reinforce the profanity.

*sheesh*  When Tom said "Not everyone is on TCP-IP" he was referring
to the TCP-IP mailing list.  Now don't you feel stupid?

Mike

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 17:19:07 GMT
From:      jim@cs.strath.ac.uk (Jim Reid)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

In article <8811090956.AA07706@LANAI.MCL.UNISYS.COM> perry@MCL.UNISYS.COM (Dennis Perry) writes:
>.... description of a password generating program
>I stongly encourage everyone to use such a password generator and not
>allow people to generate their own passwords.  

This is probably not a good idea. Programs which generate passwords can
all too easily generate a small number of potential passwords. All that
an intruder needs to do is establish the algorithm used (no doubt based
on a pseudo-random number generator) and then create a list of all the
potential passwords that the program generates. That list - which might
be quite small (say 50-100,000) - could then be encrypted and compared
with the entries in the password file. This would only take a few hours
CPU time to do. If all the user's passwords were forcibly chosen by a
password generating program, the intruder would get every password on
that computer!

Insisting that people use password generating programs (or enforcing
password ageing for that matter) is potentially dangerous. They give the
illusion of security (having frequent password changes and/or "random"
passwords) when in fact the choice of passwords in use is quite likely
to be sub-optimal.

		Jim
-- 
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 17:51:18 GMT
From:      pst@comdesign.cdi.com (Paul Traina)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

From article <557@comdesign.CDI.COM>, by pst@canary.cdi.com (Paul Traina):
> Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
> f-cking virus was.  You whould think the DDN's security officer would know
> better.

You would think that some idiot would think to read twice, examining all
interpretations of a message, before coming back with an obnoxious reply.
Needless to say, some idiot did not.  Apologies to Tom, the DDN et al.

I must have gotten up on the wrong side of the bed that morning, after
reading all of the other flames about this whole mess I had visions of the
keystone cops entering the scene.

------
Paul Traina				To believe that what is true for
{uunet|pyramid}!comdesign!pst		you in your private heart is true
pst@cdi.com				for all men, that is genius.

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 19:03:02 GMT
From:      rich@RICE.EDU (Richard Murphey)
To:        comp.protocols.tcp-ip
Subject:   availability of SLIP under A/UX on MAC?

Hello all,
      Can anyone suggest available  implementations  of  SLIP
 under A/UX on the MAC? A colleague of mine would like to run
 SLIP under A/UX on the MAC, connecting it  to  a  Sun  3/280
 running SunOS 3.4 (BSD4.2).

 I have references about Cornell  University  MacIP,  but  it
 isn't  reported to implement slip. Any other information re-
 garding vendors or availability would  be  most  welcome.  I
 will post or mail a summary if there is any interest.
                                   Thanks, Rich

Richard Murphey, Electrical & Computer Engineering Department
Rice University PO Box 1892 Houston,TX 77251 713-527-8101 X3649
Rice U. is not responsible for any of the opinions expressed here.
Internet:rich@rice.edu Bitnet:crm%rice Uucp:uunet!rice.edu!rich
Do today what you can today...
     That way if you like it, you can do it again tomorrow! -Ziggy

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 19:09:00 GMT
From:      gillies@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: passwords


Password generators are a *nice idea*.  But I wouldn't rush out and
start using them without some thorough testing:

(1) Can you give me *an estimate* of the number of pronounceable
8-character words?  Will this program generate all of them?  If not,
exactly how many different words will it generate?

(2) What if I know, to within 1 minute, the time of creation of the
login (or last password change), and the password/random number
algorithm.  Can I exhaustively search for the password, assuming the
random number generator gets its seed from the clock?

(3) How *random* is the random number generator?  What is the period
of the generator?  What is the approximate "loss of randomness" when
mapping this number onto a password?  (i.e. if the map is not "onto",
on the average, how many seeds result in a given password?)

(4) Are some passwords generated much more frequently than others, by
this password generation program?

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 19:41:01 GMT
From:      cmf@cisunx.UUCP (Carl M. Fongheiser)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <666@hscfvax.harvard.edu> pavlov@hscfvax.harvard.edu (G.Pavlov) writes:
>  Note that DEC claims to have closed the door (before the worm).  As far as
>  I know, Vaxen running Ultrix did ok. 
>
>   greg pavlov, fstrf, amherst, ny

That's true, they did.  However, there are enough Ultrix machines on the
Internet which *don't* use Ultrix sendmail that blanket statements about
the safety of Ultrix aren't necessarily trustworthy.

Why don't we run Ultrix sendmail?  Because currently available releases
of Ultrix sendmail don't know how to talk to domain name servers or process
MX records.  I suspect if you asked a number of other people, they'd give
you the same answer.

Ultrix 3.0 is supposed to handle that stuff, so maybe this will all mean
something in the future.

				Carl Fongheiser
				University of Pittsburgh
				...!pitt!cisunx!cmf
				cmf@unix.cis.pittsburgh.edu
				cmf@pittunix.BITNET

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 20:46:13 GMT
From:      RAD@VAX02.AMS.COM (RichDeJordy@SRI-NIC.ARPA, x295)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

Someone oibjected to the line "Not everyone is on TCP-IP" as part of a request
for expanded distribution of some informational message, saying that everyone
hit by the virus was, and that the DDN either didn't know what they were saying
or they were hiding something.  

I believe the misconception is this.  TCP-IP was meant as the TCP-IP mailing 
list from SCORE, not the Internet itself.
-------

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 21:21:34 GMT
From:      dle@CSL.SRI.COM (David L. Edwards)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

> William J. King <bill@uhccux.uhcc.Hawaii.Edu> writes:
> ...
> Furthermore:
>     3.  lets not celebrate movies such as 'War Games' where the hacker kid
>         breaks the law numerous times AND gets off.
>     4.  Lets engineer better operating systems!
>     5.  More distribution of binary systems and less source code.
>      

While I am tired of this topic, I couldn't let this go by without a
comment.  I agree with 3 & 4 with an emphasis on 4.  But distribution
of more binary is crazy.  Source code was not a real issue in the
current virus EXCEPT that the lack of it kept many sites from
immediately fixing the problems.  A good hacker never needs source to
figure out flaws in a design especially when the flaw is as well known
as the Sendmail one.  All a hacker has to do is come up with a create
use for it.

-dle

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 21:32:47 GMT
From:      joe@stellar.UUCP (Joe Shapiro)
To:        comp.protocols.tcp-ip
Subject:   Request for latest BIND info

I'm looking for information on the newest "non-buggy" version of BIND.
I've heard that the 4.3 version had several bugs and has since been
updated.  Can I ftp a copy of the new stuff?  Where would I find it?

Also, does anybody know what version of BIND sun used in its 4.0 release?

Finally, does anyone know of a BIND information forum?

				Thanks in advance!
					-Joe Shapiro (joe@stellar.uu.net)

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 22:14:43 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Trailers summary

A week or so ago I wrote asking for hints on implementing trailer
reception efficiently.  This posting is a summary of the responses.  I
didn't actually save most of the responses, so I'll just paraphrase.
Thanks to everyone who responded.

Several of the responses didn't really address my question.  I
received several responses telling me that trailers are a lose, and I
shouldn't bother.  Perhaps I wasn't clear about my reasons in my
original posting.  The problem is that my machines (Symbolics Lisp
Machines) are on a network with a number of Vaxes and Suns running
Unix, and we sometimes forget to turn trailers off on these machines.
This causes transient problems when communicating with the
incorrectly-configured machines.  The best, permanent solution I could
think of was to teach the Lispms to handle trailers.

The more useful responses generally described how trailers are
processed in Unix.  The interface between the Ethernet driver and the
network protocol layers is in terms of a linked list of mbufs.  It is
relatively easy in such an implementation to splice the trailer header
ahead of the data portion.  I believe that the comment in RFC-893
about the small amount of code needed to implement trailers assumed
such an interface architecture.  Unfortunately, Genera's Ethernet
driver interface doesn't provide such a structure.

I did receive one response from someone knowledgeable about the low
levels of Genera's networking software (JTW@XX.LCS.MIT.EDU), but I
ended up not using his suggested implementation.  Genera uses objects
called SUB-PACKETS, which are Lisp arrays that indirect into the
Ethernet packet buffers.  There are routines for creating a new
SUB-PACKET offset from the beginning of a given SUB-PACKET; the
Ethernet driver returns a SUB-PACKET pointing past the Ethernet header
to the IP driver, who does an analogous thing when passing the packet
up to TCP, etc.  If the requested offset is negative you can get
access to the portions of the packet buffer preceding the current
layer's data, and it will automatically copy the current packet into a
new buffer if the negative offset would go past the beginning of the
packet.  JTW suggested I use this to open up space before the
beginning of the data and copy the header into it.

I ended up using the simplest implementation, copying the trailer
header into a temporary array, shifting the data over, and copying the
header back in.  I chose not to use the above suggestion because I am
not sure about all the ramifications.  Such an implementation would
overwrite the Ethernet header with the TCP/IP headers, and I'm not
absolutely sure that nothing would ever try to look at the Ethernet
header.  I also wasn't very comfortable with the packet
allocation/deallocation issues.  I may optimize it in the future, but
for the moment I'm being conservative.  I specifically pulled this
operation out into its own routine to make it easy to plug in
different implementations.

My entire implementation is about 200 lines of code.  However, most of
it is support code for interfacing with various system diagnostic
tools, enabling/disabling network drivers, etc.  The actual protocol
implementation is under 50 lines of Lisp code.

After we've run with it for a while I'm going to send it to Symbolics
and request that they include it (or something like it) in future
releases.  Meanwhile, I'll make it available for anonymous FTP on
Think.COM, in the file /public/trailers.lisp.

For the benefit of others who might be thinking of implementing
trailers, I did find an annoying wording problem in the RFC.  In the
Trailer Format section (p.5), the following appears:

   Header length:       16 bits

      The header length field of the trailer data segment.  This
      specifies the length in bytes of the following header data.

I initially interpreted this to mean that the Header length field
specifies the length of the original header.  However, in the
implementation I was testing against, I was getting consistent TCP
checksum errors.  When I turned off checksum checking on my machine, I
noticed that the first four data characters of each TCP segment were
garbage.  I then decided that the Header length field must be the size
of the entire trailer, so I must subtract 4 from it when determining
how much space to allocate at the beginning of the packet.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 23:11:05 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   An Obvious Security Problem?

*A <------------------> M <------------------> Z
*
*(Node M is actually one or more gateways.) Couldn't a bad guy on M
*monitor the TCP/IP traffic looking for Telnet connections and then
*follow through the exchange of login names and passwords, thereby
*capturing a node/login and password pair? (I realize that the
*path from A to Z is dynamic and that this might not always be
*possible.)
*
*Jon Forrest
*Lawrence Berkeley Lab
*FORREST@LBL.GOV

yep. even on a single ethernet someone could use a lan monitor to catch
your passwords as they fly over the net. i believe the Athena people
use Kerberos (sorry about butchering the spelling) to deal with some
of this. (or at least they could . . . . .)

network security is a very big fish to try and fry. basically, the 
whole system would have to be re-done. i would think that we would
want to use diffrent "well known ports" for the new secure versions.

and forget IP security. if the packet is on my wire, i can see it.
IP security is only good if all the machines respect it. ( a friend
told me the only real-world use he saw for IP security was internet 
wide poker games).

perhaps a kerberos type of scrambling on a host basis rather than 
a connection basis (the host has a public key assigned to it). 
if you try this, you can skip messing with the programs, and put
the unscrambler between the network code and the application. (
i suppose you could even make it an IP option. then you could even
protect the tcp layer from prying eyes.) this *will* add to the overhead,
though. i havent really thought about this alot, and am not sure if
it is the "right thing to do" yet or not. ah, well, too late now,
i suppose . . . (the "purists" will probably not like this.)

(*sigh*)

stev knowles
ftp software
stev@ftp.com
617-868-4878

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 23:24:59 GMT
From:      mhw@wittsend.UUCP (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards,news.admin,news.sysadmin,news.groups
Subject:   comp.security - LET'S DO IT!  CALL FOR VOTES


     I am posting this to multiple groups because there are discussion threads
in most of them on the same topic and seemingly oblivious to each other.  The
topic, of course, is the hot one of the day, SECURITY.  As best I can figure
out, there are two security lists announced in news.sysadmin.  The groups
in comp.what-ever are unaware of these groups and are asking me for information
on how to join them.  The various discusions interrelate but seem to be going
off on different tangents.  All would benefit from a co-ordinated discussion.
I have heard all the reasons for "not" forming a comp.security group (some
are valid, most are bullsh*t).  I agree with the principles behind the two
mailing lists having different validation levels.

     Proposal:

     1) Create comp.security for INTELLIGENT discussion of REASONABLE security
issues.  i.e. - no articles of the "I found this and I can't fix it" sort.
Assume that you don't broadcast sensitive information on an unsecure channel!
That's what the two mailing lists should be for and we are supposed to be
semi-intelligent individuals.

     2) Administrators for the two mailing lists in news.sysadmin
	- Please cross post to:
		comp.protocols.tcp-ip
		comp.unix.questions
		comp.unix.wizards
	Cross posting doesn't cost that terribly much and you have a large
	legitimite clientele there.

     3) Posters - same thing as 2

     Security issues cross many topic boundries.  They apply not only to
sysadmins or to unix or to wizards and certainly affect more than tcpip.  Until
we have a central spot to discuss these issues, make sure your articles get to
the people who can benefit by them.

     Security is being discussed right now on many of these groups.
Creating a new group will not compromise the integrity of the discussions any
more than where they are taking place right now.  If some of you are still
antsey about a group airing security issues then MODERATE the damn thing but
let's get the show on the road.  Let's vote on a new group and whether it
should be moderated.  We can discuss what is appropriate for the group and
for the two mailing lists IN THE NEW GROUP.  BUT LET'S VOTE!

     Finally, if we can move the security issues to their own group, we will
not only get the information in one spot and treat it uniformly, but we
might even cut down on the NOISE level in the other groups so all of us can
get back to the non-security topics in those groups.  It's getting harder
to see the forest through the brush in some spots!

     If no one else wants to stick their head above the barricades, then I'll
tally.  Send me the votes.  I ain't fansey.  I don't have anything on hand
to do the job automatically.  I'll count them by hand an post interesting ones
so EMAIL don't post unless you want to discuss.  Anyone else rather handle it
then that's just fine too.

     EMAIL:

	if( domain_supported )
		to = "mhw@wittsend.UUCP"
	else
		to = "...gatech!galbp!wittsend!mhw"

     Thank You.

----
Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 88 23:33:46 GMT
From:      nate@altos86.UUCP (Nathaniel Ingersoll)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

In article <557@comdesign.CDI.COM> pst@canary.cdi.com (Paul Traina) writes:
:From article <8811141359.AB05134@ucbvax.Berkeley.EDU>, by TomZ@DDN1.ARPA:
:[deleted....]
:< PLEASE GIVE THIS MESSAGE MAXIMUM DISTRIBUTION; NOT EVERYONE IS ON "TCP-IP"!
:
:Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
:f-cking virus was.  You whould think the DDN's security officer would know
:better.


Note that the posting was to the newsgroup comp.protocols.tcp-ip
                                                          ^^^^^^
and that 'not everyone is on "TCP-IP"' meant that it was quite likely
that not all interested parties read this group.


-- 
Nathaniel Ingersoll
Altos Computer Systems, SJ CA
	...!ucbvax!sun!altos86!nate
	altos86!nate@sun.com

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 00:55:55 GMT
From:      mo@prisma.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Security through incompatibility

The easiest way to be secure (possibly even A1!) is to
just cut off the power cord.

This does have some minor drawbacks, however.

	-Mike

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 01:43:58 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   System security & networks & vendors

A while back, I was working on IP option support for PC/TCP, and re-discovered
another "bug that everybody knows about" in 4.2 IP option handling.  I have
demonstrated an ability to crash a number of 4.2-derived commercial products
from far, far away, with legal IP datagrams that gateways probably won't
filter.  I posted about this, asking if people wanted me to test against
their systems, and got a total of about 3 replies, none from vendors.

Another area that "everybody knows about" is TFTP.  Our Unix's TFTP is
picky about who it will take connections from (as a locally-installed side
effect of using a TFTP that conforms to the specifications, instead of the
broken 4.2 version the vendor gave us).  Who else has taken care of this?

I first heard of the FTPD bug at Interop in December, 1987.  None of the
people who were talking about it were giving details, because they were
afraid someone would use it before it could be fixed.  Hi ho.

If I can get sued for negligence for not padlocking the gate to my home's
swimming pool, I don't think you can call it justice to imprision or even
fine Mr. Morris.

There is a lot of knowlege out there, but many vendors don't share in it,
because they are isolated, or understaffed, or trying to put out other
fires first.  RFC 1009 and the "Requirements for Internet Hosts" draft
are a good start, but it will take sophisticated, energetic customers
to make the network an equal priority with the text editor for most vendors.

I had hoped that the Interop show-net would be a place where we could get
some serious testing done, but it came up too late in the day before the
crowd showed up, and many vendors didn't bring their coders.  Some people
did testing of upper-layer protocols, but I couldn't hack IP options, because
the result of my finding a bug was quite likely to be a system crash....

James VanBokkelen
FTP Software Inc.

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 02:39:20 GMT
From:      bart@videovax.Tek.COM (Bart Massey)
To:        comp.protocols.tcp-ip
Subject:   Re: Unix 8-character passwords

In article <8811090812.AA13935@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
> [ a quite stylish explanation of why UNIX passwords are currently 8 chars max]

What I think I'd rather see is just doubling the size of the password field
in /etc/passwd, and encrypting the 2 8-char chunks of a 16-char password in
two steps.  This way, you really would greatly increase the security of
reasonable-length passwords, and I don't really see any disadvantages over
Chris's scheme of hashing bits together...  Also note that storage capacity
is growing like crazy, and one can almost construct a reasonably fast
crypt() inversion dictionary on e.g. optical store even given the two salt
chars (at least by my calculations, which are probably totally hosed.. :-).
This would push that problem into the future again...

This probably isn't an appropriate topic for TCP/IP.  I'm moving it to
misc.security...

				Bart Massey
				..tektronix!reed.bitnet!bart

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 02:40:45 GMT
From:      dtynan@sultra.UUCP (Der Tynan)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert Morris

In article <168@heart-of-gold>, jc@heart-of-gold (John M Chambers) writes:
> 
> OK, so you write up a little demo and send it around.  What happens?  Unless
> you are perfect, and your code runs without bugs on all systems (including
> some you've never seen), your example will do something like rtm's worm,
> and half the world will be calling for prosecution.
>
> From:	John Chambers <mitre-bedford.arpa!heart-of-gold!jc>

Huh?  Why is it everyone seems to think that because of a simple bug, RTM's
code ran amok on Internet.  WITHOUT the bug, the infection would have spread
to *more* systems, and not have been noticed.  I fail to see that if I wrote
a 'little demo', that had a bug, it would suddenly turn into the Master
Control Program (courtesy of 'Tron'), and go screaming off into the ether.

A 'demo' program DOES NOT need to try THREE different ways of infecting a
system.  It does not need to have facilities for up to TWENTY different
machine types.  I also fail to see the connection between 'no-one listening'
and the 'right' to release a worm on the community.
						- Der
-- 
	dtynan@zorba.Tynan.COM  (Dermot Tynan @ Tynan Computers)
	{apple,mips,pyramid,uunet}!Tynan.COM!dtynan

 ---  If the Law is for the People, then why do we need Lawyers? ---

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 03:18:26 GMT
From:      sysop@pinn.UUCP (Andy Johnson)
To:        comp.protocols.tcp-ip
Subject:   RCP Request

We are planning to use rcp to copy files from one system to another over
Ethernet.  Does anyone have a copy of some public domain rcp utility or
perhaps the protocol for rcp.

Your help is greatly appreciated.  Please post, or leave me mail.

Thanks.

{your favorite backbone...inhp4 perhaps}!codas!novavax!pinn!sysop

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 03:49:31 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: FBI Contact re: November Internet Virus

> pst@canary.cdi.com (Paul Traina) writes:
> Sigh.  ... not everyone is on "TCP-IP" ...?  Everyone who got hit by the
> f-cking virus was.

	I think what the man was trying to say was that not everybody is on
the INFO-TCP-IP mailing list.  At least that's how I interpreted it.
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 04:39:08 GMT
From:      haynes@ucscc.UCSC.EDU (99700000)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards,news.admin,news.sysadmin,news.groups
Subject:   Re: comp.security - LET'S DO IT!  CALL FOR VOTES

There is a misc.security already - don't believe there has been anything
in it for quite some time.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Nov 88 9:42:46 EST
From:      "Benjamin J. Woznick" <bjw@WILMA.BBN.COM>
To:        lars@ACC-SB-UNIX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, lars@ACC-SB-UNIX.ARPA
Subject:   Re:  Worms and fixing blame
> 
> I work as a customer service manager at a TCP-IP networking company.
> My wife is a corporate MIS person. She asked me about technical aspects of
> the worm, and expressed a wish to see severe criminal charges pressed against
> the perpetrator. IU asked her on what grounds since there apparently was no
> provable malicious intent and no "real damage". rather, I suggested, SUN
> Microsystems might be liable for releasing operating systems software with
> undocumenated functionality creating a security hole, and companies and/or
> government institutions that had chosen to run poorly documented software
> available "for free" from a research facility should accept responsibility
> for whatever befalls them if they do not review the software that they make
> themselves dependent on.
> 
> I suggested as a parallel, that no company would be likely to install without
> test and review a payroll package found floating around on a computer bulletin
> board, and if they did, and the IRS sued they for improper calculation of
> withholdings, they would have only themselves to blame. I think she agreed.
> 

Are you suggesting that if I, as an employee of some company, discover
some method for fiddling the payroll system to get paid three times my
salary, that all is fair in love and war?  While there may be some
vendor liability, whoever loosed the worm also has some liability, no?
	Ben Woznick
-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 05:00:05 GMT
From:      eichin@ATHENA.MIT.EDU (Mark W. Eichin)
To:        comp.protocols.tcp-ip
Subject:   Re: Crackers and Worms

>Date: 13 Nov 88 23:24:04 GMT
>From: elsie!ado@cvl.umd.edu  (Arthur David Olson)
>> I'll bet the KGB are laughing their asses off.
>That depends on whether kremvax was running 4.3BSD or Ultrix.
 % bindtest
> hkremvax.mit.edu
res_mkquery(0, kremvax.mit.edu, 1, 13)
QUESTIONS:
        KREMVAX.MIT.EDU, type = HINFO, class = IN
ANSWERS:
        KREMVAX.MIT.EDU
        type = HINFO, class = IN, ttl = 21600, dlen = 16
        CPU=VAXSTATION
        OS=UNIX
> 

Actually, it is a VS2000, running 4.3BSD+NFS (MIT Project Athena
modifications...) It was not infected (in fact, I used it throughout
the infection, on the MIT decompiling team.)

				Mark Eichin
			<eichin@athena.mit.edu>
		SIPB Member & Project Athena ``Watchmaker'' 

ps. Yes, I chose the name just to be able to answer such a question. :-)

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 07:36:52 GMT
From:      steve@polyslo.CalPoly.EDU (Steve DeJarnett)
To:        comp.protocols.tcp-ip
Subject:   Re: WANTED: disassembled copy of internet virus

In article <5011@polya.Stanford.EDU> waters@umunhum.Stanford.EDU (Jim Waters) writes:
>  I was recently informed that some folks at Purdue did a real nice
>job of symbolically disassembling the binary part of the recent
>Internet virus.  Unfortunately, I haven't been able to find a copy
>locally.  Is there anyone out there who snagged a copy who would be
>kind enough to mail it to me?

	As of late last week, Purdue had voluntarily removed their disassembled
source for the virus from public areas.  It was reported in the papers that 
NCSC (National Computer Security Center) had called/emailed Spaf and asked him
to remove it so that other people wouldn't be tempted to study it and try to
copy some/all of it for use in another virus.  (Private mail also confirms
this story, as I recall).

	So, while it would be great to look at the real source (I have seen the 
disassembled source, and unless you're really in to reading VAX assembler, 
it's not that exciting), the chances of this occuring are about ZERO.  About
the only thing I can suggest is wait for the RFC/whatever that some people are
working on now (so I hear).

-------------------------------------------------------------------------------
| Steve DeJarnett            | Smart Mailers -> steve@polyslo.CalPoly.EDU     |
| Computer Systems Lab       | Dumb Mailers  -> ..!ucbvax!voder!polyslo!steve |
| Cal Poly State Univ.       |------------------------------------------------|
| San Luis Obispo, CA  93407 | BITNET = Because Idiots Type NETwork           |
-------------------------------------------------------------------------------

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 10:38:01 GMT
From:      NETWORK@FRSAC11.BITNET
To:        comp.protocols.tcp-ip
Subject:   Analyzer

Date: 17 November 1988, 10:28:29 GMT
From: NETWORK  at FRSAC11
To:   tcp-ip@sri-nic.arpa

We would need all comments and appreciations on Ethernet Analysers.
We would like to monitor, debug, quantify and trace traffic on Ethernet,
using TCP/UDP-IP, DECNet, XNS & other to come.
Full capture ability is a must (10 MHz cable, with packets as close as
a Sun can provide...)
Ease of programming is of some concern.

Current known products: Micom-Interlan, Sniffer (Ungermann Bass ?),
Excelan & HP (The last one is the only one speciallized instrument, all
other are PC-AT cards and software)

Comments on the use of a Compaq 386 for above use, if not the HP solution,
most welcomme. (Compaq 386s, Portable, 386e ???)

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Nov 88 10:38:01 GMT
From:      NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Analyzer
Date: 17 November 1988, 10:28:29 GMT
From: NETWORK  at FRSAC11
To:   tcp-ip@sri-nic.arpa

We would need all comments and appreciations on Ethernet Analysers.
We would like to monitor, debug, quantify and trace traffic on Ethernet,
using TCP/UDP-IP, DECNet, XNS & other to come.
Full capture ability is a must (10 MHz cable, with packets as close as
a Sun can provide...)
Ease of programming is of some concern.

Current known products: Micom-Interlan, Sniffer (Ungermann Bass ?),
Excelan & HP (The last one is the only one speciallized instrument, all
other are PC-AT cards and software)

Comments on the use of a Compaq 386 for above use, if not the HP solution,
most welcomme. (Compaq 386s, Portable, 386e ???)

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 10:58:52 GMT
From:      torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen")
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

>Perhaps the Computer Science programs should:
>    1.  require students to take ethics, humanities and social science
>        courses.

Computer science programs I know of already do that. That's still a part
of a college education.

>    2.  restructure their programs such the early years are not simply
>        set up to flunk out all but the 'compulsive' hackers.  Fortunately
>        these programs do NOT succeed, and ' a few good men & women' get by.

I believe the current tendency is to spend the first few years teaching
mostly algorithms and data structures. I'd think that it's hardest for the
so-called hackers to make it through the first few years. At least it is if
they follow a normal curriculum.

>Furthermore:
>    3.  lets not celebrate movies such as 'War Games' where the hacker kid
>        breaks the law numerous times AND gets off.

Why not? I thought that was a rather delightful movie and if you think about it,
it had quite a few *good* points. Besides, all those blinking lights was a nice
touch :-)

>    4.  Lets engineer better operating systems!

We are. Look at how we've advanced in functionality. It's not all that
surprising that a few holes exist. Actually, I'm more surprised that there
haven't been more problems than this. Making a system secure is pretty easy.
If you don't mind throwing functionality overboard. Let's learn what can be
learned from this incident, fix the holes and go on. Hopefully, vendors and
researchers/developers alike will be a little more careful about what they
release in the future.

>    5.  More distribution of binary systems and less source code.

I trust you're not serious..... Let's get more source systems out there and then
get people to work actively on breaking them. With as much information as
possible. That way we might make some real gains. 

						Torben

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 11:03:47 GMT
From:      dkhusema@faui49.UUCP (Dirk Husemann (Inf4 - hiwi),0.058I4,7908,09131-302036)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: SF columnist on the Worm, suggests new terminology.

From article <47235@pyramid.pyramid.com>, by csg@pyramid.pyramid.com (Carl S. Gutekunst):
> In article <457@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes:
>>Jon Carrol's Wednesday column in the SF Chronicle is an interesting
>>example of the level of "popular journalism".
> 
> And Dave's posting is an interesting example of copyright violation. It is
> AGAINST THE LAW (to say nothing of highly inethical) to reprint coyrighted
> works without the permission of the copyright holder. Newspaper articles are
> no exception.

	I'm not so sure about that: At least in West Germany the copyright
laws state that news (as printed in newspaper articles) receive protection
only for a very limited time (~ 2 days or so). As West Germany signed the
international copyright treaty, I can imagine that this rule originates there.
The USA did sign this treaty recently, also, thus it could be the case that
the copyright protection for news is restricted in the US also!

> 
> I asked Dave (via e-mail) to cancel the posting; he refused. I have cancelled
> it myself.

	Might have been a little bit too early ...

> 
> <csg>

------------------ Smile, tomorrow will be worse! --------------
Email:	dkhusema@immd4.informatik.uni-erlangen.de
Or:	{pyramid,unido}!fauern!faui44!dkhusema
Mail:	Dirk Husemann, Aufsess-Str. 19, D-8520 Erlangen,
(Home)	West Germany
(Busi-	University of Erlangen-Nuremberg, Computer Science Dep.,
ness)	IMMD IV, Martensstr. 1, D-8520 Erlangen, West Germany
Phone:	(Home) +49 9131 302036,	(Business) +49 9131 857908
-- Beam me up, Scotty, there's no intelligent life down here! --
--------------- My opinions are mine, mine, mine ---------------

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 13:31:13 GMT
From:      cosell@bbn.com (Bernie Cosell)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards,news.admin,news.sysadmin,news.groups
Subject:   Re: comp.security - LET'S DO IT!  CALL FOR VOTES

In article <5493@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes:
}There is a misc.security already - don't believe there has been anything
}in it for quite some time.


Just so -- the call for comp.security is pretty much misguided.  The problem
with misc.security is that the moderator moved machines and, apparently, has
not yet been able to reestablish connection to the news world, and so the
list has been moderator-blocked for something like eight months now.
There are, I'm quite sure, LOTS of postings backed up (I know for sure that
hobbit is holding onto two or three of mine).

Instead of rushing off to start a new newsgroup, why don't we just unmoderate
misc.security and see how it works moving all of the security stuff OUT of
the random newsgroups for a while.

   __
  /  )                              Bernie Cosell
 /--<  _  __  __   o _              BBN Sys & Tech, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_             cosell@bbn.com

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 14:53:44 GMT
From:      hubcap@hubcap.UUCP (Mike Marshall)
To:        comp.protocols.tcp-ip
Subject:   computer press & the worm...

I was looking forward to discussions of the worm in the computer press.
All (most) of the discussions in the popular press I saw were botched, but
then I don't really blame "The Greenville News" or whatever for getting the
technical details wrong.

I got "UNIX Today!" yesterday and was dissapointed...

"Usenet users, however, were actually safe from the particular worm 
 that hit last week. The worm required TCP/IP to function, and usenet 
 is based on uucp..."

 Of course the worm didn't attack USENET, but the reasons stated above
 don't belong in a magazine about UNIX...  I am posting this from an 
 NNTP site.

"Ultrix doesn't include the send-mail feature of of Berkeley 4.3..."

 Then what the heck is this configuration file that's been driving me
 crazy? 1/2 :-)...

"... it would zero out its argv[] parameter block..., effectively making the 
 operating system give it a (sh) as its argv[0]..."

 RTM crammed the string "(sh)" into the argv list so that his worm wouldn't
 stick out like a sore thumb, UNIX didn't do it for him.

These are little things, but I'll have a hard time in the future 
accepting the stuff I read in "UNIX Today!" as credible.

-Mike Marshall      hubcap@hubcap.clemson.edu

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 1988 20:25-EST
From:      CERF@A.ISI.EDU
To:        sei!pdb@PT.CS.CMU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Packet filtering for 4.3BSD ?
Pat Barron,
by whom have you been told to support filtering of packets
baseed on UDP and TCP port numbers and source/dest IP addrs?

Thanks,

Vint
-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 16:12:43 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   password aging (from worm discussion)


Although I support the other proposals I will argue that shadow
password files are a bad idea (actually, I'm not too enamored with
password aging, others have argued against this questionable idea.)

It means that if, for any reason, you believe your password file has
been let out you will have to admit that your security is compromised
and, for starters, have everyone change their password (then spend
your time "improving" the file's security etc.) You better also
develop effective means of detecting whether anyone has read your
password file or printed it out and not disposed of it properly.

You're turning the file into pure gold.

I still am confident that with methods like password changing programs
which try to prod the user to choose a reasonable password AND
education of users (perhaps backed with some internal enforcement,
such as removing accounts that insist on trivial passwords, whatever
your organization needs) the current publicly readable file affords
MORE security than a shadow file.

I sincerely hope that the community consider this matter before it
becomes some sort of standard. I believe it compromises security by
creating more problems than it solves, complicates security
administration by requiring strict controls on who can access the file
and creates new security crises when the file is believed to have been
read by someone unauthorized.

I fear that everyone is currently running willy-nilly trying to find
*something* to do in response to this worm, let's not, in the heat of
the moment, commit to something that actually makes matters worse.

	-Barry Shein, ||Encore||

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 16:31:17 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Worms and fixing blame


From: lars@ACC-SB-UNIX.ARPA (Lars J Poulsen)
>As a minumum, everybody who buys system software should add the following
>clause to their purchase orders: "The system shall identify each user by
>a unique user identification, and password validation shall be used to
>ensure that no unauthorized access occurs". This will ensure that you can
>hold the vendor liable for losses you might incur in a situation like this.

Does this make sense? Does sending mail without a password constitute
"unauthorized access"? How about being able to transfer a file to a
publicly writeable scratch area? How about if it fills that scratch
area and cripples the system, or fills a mail spool causing mail to be
lost? How about being able to finger someone? What if someone merely
ties up networking bandwidth soas to cause you major nuisance? What if
they merely dial-up your system with N modems and tie up every
available dial-up you have? Are all those the vendor's fault? What if
they eavesdrop on your packets going across an ethernet? etc etc.

What exactly is "unauthorized access"? Whatever inconveniences you as
an afterthought?

I don't believe that this past problem would have been an issue under
your proposal, the system certainly demands a password for login
access. You're too vague, the bug exploited was that a particular mail
message text could allow an "undesired" program to run (as opposed to
many, permitted and necessary, "desired" programs regularly run on
behalf of mail messages.)

The problem is that user's security needs are widely varied. Oh, I
agree that this past worm entry was an obvious botch, but let's talk
in more general terms, at some point we all agree an error occurred
but the important thing is to agree on intent.

It's easy to say something like "reasonable security" in a contract or
some other such mom and apple pie truism, but what does it mean?  How
can we determine if the contract has been breached?

What are needed are reasonably detailed security requirements (the
military certainly has these although I doubt they would correspond to
most users.) A test suite would be very helpful which would reflect
these needs.

But that would require real work, and cost real money...

Let's face it, one person's security requirement is another's damned
nuisance.

	-Barry Shein, ||Encore||

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 17:08:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: SF columnist on the Worm, suggests


/* Written  2:50 pm  Nov 15, 1988 by csg@pyramid.pyramid.com in p.cs.uiuc.edu:comp.protocols.tcp-ip */
In article <457@gonzo.UUCP> daveb@gonzo.UUCP (Dave Brower) writes:
>Jon Carrol's Wednesday column in the SF Chronicle is an interesting
>example of the level of "popular journalism".

And Dave's posting is an interesting example of copyright violation. It is
AGAINST THE LAW (to say nothing of highly inethical) to reprint coyrighted
works without the permission of the copyright holder. Newspaper articles are
no exception.

I asked Dave (via e-mail) to cancel the posting; he refused. I have cancelled
it myself.

<csg>
/* End of text from p.cs.uiuc.edu:comp.protocols.tcp-ip */

The fact is, it is *NOT* illegal to reprint copywritten material unless
the author specifically denies permission. I haven't seen a newspaper
ever that does so. If Dave were getting some financial advantage by
posting the article, it would be copyright violation. Quoting newspaper
articles for purposes of discussion/comment simply isn't something that
the copyright laws of the U.S. were designed to prevent.


Johnny Zweig
University of Illinois at Urbana-Champaign
Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 17:41:48 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   passwords


Henry, you point out several interesting points that are not too
difficult to solve.  The latter one about writing down passwords is
relatively easy.  The passwords are pronouncable and easily remembered.
Now, you may argur that since you did not think it up, it is too hard,
but in practice, this is not a problem.

The first potential problem is the log on name.  Los Alamos does not
use 'names', but user numbers, which are assigned to employees and
people authorized for accounts on the system.  If you know something
about Los Alamos or people who work there you know a little about
the system, an outside hacker most likely would not.  In fact, we have
watched many hackers (all login attempts are logged) try all kinds of
names, but none with the right 'type' of number.

One of the things I did not say in my previous message (I was not trying
to give a definitive statement about how Los Alamos does things, since
I am no longer employed there) is that the first thing a user has to
get right is is login name.  This can be done many times, but since
attempts are logged, it soon becomes apparent that someone is trying
to get in.   When I left we were thinking about makeing the loging
of login attempts a real-time system which would alert the operations
desk which could then take action to shut down the port under attack.
So, a user would not normally be denied service except for the case
where his name was known to the hacker, or he guessed a valid user number
at random.  In addition, if a hacker were to get in, he still must 
get passed the account checking, i.e. does he have an account with
money in the bank, and then he must logon to the machine itself, for
which he may or may not be authorized.

Again, there are lots of things we can NOT do, but that doesn't help
much.  Reasonable passwords are a good investment in system management.
Password aging is a good investment in system managment.  To remove
these responsibilites from humans and entrust them to machines would
make it even better, since now we only have to worry about losing
a 'smart' card, and that can be reported and logged in the system.
In addition to a smart card, some of the type of things I was looking
at at DARPA was to usa biological information to verify that the person
useing the equipment was authorized.  Retina scans from 3-4 feet
now seem doable and would be non intrusive.  So, the general ideas
of useing something one know, something one has (object), and something
one is (bio) would make a fairly tight system.  (please spare me the
objections of plucking out someone's eyes to defeat the system, dead
eye don't focus and retina scans pick that up too!)

dennis

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 19:28:05 GMT
From:      ron@ron.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

Great, denial of serivce is almost as bad.  We need some obnoxious
person causing all the users to be blacklisted.  I typed bad passwords
to perry on mcl three times, I guess you either can't read this or
you don't have that code turned on.

-Ron

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 19:29:33 GMT
From:      bet@dukeac.UUCP (Bennett Todd)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

In article <1801@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes:
->In article <2120@kalliope.rice.edu>, hd@kappa.rice.edu (Hubert D.) writes:
->> We've been looking at software to connect our PCs and MACs
->> to SUNs and [...]
->	Huh?  If you let anyone on your Ethernet cable with a PC you've
->	basically just given up any hope for security.  Even active
->	methods like Kerberos will not protect you from people who
->	just listen to eg TCP sessions on the cable.  

Are you sure about that? I thought I sorta understood Kerberos, and that it
was distinguished as the only authentication protocol that was robust and
secure in the face of hardware eavesdropping, interception, and injection of
messages. The "dialog" is pretty fun reading, and explains the contortions --
and the reasons for going through the contortions -- pretty clearly.

-Bennett

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 19:43:19 GMT
From:      mfidelma@bbn.com (Miles Fidelman)
To:        comp.sys.mac.programmer,comp.protocols.tcp-ip
Subject:   IP for the MAC (summary)


Folks,

Here is a summary of my query re. IP for the Mac.

1. Apple will be releasing a TCP/IP driver package in January (now in
beta) that should be accessable via system traps.

2. Kinetics is shipping a product called "TCPort" that is a toolkit
for writing TCP and IP applications. It's based on the Umich TCP/IP
code (see below).

3. Umich has developed a set of TCP, IP, and UDP drivers, plus a few
other goodies (e.g. nameserver access). They're available via
anonymous FTP to citi.umich.edu, and live in the directory 
citi-macip/release2.0B2. Note: these are huge files (several megs) that
must be decompressed(!) into even huger files using a special program
that also lives in that directory. The README file gives details. You
need MPW to use this stuff.

Miles

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 20:58:12 GMT
From:      ccs@mtune.ATT.COM (Chuck Schwing)
To:        comp.protocols.tcp-ip
Subject:   Re: shadow passwords?

In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
>It seems the phrase `shadow password file' is not well known, so here
>is a definition:
>
>It means the encrypted passwords themselves (and any other `sensitive'
>information) is not kept in /etc/passwd, which is readable by everyone,
>but rather in some other file that is not readable except by root
>(and/or by other privilege of your choice).  The typical implementation
>is to rename the real password file /etc/passwd as something else
>(e.g., /etc/pw.shadow), and replace /etc/passwd with a copy that has
>the password field replaced with something unusable (`*').  Programs
>that really need a user's password run privileged, and are changed to
>refer to the shadow file; others use the usual file, but have no access
>to the encrypted password.  Updates must happen to both files.


This is all true.  A good idea, however is to leave the passwd entry in the original
/etc/passwd either the original root password or leave the password field in the 
original nulled out.

This will allow root to get back in should the unthinkable happen:

Your /etc/shadow file gets blown away.

This little scheme will only work if you have source code for login and make it
look in either /etc/shadow or /etc/passwd when checking a user's password 
entry.
Obviuosly, I guess everybody doesn't have the source so this
tip is not of real general use, but for those who do have the
source code, this can save real headaches at some future date.


Take care,
Chuck Schwing		ccs@mtune.att.com

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 21:58:43 GMT
From:      matthews@udel.EDU (John Matthews)
To:        comp.protocols.tcp-ip
Subject:   Does a RARP utility exist?

Can someone tell where I might be able to find a utility that uses
the RARP (Reverse Address Resolution Protocol) to find the IP adresses
of ethernet equipment via their ethernet address?  Can someone at the
same time tell me where I can find the source to the latest version of
arp?  While I'm at it, does anyone know if there exists such a protocol
that does a broadcast and asks all equipment connected to a given ethernet
to respond saying that they are there and powered up?
					John Matthews
					Matthews@UDEL.EDU
					Matthews@Research.ATT.COM

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 22:48:46 GMT
From:      ejs@GOLDHILL.COM (Eric Swenson)
To:        comp.protocols.tcp-ip
Subject:   FBI Contact re: November Internet Virus


   Date: Wed 16 Nov 88 15:46:13-EST
   From: RichDeJordy@goldhill.com, x295 <RAD@vax02.ams.com>

   Someone oibjected to the line "Not everyone is on TCP-IP" as part
   of a request for expanded distribution of some informational
   message, saying that everyone hit by the virus was, and that the
   DDN either didn't know what they were saying or they were hiding
   something.

   I believe the misconception is this.  TCP-IP was meant as the
   TCP-IP mailing list from SCORE, not the Internet itself.
   -------

Interesting, the above message (cc'ed to the tcp-ip mailing list) claims to
have come from a RichDeJordy@goldhill.com.  There is no such user here at
Gold Hill and no such user on any of our machines.  Whoever sent this message
has a machine whose mailer does the wrong thing when trying to reply to a 
message.  Who sent this message anyway, was it rad@vax02.ams.com?  If so,
please check your mailer.

-- Eric

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 88 22:55:46 GMT
From:      minshall@kinetics.UUCP (Greg Minshall)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun to IBM Full Screen Operation

From article <XX.64.10677.594936074@XX.QMAIL>, by jwegl@DDN-WMS.ARPA (John Wegl):
> We have a Sun 3/280 connected to the DDN using the Sun provided
> DDN interface.  On the back side of the Sun we have a number of
> WYSE terminals emulating VT-100s.  We are trying to connect from those
 ...
> to change our TELNET from character mode to line mode.  However, once
> we are there we lose some functionality--mainly, we can't get cursor
> movement using the arrow keys; and using shift F3 does not do a screen
> print but just echoes.  Those are the only problems we have identified
 ...
> Any solutions or suggestions are welcome.

One solution is to run "tn3270" on the Sun.  Tn3270, which emulates a
3270 terminal, allows terminals (and the sun console itself) to be used
as 3278 terminals on the IBM mainframe.

You can get ahold of tn3270 from the Campus Software Office at UC Berkeley,
(415)643-7201.

Greg Minshall

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 00:47:31 GMT
From:      beepy%commuter@Sun.COM (Brian Pawlowski)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.misc,comp.windows.news,comp.windows.x
Subject:   Connectathon for ONC/NFS, X11 and NeWS Annual Testing


To NFS/ONC, X11 and NeWS Developers,

	Sun Microsystems, Inc. is hosting the annual Connectathon
event in February 1989. Connectathon was set up for developers of ONC
and NFS implementations to test against other implementations.
(NFS - Network File System, ONC - Open Network Computing).
For the first time this year, X11 and NeWS window system testing
will also be performed.

	Vendors send their engineers and machines to test
interoperability of with all other vendors present.  It's an
unsurpassed opportunity to test your completed implementation
or implementation in progress in a large multivendor, heterogeneous
environment.  Last year, we had approximately 50 implementations
of ONC from over 40 vendors for a week of intensive testing.

	Connectathon also represents a unique opportunity
developers to share ideas while testing their implementations.
As in previous Connectathon's we will be running technical tracks,
which in the past included presentations on NFS testing, NFS
implementations (UNIX and non-UNIX), and the impending NFS protocol
revision.

	Connectathon '89 will be held on February 13-17 near
Mountain View, CA. The week prior is available for set up of machines
at the site. February 20 and 21 are available for press and
marketing relations for those vendors/developers who want to
show their product.

	Registration is underway, and space is quickly filling up.
There are two more weeks of extended registration time left! This
year a registration fee of $1000 is in effect, to defray operating
costs for the event.

	Connectathon is open to all ONC/NFS, X11 and NeWS developers.
For more information, and registration materials, please send email
to Linda Cwiak (lhatt@sun.com) as soon as possible. Or call at
(415) 336 4717.

	If you are working on an NFS/ONC implementation and will be
unable to attend Connectathon, we'd still like to hear from you.
There are several events each year of interest to NFS/ONC developers
(ONC Vendors Group Meeting, BOFs at USENIX and Interop conferences,
and multivendor demonstrations) which we keep interested vendors
posted on.

	If you know of someone who may not see this posting but
may be interested, please pass this on.

Looking forward to seeing you in February!
Brian Pawlowski

P.S.	Attached to this message is a sample of ONC/NFS bugs that
	were found at Connectathon '88.

------------------------------------------------------------------------

The unique environment at Connectathon turns up different types of bugs:

1) Implementations do not always follow the protocol:

Bug #11
Description:
On Vendor_X's server, READDIR returns einval(22) when buffer size is 512.  
Buffer size = 1024 works.  This server doesn't really allow clients to 
specify buffer size.

2) Some problems only occur when two particular vendor's machines try 
to communicate:

Bug #25
Description:
/bin/pwd returns error "directory un-readable" when current working
directory is Vendor#1 filesystem over NFS.

Coments:
To recreate:
Mount Vendors#1's filesystem on Vendor#2's filesysytem.
cd into Vendor#1's filesystem.
pwd

Vendor#1's filesystem was using inode numbers > 65535 which did
not fit into the 16 bit field used by Vendor#2.


3) Problems are found in the reference port:

Bug #26
Description:
Names of NFS temporary files are not random due to bug in newname()
[sys/nfs/nfs_subr.c]. NFS doesn't use random names when renaming
a file in nfs_remove(). The problem exists in 3.x and 4.0 
implementations of NFS.

4) Problems are found in a single vendor's implementation:

Bug # 47
Description: 
readdir doesn't work properly.  EOF not set at end of directory reading.

Comments:
The problem was in the vendor's code.
------------------------------------------------------------------

(NFS, ONC, NeWS and Connectathon are trademarks of Sun Microsystems, Inc.
 UNIX is a registered trademark of AT&T)

			Brian Pawlowski <beepy@sun.com> <sun!beepy>
			Sun Microsystems, Portable Software Products

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 01:25:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Packet filtering for 4.3BSD ?

Pat Barron,
by whom have you been told to support filtering of packets
baseed on UDP and TCP port numbers and source/dest IP addrs?

Thanks,

Vint

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 02:01:50 GMT
From:      ado@elsie.UUCP (Arthur David Olson)
To:        comp.protocols.tcp-ip
Subject:   Re: Crackers and Worms

Thanks for the reply!  So much for my followup article about
how kremvax didn't get infected because the KGB had not only disabled
sendmail's debug option but had removed sendmail entirely as a security
threat.

(Another possibility would have been that kremvax ran neither Ultrix or
MORE/bsd 4.3 on its VAX, but rather MS-DOS.  Muscovite Socialist DOS?)

				--ado

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Nov 88 12:34:18 PST
From:      lars@SALT.ACC.COM (Lars J Poulsen)
To:        encore!pinocchio!bzs@talcott.harvard.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Worms and fixing blame
I (Lars Poulsen) said:
>> As a minumum, everybody who buys system software should add the following
>> clause to their purchase orders: "The system shall identify each user by
>> a unique user identification, and password validation shall be used to
>> ensure that no unauthorized access occurs". This will ensure that you can
>> hold the vendor liable for losses you might incur in a situation like this.
 
Barry Shein replied:
> Date: Thu, 17 Nov 88 11:31:17 est
> From: Barry Shein <encore!pinocchio!bzs@talcott.harvard.edu>
> To: lars@ACC-SB-UNIX.ARPA
> Subject: Worms and fixing blame
> 
> What exactly is "unauthorized access"? Whatever inconveniences you as
> an afterthought?
> 
> I don't believe that this past problem would have been an issue under
> your proposal, the system certainly demands a password for login
> access. You're too vague, the bug exploited was that a particular mail
> message text could allow an "undesired" program to run (as opposed to
> many, permitted and necessary, "desired" programs regularly run on
> behalf of mail messages.)

What I mean to say, is that most clients have some expectation of their
operating system providing a certain amount of protection, and they need
to communicate this to their vendors. Without SOME mention of these
issues in a contract, the vendor can point to his standard terms and
note that the user is using the product entirely at his own risk.
"No claim of merchantability or fitness for any purpose is implied".
The language I suggested may be sub-minimum, but would you not agree
that if the user has an expectation it should be expressed ?
 
> Does this make sense? Does sending mail without a password constitute
> "unauthorized access"?
> How about ... [6 other examples of user abuse that might bring down the
> system] ...  Are all those the vendor's fault?
> The problem is that user's security needs are widely varied. Oh, I
> agree that this past worm entry was an obvious botch, but let's talk
> in more general terms, at some point we all agree an error occurred
> but the important thing is to agree on intent.

But intent is so hard to prove.
 
> It's easy to say something like "reasonable security" in a contract or
> some other such mom and apple pie truism, but what does it mean?  How
> can we determine if the contract has been breached?
> 
> What are needed are reasonably detailed security requirements (the
> military certainly has these although I doubt they would correspond to
> most users.) A test suite would be very helpful which would reflect
> these needs.

The orange book states such evaluation criteria. One of the classes
(I can never remember the codes) describes a multi-user system with
password protected logins, which allows users and/or system managers
to restrict or permit the access to files belonging to other users.
This is what most commercial sites believe thay have, and it is sobering
how few of these systems can actually pass certification.
 
> But that would require real work, and cost real money...

But now that we have defined the evaluation criteria, I expect to
see these specs to be quoted on more and more procurements, and soon
the vendors will find it important to comply.
 
> Let's face it, one person's security requirement is another's damned
> nuisance.
> 
> 	-Barry Shein, ||Encore||

With this, I wholeheartedly agree. We need to remember that any
computer is secure if it is powered down, but then it is also quite
useless.

	/ Lars Poulsen
	  Advanced Computer Communications
-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Nov 88 14:29:05 CDT
From:      "Stuart Levy" <slevy@uc.msc.umn.edu>
To:        encore!pinocchio!bzs@talcott.harvard.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  password aging (from worm discussion)
> ... once you've decided that the security of your system depends on
> the read security of one file ...

But it doesn't.  It depends on that *and* the chance that someone will be
able to guess one of the passwords on the local system.

I heard of someone who in the last few days tftp'd to a machine at another
university, picked up their /etc/passwd, and found the root password in a
few minutes computing time.  It just shouldn't be that easy.

Someone else from Syracuse University has been anonymous-ftping into machines
here and attempting to pick up ~ftp/etc/passwd, presumably with the hope
that it would contain account names and perhaps encrypted passwords
for accounts on these systems.  Even if you trace failed login attempts,
someone who gets the password right the first time won't show up.
It shouldn't be that easy either.

I don't know anyone who's claimed that shadow pw files are all that's
necessary in the way of password security, and it's hard to see anyone
trying to do so.  But it would help.

As you probably know, VMS has a similar arrangement: its authorization file
is unreadable to the world but its designers still judged a difficult-to-
invert password hash advisable.

	Stuart Levy
-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Nov 88 16:30:54 est
From:      Barry Shein <encore!pinocchio!bzs@talcott.harvard.edu>
To:        @talcott.harvard.edu:slevy@uc.msc.umn.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   password aging (from worm discussion)

Well, I don't have much faith in security by small incremental steps
that may or may not sum up, it's an interesting theory I've never
heard before.

The real goal should be an encryption field which is secure, I believe
the technology to achieve that is both possible and sufficient.

I don't consider VMS to be any authority on the matter, it's full of
questionable layers of pseudo-security which don't seem to have any
sound basis, most likely suggested by marketing types, it's a good
example of implement everything and hope it makes the customer happy
in his/her ignorance. I'd rather hear an appeal to reason rather than
"authority" (if anyone can consider VMS to be "authority", I usually
find it fertile ground for examples of how *not* to do things.)

I'd prefer an argument based on more than "common sense" which I
believe already has been poked full of holes (ie. aren't you admitting
an easy target rather than dealing with the real problem?)

The real problem is people picking easily cracked passwords and
possibly the ease with which the encryption algorithm currently in use
can be used to exploit this, don't you think it would be more sound to
approach that problem than trying to sweep the whole issue under the
(file protection) rug? At some severe cost I may add (notably having
to secure a file.)

	-Barry Shein, ||Encore||

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 13:01:35 GMT
From:      rlodp@nzapmb.co.nz (Richard L. Osborn )
To:        comp.protocols.tcp-ip
Subject:   WANG VS100 - TCP/IP

Is anyone out there familiar or even seen the Wang implementation of TCP/IP.
This product was annouced June. We are very keen to link a VS100 and a Pyramid
9820 using ftp etc. Wang (NZ) say it is running but we have heard otherwise.

We would be grateful to hear from anyone who is:
a) using the product on the same type of machine
b) has heard of it running.

The particular aplication is to re-route Wang print files out of the Wang VS100 
thru the Pyramid's X25 controller to remote sites. But that's another story.

If you have the time, I would be keen for someone to ring us with experience of the product collect on New  Zealand code? 04 731594. Thanks.

RL Osborn                                              rlodp@nzapmb.co.nz

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 13:56:28 GMT
From:      stoll@ux1.lbl.gov (Cliff Stoll)
To:        comp.protocols.tcp-ip
Subject:   Virus Stories, Please


 COLLECTING ARPANET VIRUS STORIES

 (Apologies that I'm repostin this note:
   I am about to analyze the many comments I've received 
   and wanted to get any latecomers.
   Thanks to all who have responded so far!)

I'm collecting information about the Nov 3 Arpanet virus,
trying to determine:
     > How many sites were infected
     > How many were not
     > How quickly it spread

SO:  If you were infected, please send me a note describing
your experiences.  Please include:
     > Where are you?  What type of computers?
     > What times were stamped on the /usr/tmp/x files?
     > Which of your computers were infected?  All of them?

Please send your anecdotes & stories, such as:  
     >  What time did you discover it?
     >  What tipped you off?
     >  How did you and your colleagues respond?
     >  What would you differently?
     >  Did you call anyone?  Or did anyone call you?
     >  Where would you turn for information next time?
     >  When did you finally eradicate it?  
     >  Any weird wrinkles or strange effects?

I'm interested in hearing from you even if you were not infected!

Please pass this message on to others:
I would rather have multiple responses from a site than none.

Thank you very much for your time & trouble.
In return, I'll mail summaries to everyone that contributes.
If you'd like a copy, please include your address.


Thank you very much for your time & troubles!

Cliff Stoll                Harvard/Smithsonian Center for Astrophysics
617/495-7147               60 Garden Street,  Cambridge, MA 02138
Cliff@cfa200.harvard.edu   ( or on bitnet,  Cliff@lbl ) [Nov 5, '88] [&Nov 16]

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 14:42:38 GMT
From:      hal@GATEWAY.MITRE.ORG (Hal Feinstein)
To:        comp.protocols.tcp-ip
Subject:   passwords

Before anyone falls too deeply in love with pronunceable passwords and
rushes off to install it maybe you should take a look at some others who've
used it.  I put pronunceable passwords into a network authentication server
about three years ago which had lots of office-type workers, not computer
people.  My goal: add some kind of psychological memory jog to help 
people remember them.  Random strings no one remembers and most people
write'em down. Fine!  We'll do pronunceable passwords.  I based it on
the algorithm used by multics. They hated it and wrote 'em down.
Now, years later I am a user of a multics
system with pronunceable passwords, and I hate it!  Yes, I've been tempted
to write'em down.  A better system is pass phrases which uses DES and a 
standard feedback chainning technique to develop a 64-bit result from a
variable length phrase.  A lot of password generation schemes beat the
dictionary attack such as a few small words glued together with a number
or other symbol. They are easier to remember than 8 characters of bizarre 
text.
 

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 15:30:41 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re:  password aging (from worm discussion)

> From: Barry Shein <encore!pinocchio!bzs@talcott.harvard.edu>
 
> Although I support the other proposals I will argue that shadow
> password files are a bad idea  ...
 
> It means that if, for any reason, you believe your password file has
> been let out you will have to admit that your security is compromised
> and, for starters, have everyone change their password ...
 
> You're turning the file into pure gold.

I don't understand this, could you explain further?  Shadow password
files aren't intended to contain clear passwords, they'd hold encrypted
ones just as they do now.  Using them would just impede people from casually
picking up the file and trying passwords without going through login etc.
But even if someone did capture a copy of a shadow pw file, you'd only be
in the same situation you always were when /etc/passwd contained passwds.
So is it really the kind of catastrophe you suggest?

	Stuart Levy

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 15:52:42 GMT
From:      mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards,news.admin,news.sysadmin,news.groups
Subject:   Re: comp.security - LET'S DO IT!  CALL FOR VOTES

In article <32417@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes:

>Just so -- the call for comp.security is pretty much misguided.  The problem
>with misc.security is that the moderator moved machines and, apparently, has
>not yet been able to reestablish connection to the news world, and so the
>list has been moderator-blocked for something like eight months now.

     Well maybe slightly misguided?  I may have jumped the gun a bit on calling
for votes but apparently the "misc.security" group is not well known.  Judging
from the response I have gotten in over less than two days, there is
considerable support for an unmoderated group devoted to "computer" security.
The charter on misc.security (yes, NOW I'm finally doing my homework!) states
that it is "security in general, not just computers".  There is also the
question of whether the moderator wants to deal with all this goo we have
oozing through about a dozen other groups.  The seems to be a demand for a
place to go and bullsh*t about security (along the lines of who's likely to
take out a contract on rtm) as well as a quiet place for serious discussions
on real security issues (although these should probably be in the mailing
lists when they real get going!).

     Lets face it folks.  Not having a group does not mean the discussions and
the bullsh*t won't take place.  It just means it will probably take place in
a group you're not reading or be in an article you skip because your interested
in the other topics in the group (Subject lines arn't all that clear and I don't
read everything).  Arguements along the lines "well we really shouldn't be
discussing this in the open" are (VOID)&NULL .  The discussions are taking
place RIGHT NOW and in most cases out of your sight!  There is no way to
stop them (even if all of us wanted to) or even control it.  There are books
in the bookstores RIGHT NOW with serious security issues covered.  These are
far more accessible to Joe Blow Hacker than our discussion groups!

>Instead of rushing off to start a new newsgroup, why don't we just unmoderate
>misc.security and see how it works moving all of the security stuff OUT of
>the random newsgroups for a while.

     I agree completely.  We need something rolling as quickly as possible.
It seems like the most lasting damage rtm may have done is raising the noise
levels in a dozen or so groups to astronomical levels (there are better ways
to do this as a few past individuals have show us, but....).  One way or
another, let's get it all in one spot.  Unmoderating misc.security may well
be the answer, whose cage do we rattle?

     I'm out on UUCP so I've not had to deal with "the WORM" but I have had
to deal with a few practical jokers getting into "galbp" (much worse for me,
these clowns kept coming back for more).  I have had to find out about a lot
of this nonsense the hard way following serious security breaches.  I have
not lost a day and a half dealing with a slow down in my system, I have lost
weeks in some cases preventing "ghost messages" appearing out of nowhere on
my printers and in our mail.  These guys even got on our system and were
posting forgery USNET articles from galbp!  I don't know if I plugged all
their holes or if they finally got bored.  I will never know and I have to
assume that there is something I have missed or that I don't know about!
I need to know what everybody else has had to deal with so I can prevent
it on my system.  You won't find me posting what they did to insert their more
devious holes into my system or the stupid mistakes they made which let me
I don't need "cookbook" cracking techniques but I haven't seen anyone
discussing anything of that sort to date anyways.

     BTW) It has been pointed out to me by one individual that I should have
had a "Followup-To: news.groups" specified in my original call for votes.
Largely true and an oversight in my haste, my apologies to everyone.
Please carry on the discussion ABOUT THE GROUP in news.groups.  Part of my
objective was to make some of the discussions aware of each other.  That
would not have involved a followup (till we get our own working group).
Sorry if I tried to cover too much ground in one article (guilty here too I
guess).

     As I said in my original posting, I am processing the votes by "hand".
I have received some software for automating this to some extent.  Please,
if and when you vote, include the following in the "Subject:" line:

	"yes"		If you want the group unconditionally.
	"no"		If you don't want it under any circumstances.
	"moderated"	If you only want it if it is moderated.
	"unmoderated"	If you only want it if it is unmoderated.

     I will attempt to send out acknowledgements as soon as I can.  Summaries
will be mailed as well as posted.  If you've already sent me a vote, don't
worry, your counted.  No need to send another.

     If I am failing to follow some guidlines that I haven't found yet or
some unwritten rules please EMAIL them to me!  I just run this show over
here, I don't pretend to really understand it!

     Thanks
---
Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 16:11:55 GMT
From:      srwmxpb@windy.dsir.govt.nz (Peter Burgess)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP source for Unix

Don't you just hate people who jump into a news group which they haven't been
reading and ask dumb questions which have already been answered a million times
already!

Well,... where can I find a public domain version of TCP/IP for a Unix system
(preferably System V) and preferably with support for serial lines?

Please send replies to me and I will summarize (to avoid pollution :-).

Peter Burgess
New Zealand Department of Scientific and Industrial Research.
(srwmxpb@wnv.dsir.govt.nz)

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 17:34:05 GMT
From:      spaf@cs.purdue.EDU (Gene Spafford)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Report on the Worm Available

On Monday, the printers should be getting an order to print copies of a
joint Purdue CS/SERC technical report entitled "The Internet Worm
Program: An Analysis," authored by yours truly.  I have enclosed an
abstract of that report below.

In order to get an idea of how many copies to order for the first
printing run, I'm posting this announcing its availability.  If you
would like to order one or more copies of the report, please send me
e-mail with your SURFACE mail address ASAP.  Purdue and SERC have a
tradition of not charging for copies of our technical reports, so just
your address is all you need to order; we may make an exception if any
one person or organization orders multiple copies. Copies should be
mailed starting the week of the 28th, and orders will be filled FIFO.

This is the first in a planned set of reports on the incident.  The
others will be announced as they become available.  One will have to do
with the spread of both the program and the fixes.  If you have not yet
sent in your local experiences with the worm to either Cliff Stoll or
myself, please do -- it will help us put together one or more such
papers!

--spaf


	       The Internet Worm Program: An Analysis
			Eugene H. Spafford

	  On the evening of 2  November  1988,  someone infected  the
     Internet with a worm program.  That program used a number of
     methods  to  break  into other  machines  and  copy  itself, thus
     infecting those systems.  The infection eventually spread to
     thousands   of   machines,  and  disrupted  normal activities
     and  Internet  connectivity  for  many days.

	  This report gives a fairly detailed  description  of  the
     components of the worm program -- data and functions.  It  is
     based on  two  completely independent   reverse-compilations  of
     the worm, along  with  a  disassembled  version.  Almost  no
     source code  is given in the paper due to current concerns about
     the state of the "immune system" on the  Internet,  but the
     description should be complete enough to allow  the  reader  to
     completely understand  the  nature of the attacks used by the
     program.

	  The paper contains a list of  the  security  flaws
     exploited  by  the  worm program, and gives some recommendations
     on how to eliminate  or mitigate   their  future  use.   The
     report  also includes an  analysis  of  the  coding  style  and
     methods  used  by  the  author(s) of the worm, and draws some
     conclusions about both their  abilities and intent.
-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 19:01:52 GMT
From:      bzs@pinocchio.UUCP (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   password aging (from worm discussion)


>> You're turning the file into pure gold.
>
>I don't understand this, could you explain further?  Shadow password
>files aren't intended to contain clear passwords, they'd hold encrypted
>ones just as they do now.  Using them would just impede people from casually
>picking up the file and trying passwords without going through login etc.
>But even if someone did capture a copy of a shadow pw file, you'd only be
>in the same situation you always were when /etc/passwd contained passwds.
>So is it really the kind of catastrophe you suggest?
>
>	Stuart Levy

That's the idealized situation. In reality once you've decided that
the security of your system depends on the read security of one file
then any breech of that must be responded to, common sense would
dictate it. Otherwise, why did you make it unreadable? I don't think
going forth with the idea "oh, we did it, but we never *really* needed
to, it doesn't matter if a copy got out" is a rational approach.

Otherwise one is just trying to have it both ways, relying on the
security of an unreadable pw file but saying you don't really care if
anyone reads it. At that point at best it's a matter of whether you
can sell such an attitude to your (management? users?) when they come
to you and say "gee, I saw so and so walk out with a listing of the
password file...what are you going to do?"

Don't think about yourself who knew in November 1988 *why* you went to
shadow pw files, think about (oh) 5 years from now when every system
is delivered and manuals say to keep the pw file unreadable because
otherwise passwords might be cracked.

I still contend it's a bad idea, concentrate on the other aspects.

If some form of publicly readable encryption is deemed impossible
as a concept I sincerely hope that argument gets published.

	-Barry Shein, ||Encore||

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 19:02:56 GMT
From:      pcg@aber-cs.UUCP (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

In article <7178@charlie.OZ> jgm@charlie.oz.au (John Moorfoot) writes:

    In article <26010@bu-cs.BU.EDU> kwe@bu-it.bu.edu (Kent England) writes:

    >In article <8811090956.AA07706@LANAI.MCL.UNISYS.COM>
    > perry@MCL.UNISYS.COM (Dennis Perry) writes:
    >>
    >	When I was at InterOp I stopped by the Sytek booth to look at
    >their telnet server.  I was not impressed, except by a neat little
    >gizmo they had for their terminal server administrators.  It looked
    >like a calculator.  To use it you enter a PIN, like at your favorite
    >ATM machine.  Then when you log onto a secure port to administer your
    >Sytek terminal server, the login program gives you a sequence of
    >numbers.  You enter the numbers into the little gizmo and it gives you
    >a bunch of numbers back.  You enter these into the login program and
    >you are in.  Anyone catching this sequence over the net cannot
    >duplicate it, they don't have the little calculator gizmo and your
    >PIN.
		[ ........ ]
    A host program asks the PC for a challenge for a user, and the PC
    returns the challenge and two possible responses. The calculator
    can be programmed to accept two separate PINs, and will give a
    response to the challenge dependant on the PIN entered. This
    provides an adiitional degree of security, as the second PIN can
    be used (for instance) if the user is under duress.

		[ ......... ]

Actually all these systems just transform a "what you know" security to
a "what you have" security. There is no inherent improvement
in the overall security level, and actually it may be lower (more
components to compromise, etc...).

As to systems that auotmatically generate passwords, usually the
cardinality of the set of distinct passwords they can possibly generate
is vastly smaller than the cardinality of possible passwords, and
therefore they make it terribly easy to generate a list of all possible
passwords. What's the point of having a key space of 127^8 (8 ASCII chars)
if the password generators can only generate a few thousand or
dozen thousand different passwords (e.g. most generators based on trigraphs).

All these issues have been hashed to death in the past.

This is a TCP/IP group. Let's make some specific TCP/IP comments on
security -- a system that supports TCP/IP protocols must provide all
security itself. Security MUST be end-to-end, and MUST be based on
powerful encryption, such as RSA, and authentication MUST be based on
something like zero-knowledge proofs, and the human link still remains the
weakest. Protecting things like portions of the socket/host address
spaces will only stop children.

My general feeling is that security is NOT terribly important for a lot of
people, and that as somebody pointed out, it involves a total approach,
and is thus TERRIBLY expensive if done seriously. For example, one
of the attacks to a system is to send a fake os upgrade tape
labeled as though it were from the manufacturer... To foil these attacks
you must involve the manufacturer in your security approach.
-- 
Piercarlo "Peter" Grandi			INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BX (UK)

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 19:30:02 GMT
From:      sec@berlin.acss.umn.edu (Stephen E. Collins)
To:        comp.protocols.tcp-ip
Subject:   Copyrights - Talk to your lawyer, not me!


A number of people have been spouting off about this or that fact
regarding the copyright laws lately.  It is a simple matter to
go to your local law library and ask to look at a copy of
Title 17 USCS and get the facts for yourself (no, you probably
can't ftp it from anywhere, you'll have to use traditional
information gathering methods; but it will be a good exercise
for you).
 
What you discover may suprise you.  The law as written is not
entirely unreadable, and with a little bit of study, you might
even learn something.
 
While the copy I keep in my files is a few years old, according my inter-
pretation of it, those people trying to copyright their "shareware", "public
domain", "anonymous ftp", and other such programs and documents are not
complying with the statutes, thereby opening themselves up to civil
fines and preventing any enforcement of their copyright claim.

Furthermore, those who are "copyrighting" messages, etc., to prevent
people from quoting them out of context hopelessly misunderstand
the copyright laws.

However, all this is beside the point.  The actual question is what will
happen if someone violates your supposed copyright claim, or you
violate someone elses copyright claim.  Will that violation be taken
to court or enforced by anyone?  HIGHLY UNLIKELY!
 
If anyone is really interested in making a valid copyright for something,
I suggest writing to the copyright office and asking for a copy of
Circular R1 "The Nuts and Bolts of Copyright", a copyright application
form, and related information.  The address is:
  Copyright Office
  Library of Congress
  Washington, DC  20559

That's enough said here about copyrights.  Any further discussion of
this subject should be with your lawyer, not with us country bumkins.
+-----------------------------------------------------------------------+
| Stephen E. Collins                             | sec@ux.acss.umn.edu /
| ACSS Microcomputer & Workstation Systems Group | sec@UMNACVX.BITNET /
| 125 Shepherd Labs                  +-----------+-------------------/
| University of Minnesota            | Cum hanc intellegas, Latinam /
| Minneapolis, MN  55455             | sententiolam potes legere!  /
+------------------------------------+----------------------------+

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 19:53:07 GMT
From:      sam@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: misquoting . . . .

Steve Dyer writes:
>Putting aside your description of the Globe as "respectable", I would
>like to think that the media's portrayal of Robert as "brilliant" and
>"ingenious" comes from the many interviews with people who know him and
>have worked with him, all of whom will gladly offer comments describing
>him as brilliant, his work ingenious, his manner uniformly helpful,
>and his intentions always free of malice.  This particular event is
>certainly confusing to those of us who harbor such opinions, but it's
>also not enough to sweep them away.
>
>Sherri, I've known assholes, I've worked with assholes, and RTM
>is no asshole.

(I won't pick on you about my name spelling since someone else already
caught your error... :-)

I think you're misunderstanding me.  My posting was not meant to express
my opinion as to the asshole-ish-ness of RTM.  My personal opinion on
the virus and what the consequences should be is irrelevant to the
argument I was presenting.  In this forum alone we have people expressing
opinions on RTM ranging from marriage proposals to wanting him shot.
My complaint against the Globe (or whatever news medium we want to pick
on - most have been the same on this issue) is that they are *only*
presenting the folk-hero image of RTM while there are lots and lots of
people out there who would have some not-so-nice things to say about him.
I think this is imbalanced and definitely contributes to the warped
public image that not only hackers but all of us in the computer industry
are suffering from.

Shelli (that's with two l's and an i) Meyers
...who works for but doesn't speak for FTP Software, Inc.

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 20:52:31 GMT
From:      shore@adobe.com (Andrew Shore)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   looking for "whois" server source

I'd like to run a local "whois" server in my organization
and I'm looking for the server source.  

What I need is a C implementation that runs on SunOS (4.0 or 3.?) or 4.3 BSD.

Anybody got one?
Is is available from the NIC?

Thanks in advance,
--Andy Shore
  Adobe Systems Incorporated
  shore@adobe.com
  {sun,decwrl}!adobe!shore

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 88 22:53:13 GMT
From:      kjones@talos.UUCP (Kyle Jones)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   need explanation of Sun/PCC compiler error

While compiling a program module under Sun OS 3.5 the compiler died
with:

"../c/mcpdata.c", line 3365: compiler error: out of temporary string space

Would someone with source (and understanding) of the Sun compiler tell me
what this error means, and what I can do to make it go away?

kyle jones   <kjones@talos.UUCP>   ...!uunet!talos!kjones

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 03:32:32 GMT
From:      postel@VENERA.ISI.EDU (Jon Postel)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over FDDI

> Date: 7 Nov 88 23:07:17 GMT
> From: sgi!vjs%rhyolite.SGI.COM@ucbvax.Berkeley.EDU  (Vernon Schryver)
> Subject: TCP/IP over FDDI
> 
> As I understand (or, more accurately, misunderstand) things, in the
> next MAC document 48-bit addresses will be required & 16-bit optional
> (good news!).  That means, we have a 13 byte MAC header in front of every
> FDDI packet.  If we add an 8-byte 802.2 LLC header in the style of
> RFC-1042, then the IP header starts at the wonderous offset of 21.

Does anyone think a 13 byte MAC header is a good idea?  

Do the guys on the 802 committee ever thing about anything bigger than a
single bit?  What favor can they possibly think they are doing to the
users of FDDI networks by having a 13 byte header?

--jon.

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 07:13:16 GMT
From:      MKL@SRI-NIC.ARPA (Mark Lottor)
To:        comp.protocols.tcp-ip
Subject:   The TCP-IP List

This is a reminder of what this mailing list is for.  The TCP-IP list
is for discussions related to TCP/IP protocols and implementations.
Occasionally it is used for maximum distribution of Internet related
announcements.  It is not for discussions on passwords or system security,
or anything else.

It takes the mailer about 3 hours to mail out one message to the whole
list.  This means it can't handle more than about 8 messages a day
without getting backlogged.  Please don't clutter things up with one
line responses, flames, or other useless personal comments.
-------

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Nov 88 19:29:45 PST
From:      lougheed@clash.cisco.com
To:        postel@venera.isi.edu (Jon Postel)
Cc:        sgi!vjs%rhyolite.sgi.com@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP over FDDI
No, a 13 byte MAC header is not a good idea if you want your protocols to
run fast on modern processors.

There are ways around this, however.  Design your FDDI interface to
optionally insert a pad byte on reception and delete a leading pad byte on
transmission.  Then you have a performance win if people use the eight byte
SNAP header a la RFC-1042 and a performance problem if people use the simple
three byte 802.2 LLC header.  Now at least you can choose which protocol
suite is going to take the performance hit.

Kirk Lougheed
cisco Systems
-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 16:21:02 GMT
From:      hbo@sbphy.ucsb.edu (Howard B. Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: Crackers and Worms

In article <CMM.0.88.595111611.bill@uhccux.uhcc.hawaii.edu>, bill@UHCCUX.UHCC.HAWAII.EDU (William J. King) writes...

>Well,
>   What would prescribe as just punishment for the Wiz of Cornell?

   A friend of mine at Berkeley says they suggested to Cornell that the
guilty party be suspended for one year, then forced to rewrite sendmail. When I
intimated I wasn't too happy with that idea, my friend replied "I didn't say
anyone had to run it!" 


--
Howard Owen, Computer Systems Manager           internet: hbo@sbphy.ucsb.edu
Physics Computer Services                       BITNET: HBO@SBITP.BITNET
University of California, Santa Barbara         HEPNET/SPAN:   SBPHY::HBO
"I am not a pay TV service!"                    uucp:{The World}!ucbvax!hub!hbo

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 17:43:17 GMT
From:      csd1032@UX.ACSS.UMN.EDU ("Aaron Y. T. Cheung")
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert "wormer" Morris

In article <CMM.0.88.595118467.bill@uhccux.uhcc.hawaii.edu> bill@UHCCUX.UHCC.HAW
   AII.EDU (William J. King) writes:
|
|     4.  Lets engineer better operating systems!

better in what sense? is Multics better than Unix?

|     5.  More distribution of binary systems and less source code.

Please justify.  For as I see it, binaries are more difficult to
patch satisfactorily when problems arise (Murphy's Laws predict so)
and that Trojan hourses could creep in more readily, especially
regarding distributions in public domain.

/*
 *   Aaron Y. T. Cheung
 */

-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 18:07:28 GMT
From:      wdw@aucs.UUCP (Bill Wilder)
To:        comp.protocols.tcp-ip
Subject:   Dynamic IP address assignment

At our site, we have a number of PC's attached to an Ethernet and
this number will no doubt continue to grow. At the moment each PC picks
up it's IP address from a RARP daemon on a UNIX host (Sun-4/280 SUN-OS
4.0).  It seems to me a shame to dedicate an IP address to each PC when
at any given time only a fraction of the PC's would be in use at the
same time.

Does anyone know of an RARP implementation that dynamically assigns
IP addresses from a pool? Obviously this would be appropriate only for
machines such as PC's in a public location where the current user may
care less what his IP address is.
-- 
UUCP:      {uunet|watmath|utai|garfield}!dalcs!aucs!wdw
BITNET:    WDW@Acadia
Internet:  WDW%Acadia.BITNET@CUNYVM.CUNY.EDU

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 18:58:01 GMT
From:      dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
To:        comp.protocols.tcp-ip
Subject:   Re: An Obvious Security Problem?

In article <881109143927.20402284@Csa3.LBL.Gov> forrest@CSA3.LBL.GOV writes:
    I am a complete novice at matters relating to networking and haven't
    read the Telnet RFC so I may be missing something obvious.
   
No question is unworthy of asking.

    Assume the following network organization:
    
    
    A <------------------> M <------------------> Z
    
    (Node M is actually one or more gateways.) Couldn't a bad guy
    on   M   monitor   the  TCP/IP  traffic  looking  for  Telnet
    connections and then follow through  the  exchange  of  login
    names  and  passwords,  thereby  capturing  a  node/login and
    password pair? (I realize that  the  path  from  A  to  Z  is
    dynamic and that this might not always be possible.)

Yes.  In fact if one has a LAN sniffer one can  read  the  entire
traffic  on  the  EtherNet  Cable.  All networking schemes assume
physical secuirty of the communications media.

The DoD people have a solution: encrypt the comm-line.  There  is
a  secure  version  on  the  Internet  that does just that.  Even
better is to use end-to-end encryption  for  each  communications
circuit.  The  basic  problem  with all of this is the encryption
overhead and the key and authentication problems.

-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm@arpa.att.com

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 19:14:33 GMT
From:      csd1032@UX.ACSS.UMN.EDU ("Aaron Y. T. Cheung")
To:        comp.protocols.tcp-ip
Subject:   Re: hosts.equiv considered harmful (was Re: bin owning files)

In article <185@bnr-fos.UUCP> hwt@bnr-public.UUCP (Henry Troup) writes:
|
| I just checked my SunOS 4.0 *distribution tape* hosts.equiv.  The
| file consists of "+\n".  A quick RofTFM shows that this means
| ***trust everyone***  Surprise!

Putting a "+" in hosts.equiv is definitely an oversight, and the problem
becomes quite seriuos when two vendors' oversights are put to work together:

Here we're in wide-spread use of a type of terminal server which is capable
of several login protocols (vis, telnet, rlogin, call).  The rlogin works
the usual way (rlogin <remotehost> [-l <remoteuser>]) except that when
connecting to a remote host, it uses the user-supplied <remoteuser> as
arguments to *BOTH* of the locuser and remuser parameters in the rcmd() call.
man rcmd for details. (The locuser is usually returned by "getpwuid(getuid())"
from the user's environment who is invoking the rlogin; but being a terminal
server, it wouldn't make too much sense, and hence is [apparently] not used).
Security checkpoint #1 passed....

Each of these terminal servers bears an Internet name and address, which
is listed in the [locally, centrally distributed] host table too.  The "+"
in hosts.equiv on a particular machine tells that machine to trust all hosts
it knows, including these terminal servers!
Security checkpoint #2 passed....

Consequence?  "rlogin john -l doe" logins the user in as doe on machine john,
WITHOUT A PASSWORD.

Quite an amusement, eh?  Btw, this is not hypothetical, it actually happenED.

/*
 *   Aaron Y. T. Cheung
 */

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 20:37:41 GMT
From:      csg@pyramid.pyramid.com (Carl S. Gutekunst)
To:        news.misc,news.sysadmin,comp.protocols.tcp-ip
Subject:   Re: SF columnist on the Worm, suggests new terminology.

[Time to move this discussion to news.misc.]

It has been pointed out to me by several people (notably RFW Clark, thanks)
that my reply to Dirk was pretty snot-nosed. I've been embroiled in a lot of
really stupid copyright arguments over the last few months, and have long
since gotten exasperated with people who like to write lengthy postings, but
who don't know the first thing about copyright law. So here comes Dirk, with
an intelligent, reasonable posting fer Gawdsake, and I act like an idiot. I'm
sorry Dirk. Let me try to answer your posting with equal intelligence. 

In article <735@faui10.informatik.uni-erlangen.de> (Dirk Husemann) writes:
>	I'm not so sure about that: At least in West Germany the copyright
>laws state that news (as printed in newspaper articles) receive protection
>only for a very limited time (~ 2 days or so). As West Germany signed the
>international copyright treaty, I can imagine that this rule originates there.
>The USA did sign this treaty recently, also, thus it could be the case that
>the copyright protection for news is restricted in the US also!

I haven't kept up on the discussion on the international copyright agreement;
last I knew for sure, the U.S. was still balking over a number of many items,
notably copyrights on fonts (which many countries do not recognize). A U.S.
signing would normally mean nothing to publications within America, however;
a separate act of congress is necessary to change the existing laws as they
apply within the U.S.

I hadn't heard of a two-day limit on newspaper articles, although I can see
where it makes sense, and can also see where the publishing industry in the
U.S. would scream bloody murder over it. Newspapers in the U.S. print a lot of
articles that are not, strictly speaking, "news." There are columns, features,
and "research" papers that are equally relevant (or irrelevant) over time. And
these are what sell papers in the U.S., not the news.

With regard to Jon Carroll's column, the Chronicle's Legal Department flatly
stated that posting of the column to Usenet without prior written permission
was a violation of their copyright. The lawyer was a little irked, apparently
since one other computer bulletin board *had* written for permission before
posting. The lawyer was willing to ignore the violation if the article was
cancelled. (I do wonder what he would have done if it was not -- how would he
know?)

The lawyer implied, but did not state explicitly, that they owned full rights
to the column. Even still, I would not unilaterally cancel a posting that had
Carroll's blessing, since he has accepted resposibility. (Note that I, as an
employee of Pyramid Technology, cannot post software I developed here; I don't
own the copyright. But for all the articles I have ever published, I retained
copyright.) I haven't called the lawyer since the reposting since he isn't in
on weekends :-), but I wonder if he and Carroll would say the same things? 

<csg>

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 88 22:34:48 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

This is interesting.  You say that your users *hated* pronouncable
but non-word passwords.  Hmm..  But that's the only sort of password
I ever have.  (Example:  Burple; don't worry, that password is a couple
of years old and isn't in use anywhere.).

Perhaps it's not just pronouncability that people want.  At least
for me, most of my passwords are sniglet type things, that is there
usually is something which might mean something.  After all, pronouncability
isn't all there is to something being rememberable.

Now, why is this discussion occuring in comp.protocols.tcp-ip/info-tcp-ip?
And the similar discussions going on in other groups.  We *need*
to have comp.security, and gateway it into a mailing list for those
who cannot receive news.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 00:56:32 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: passwords

Ron, we don't need you going around to check to see if
anybody has done anything to protect their machines.

I don't remember you being appointed Internet Cop!

Also, you did not get into mcl did you?  I rest my case.

dennis

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 01:21:23 GMT
From:      vjs@rhyolite.SGI.COM (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over FDDI (13-byte MAC hdr)

In article <8811190332.AA13232@venera.isi.edu>, postel@VENERA.ISI.EDU (Jon Postel) writes:
> 
> Does anyone think a 13 byte MAC header is a good idea?  
> 
> Do the guys on the 802 committee ever thing about anything bigger than a
> single bit?  What favor can they possibly think they are doing to the
> users of FDDI networks by having a 13 byte header?

Some have helped calm my hysterical giggles by pointing out that AMD's 7982
DPC chip can shift by 0-3 bytes, so if you leave 3 bytes free at the start
of every buffer, ...

Others have said that 13 bytes of MAC + 3 bytes of LLC is just find.
Perhaps the 802 guys were thinking, but only about 802.2.

Could there be a new IP encapcapsulation in the style of RFC-1042 that
would be 7 or 11 bytes long?  Adding 3 bytes of 0 after the RFC-1042 802.2
header would waste no significant bandwidth, and would remove some
craziness in drivers--even if you do use the DPC.  One hears rumors
and more of other chip sets.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 01:29:20 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: a holiday gift from Robert Morris

In article <566@husc6.harvard.edu> cherry@husc4.harvard.edu (Michael Cherry)
writes:
>It is difficult to agree however it is analogous to a brilliant University
>Molecular Biologist experimenting on a biological virus but through
>inadequate precautions results in a large number of dogs in North America
>becoming infected. The released virus could be completely harmless - but
>I don't think this country would want or should allow this act to go
>completely unpunished.

I will grant you this analogy with one small change:  The `virus' must
be one that makes the dogs bark all night for two days in a row, keeping
everyone awake.

( :-) ? )

Chris

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 02:05:55 GMT
From:      mo@prisma.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   bogosity


13-byte headers are clearly crap.

However, the HSC (High Speed Channel) is a point-to-point, SIMPLEX,
link with 8 64-bit words of header!

Talk about opposite ends of the same black hole.....

	-Mike

-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 03:29:45 GMT
From:      lougheed@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over FDDI

No, a 13 byte MAC header is not a good idea if you want your protocols to
run fast on modern processors.

There are ways around this, however.  Design your FDDI interface to
optionally insert a pad byte on reception and delete a leading pad byte on
transmission.  Then you have a performance win if people use the eight byte
SNAP header a la RFC-1042 and a performance problem if people use the simple
three byte 802.2 LLC header.  Now at least you can choose which protocol
suite is going to take the performance hit.

Kirk Lougheed
cisco Systems

-----------[000495][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Nov 88 17:39:02 EST
From:      Steve Howie <SCOTTY%UOGUELPH.BITNET@CORNELLC.ccs.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: The TCP-IP List
I agree wholeheartedly about an excessive amount of traffic being
produced by this list (this message included:-)),so *PULEEZE* try
to keep to the subject, and stop this petty bickering. I for one
hate to see 40 or so mail messages, some many days old, showing up
on my VM system daily - even with our neat mailer it is a real pain to have
to look at every one of them and discard the 90% of them which could be
quickly classified as garbage.
I want to use this list to try to keep up with TCP/IP,
not to listem to re-hashed month old arguments about viruses. That belongs
somewhere else.

Thanx,

Scotty


'God invented Unix when he had to save printer ribbons'
-----------[000496][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 15:18:57 GMT
From:      farber@linc.cis.upenn.edu (David Farber)
To:        comp.protocols.tcp-ip
Subject:   Re: MMDF - Remote Mail Program

The following are two notes which I hope reflect properly the current
state of MMDF 2 distribution

Date: Sat, 19 Nov 88 22:07:19 -0500
From: Daniel Long <long@NNSC.NSF.NET>
Subject: MMDF2 Distribution
To: mmdf2@RELAY.CS.NET

Here's what I know:

Historically,

    BRL handled distribution to U. S. Government sites.
    CSNET CIC handled distribution to CSNET members.
    UCL handled distribution to Europe.
    UDEL handled distribution to all others.

We (CSNET) have followed distribution policy set by Dave Farber.  To
quote him:

"Yup, I am the target. Let me say again our rules for MMDF II distribution
 outside the CSNET community. MMDF II is available to all not-for-profits
 (that includes Universities ) and for commercial companies who will not
 use it in a service mode to make money with it (thats for the free
 distribution) and who agree to feed back to the commmunity any fixes,
 improvments etc.  We [UDEL] charge a $100 (US) fee to JUST cover tape,
 mailing, [and labor]".

MMDF2 was also distributed with BSD 4.3 (upon which the current set of
"updates" is based).  My understanding of the terms of usage is that a
license agreement was not required for sites who got the 4.3 version for
non-commercial use.

CSNET has always required members to execute a software license
agreement for MMDF2 per our original agreement with UDEL. 

Various things have changed since the early days of MMDF distribution:

	Prof. Farber has left UDEL for UPENN 
	BRL may no longer be the government distribution point
	The Army is making widespread use of MMDF and pockets of MMDF expertise
		are appearing at new places within the Army.
	CSNET has incorporated MMDF into its "generic" CSNET software agreement

Where this leaves things is anyone's guess.  I think the message that
the "freely-available" (e.g. 4.3BSD) MMDF versions are not to be made
into a commercial product is pretty clear.  Less clear is exactly what
the non-CSNET research community should do to get it, especially if
they don't have 4.3 BSD. 

If anyone has any more up-to-date or clarifying info, I hope they will
share it with the list. 

Regards,
Dan

(Disclaimer: I've met copyright lawyers.  I'm no copyright lawyer.
These are my personal opinions.)

_________________________________________________________________________

Date:     Sun, 20 Nov 88 9:48:13 EST
From:     "David J. Farber" <farber@dsl.cis.upenn.edu>
To:       mmdf2@relay.cs.net
Subject:  MMDF 2 distribution

As Dan Long said in a recent message , the current state of MMDF 2
distribution is certainly unclear. However I have been taking the
position of acting as a informal agent for getting copies of MMDF 2
out to people who are either not csnet members (although I always
recommend they consider joining if eligible and getting all the
benefits) and who can not just pick up 4.3. 

I am asking for the Udel license to be signed and will forward it to
Udel for record. We, at UPenn, will not charge for the distribution
(if a tape is supplied) but are NOT prepared to offer help, advise ,
cure problems etc. 

Dave

David J. Farber; Prof. of CS and EE, Director - Distributed Systems Labs.
University of Pennsylvania/200 South 33rd Street/Philadelphia,PA/19104-6389
Tele: 215-898-9508(office), 215-274-8292(home); FAX: 215-274-8192 

David Farber; Prof. of CIS and EE, U of  Penn,  Philadelphia,  PA
19104-6389 Tele: 215-898-9508; FAX: 215-274-8192 "The fundamental
principle of science, the definition almost, is  this:  the  sole
test of the validity of any idea is experiment." -- R. P. Feynman

-----------[000497][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 16:55:29 GMT
From:      david@ms.uky.edu (David Herron -- One of the vertebrae)
To:        comp.protocols.tcp-ip
Subject:   Re: Food for thought...

In article <8811090326.AA26953@multimax.encore.com> bzs@ENCORE.COM (Barry Shein) writes:
>
>Is it just possible that we have tolerated a mail system which has
>grown so complicated that a program like sendmail with its generalized
>regular expressions pattern matchers and massively complicated rules
>(and several other complex "support" programs to figure out paths,
>like pathalias) is about the simplest program which can do an adequate
>job acting as a gateway?

AHEM!  If you'll look over at CSnet-Relay you'll see, not sendmail,
but MMDF instead.  MMDF is proof that you don't need a nearly impossible
to use language to do the things you just mentioned.  With MMDF it's
a mixture of C and certain details in configuration files.

>Complexity breeds error.

YES  I agree completely.

>(note: This is *not* a bash at sendmail, I honestly have never been
>able to think of a much different way to effectively handle the
>current miasma of addressing schemes.)
>
>	-Barry Shein, ||Encore||

So I'll describe how MMDF handles it and see what you think.  I apologize
if this isn't very well written, but it's off the cuff.

The model is that you have "channels" through which all mail passes,
either going in or out.  In times where there are two different
addressing methods on each end of the channel, the channel program
converts one to the other as appropriate.  It uses pure RFC822
internally, except that it supports the %-hack as well.  That is, a
message coming in from uucp land has !-addresses converted to
@-addresses but unfortunately in a mixed mode:

	known.site!unknown.site!user
to	unknown.site!user@known.site

Which we all know to be a bad thing.  But I can live with it ...

Once the message is within the system the various addresses
are looked up in its database of the known world.  There are
two sorts of tables, domain tables and channel tables.  Domain
tables specify which domains exist and what hosts are in the
domain.  Channel tables specify which channel to use to reach
particular hosts.

To configure the gateway into the system it's simply enough put
the following into a domain table:

	berkeley.edu: ucbvax.berkeley.edu, g.ms.uky.edu

Now, the left hand side (LHS) specifies the domain for this record.
The RHS (in domain tables), it doesn't have to be specified fully,
on each domain table there is a upper-level portion which is
attached to the name.. that is

	g: g.ms.uky.edu

is in the "ms.uky.edu" domain table (it's also in the "uky.csnet"
table, which is also another flexibility).

Now, the line with berkeley.edu.  On the LHS, if the domain we're
considering matches it then we use the information on the RHS to
generate a route to reach it.  That form with comma's and such
ends up generating an RFC822 route-addr like so:

	<@g.ms.uky.edu,@ucbvax.berkeley.edu:user@bleah.berkeley.edu>

Now, MMDF could support a different addressing scheme internally
and still use that same syntax in domain files to specify routes.
Right?  (In fact, I understand that Steve Kille is working on
a version of MMDF which does X.400 internally, but I don't know
any details).

Now, if once it reached "g" the message could get to ucbvax only
by UUCP, the UUCP channel will translate to:

<route-to-ucbvax>!ucbvax!ucbvax.berkeley.edu!bleah.berkeley.edu!user

The "<route-to-ucbvax>" stuff is stored in the channel table.  The LHS
in a channel table has the domain-name for this entry, and the RHS has
routing information.  Like in the SMTP channel it has the IP address of
the host.  In the UUCP channel it has pathalias output.

The only thing I know of which we cannot do here is to generate routing
which only works by using the %-hack.  The example is our IBM
mainframe, one of them anyway.  They have TCP/IP stuff on one of them
only.  If I were to configure things such that bitnet mail went through
their SMTP server (so that it would avoid the BITNET line between here
and there) ... well, the SMTP server on the mainframe chokes on
"user@host.bitnet" addresses.  But if I instead were able to generate
"user%host.bitnet@ukcc.uky.edu" it would work fine.  So I end up
routing all that stuff by way of BSMTP over bitnet lines, but the
Crosswell mailer they use doesn't understand RFC822 routes so I have to
munge the routing to make "@ukcc.uky.edu:user@host.bitnet" ->
"user@host.bitnet".  Sigh.



I haven't yet read the documents for ZMAIL, at least not closely,
but what I read of it looks good.
-- 
<-- David Herron; an MMDF guy                              <david@ms.uky.edu>
<-- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.

-----------[000498][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 18:05:57 GMT
From:      allbery@ncoast.UUCP (Brandon S. Allbery)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: rtm and uucp

As quoted from <13059@princeton.Princeton.EDU> by alb@olden.uucp (Adam L. Buchsbaum):
+---------------
| In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
| >It would be so nice if someone would undertake a security audit to
| >insure that work other college students did, which *is* currently
| >in production, doesn't contain any surprizes.
| 
| Being just an ignorant graduate student myself, I can't figure out
| whether this implies that all college students are suspect, anyone who
| is not in college is not suspect, or both?  Perhaps John F. Haugh II
| could clarify this for me?
+---------------

You misunderstand; he's not talking about RTMorris, he's talking about the
kind of peoplke who wrote sendmail, and fingerd, and other programs that
might have inadvertent security holes in them.  And we've *all* done it at
one time or another.  An independent audit of "important" code is a good
idea.

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery@hal.cwru.edu
allberyb@skybridge.sdi.cwru.edu	      <ALSO>		   allbery@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.

-----------[000499][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Nov 88 11:02:09-1000
From:      William J. King  <bill@uhccux.uhcc.Hawaii.Edu>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: "Morris did it"--the new excuse?
I have always felt that computers were for work & study, and taht games
should be relegated to the parlor.  Parallels between dungeons and dragons
and hacking at the OS are much to close. 
-----------[000500][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 21:19:19 GMT
From:      alb@notecnirp.Princeton.EDU (Adam L. Buchsbaum)
To:        comp.protocols.tcp-ip
Subject:   Re: rtm and uucp

In article <13153@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>
>You misunderstand; he's not talking about RTMorris, he's talking about the
>kind of peoplke who wrote sendmail, and fingerd, and other programs that
>might have inadvertent security holes in them.  And we've *all* done it at
>one time or another.  An independent audit of "important" code is a good
>idea.
>

What "kind" of peoplke [sic] write sendmail, fingerd, etc.?  Perhaps
it would just be easier, if we can identify "them," to put them in
some sort of prison camp and be done with them.

-----------[000501][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 21:30:19 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip, wdw@aucs.UUCP
Subject:   Re: Dynamic IP address assignment

Wouldn't you run into a problem with ARP caches if you dynamically
assign internet addresses to ethernet based machines?

Eliot
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000502][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 88 22:39:02 GMT
From:      SCOTTY@UOGUELPH.BITNET (Steve Howie)
To:        comp.protocols.tcp-ip
Subject:   Re: The TCP-IP List

I agree wholeheartedly about an excessive amount of traffic being
produced by this list (this message included:-)),so *PULEEZE* try
to keep to the subject, and stop this petty bickering. I for one
hate to see 40 or so mail messages, some many days old, showing up
on my VM system daily - even with our neat mailer it is a real pain to have
to look at every one of them and discard the 90% of them which could be
quickly classified as garbage.
I want to use this list to try to keep up with TCP/IP,
not to listem to re-hashed month old arguments about viruses. That belongs
somewhere else.

Thanx,

Scotty


'God invented Unix when he had to save printer ribbons'

-----------[000503][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 08:22:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   Re:  Food for thought
This is to elaborate on David Herron's reply, about MMDF.

The philosophical differences between sendmail and MMDF have always been
quite basic.  sendmail puts essentially full address parsing and mapping
decisions into the hands of the system administrator.  MMDF builds the
rules into code and gives the administrator access to certain parameterized
choices.  While the latter would seem to be simpler for administrators, the
presence of the domain system, as a logical indirection to the routing
information, makes the actual practise more painful that one would like.

In any event, when a message comes in, from ANYWHERE, address specifications
are mapped to a single canonical representation.  The works because,
ultimately, addresses reduce to a routing sequence.  That is, most of the
brouhaha about addresses has to do with syntax.  The range of semantic
choices seems to be rather small.

When the message is being sent, the channel doing the sending knows how to
map from canonical to channel-specific format.  This is built into the code.

To anticipate a concern:  You might fear that this makes MMDF too rigid in
its address handling.  To some extent, this is correct.  And intentional.

In reality, it is not very often that a new mapping algorithm needs to be
invented.  On the other hand, configuration files need to be built quite
frequently.  The world is quite sensitive to incorrect mappings and it is
not always easy to specify the mapping -- Eric Allman's efforts with
developing a language for it, in sendmail, were quite impressive -- and,
sure enough, random folk like system administrators, get it wrong frequently.

Hence the decision to bury as much of this thought into rigid code.

Dave

-----------[000504][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 01:07:48 GMT
From:      ICHII@JPNKEKVM.BITNET (Shingo Ichii)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 on WIN/TCP for VMS

I'm very interested in tn3270 on VMS too.  Please post the summary.
Shingo Ichii
KEK, Tsukuba
Japan

-----------[000505][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 01:16:35 GMT
From:      hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting Vendors To Fix Bugs

Hi Hubert Daugherty {hd@kappa.rice.edu}

for a secure Ethernet, look at DEC's DESNC Ethernet encryption box.

Cheers
Heng-Wah Choy
Software Specialist
Singapore Software Services
{ZPOSWS|ZPOVC|ZPOACT}::HWCHOY
Heng-Wah Choy @ ZPO

-----------[000506][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 03:32:38 GMT
From:      morgan@polya.Stanford.EDU (Robert L. Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: Dynamic IP address assignment


wdw@aucs writes:

> Does anyone know of an RARP implementation that dynamically assigns IP
> addresses from a pool? Obviously this would be appropriate only for
> machines such as PC's in a public location where the current user may
> care less what his IP address is.

There's much gnashing of teeth about this issue going on at several
sites, including ours.  There are, as far as I know, no distributable
implementations yet.  There are a variety of problems that need to be
addressed with such a mechanism, including how the address is chosen,
when it is OK to reuse it, ARP caches in other hosts and gateways on
the LAN, robustness in the face of server crashes, etc.  Stay tuned.

 - RL "Bob" Morgan
   Networking Systems
   Stanford

-----------[000507][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Nov 88 10:47:36 EST
From:      ron@hardees.rutgers.edu (Ron Natalie)
To:        perry@mcl.unisys.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  passwords
I wasn't trying to break into MCL or going around testing things.
I was trying to point out that disabling accounts just because
people have been banging at the passwords has more implications
than implied by your guidelines.  Believe me, people will find
it just as serious a problem when they find out that anyone else
on the net can turn their account off at will.

Lighten up, geez.

-----------[000508][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 10:51:00 GMT
From:      u320@CBEBDA3T.BITNET (Martin Egger)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for PDP-11/73 under RSX-11


We are looking for any TCP/IP SW/HW combination running on a
PDP-11/73 (QBus) under RSX-11. Is there any?

(Please send the answer directly to my - I'am not on the list. If
there is anything of interest, I'll put a summary.)

-- Martin Egger
-- University of Bern, Dept. of Organic Chemistry
-- Freiestrasse 3, CH-3012 Bern / Switzerland
-- Phone: ++41 (0) 31 65 43 28
-- eMail: u320@cbebda3t.bitnet

-----------[000509][next][prev][last][first]----------------------------------------------------
Date:      21 NOV 88   10:51  GMT
From:      u320%CBEBDA3T.BITNET@CUNYVM.CUNY.EDU  (Martin Egger)
To:        tcp-ip@sri-nic.arpa  (tcp-ip)
Subject:   TCP/IP for PDP-11/73 under RSX-11

We are looking for any TCP/IP SW/HW combination running on a
PDP-11/73 (QBus) under RSX-11. Is there any?

(Please send the answer directly to my - I'am not on the list. If
there is anything of interest, I'll put a summary.)

-- Martin Egger
-- University of Bern, Dept. of Organic Chemistry
-- Freiestrasse 3, CH-3012 Bern / Switzerland
-- Phone: ++41 (0) 31 65 43 28
-- eMail: u320@cbebda3t.bitnet
-----------[000510][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 1988 20:11 EST
From:      bhoward@sol.engin.umich.edu
To:        law@louie.udel.edu, tcp-ip@sri-nic.arpa
Subject:   Re: rtm and uucp
	From louie.udel.edu!law Mon Nov 21 18:22:58 1988
	From: law@louie.udel.edu
	Sender: tcp-ip-request@sri-nic.arpa
	To: tcp-ip@sri-nic.arpa
	Date: 13 Nov 88 19:24:53 GMT
	Organization: University of Delaware
	Message-Id: <5356@louie.udel.EDU>
	References: <8409@alice.UUCP>, <8597@rpp386.Dallas.TX.US>
	Subject: Re: rtm and uucp
	
	In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
	>It would be so nice if someone would undertake a security audit to
	>insure that work other college students did, which *is* currently
	>in production, doesn't contain any surprizes.
	>Our friendly enchilada may not be the only prankster out there ...
	I sincerely hope you are not making a general statement about college
	students.  I take great pride in the fact that UDel allows some students
	to work at the system level, even in system administration, I happen
	to be one of those students and have taken slight offense to the recent
	messages that seem to knock college students as being like RTM.  Not
	all of us write worms and think about how to break security in our spare
	time.
	 
	--
	Jeffrey A Law
	University of Delaware  PHONE: (302)-451-8005,  (302)-451-6339
	ARPA: law@udel.EDU,  UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!law
	
the computer aided engineering network (caen) at the university of michigan depends
on a core of 23 fulltime professionals and a roughly equal number of "student"
professionals to maintain our network of 500+ apollos, 50+ suns, 350 macs and maciis
and assorted ibm machines.  the distinction is mostly an artificial one, emphasizing
a difference in pay, rather than responsibility or skill.  these students are help
maintain basic systems services, software development and (perhaps not surprisingly)
systems security.  they are routinely given the root password and determine with
the rest of the systems group who else also requires its use.  there has never been
any question of their integrity.

the suggestion that college students are any more unreliable as a group than, for
example, professional systems staff, is unfounded.  people respond as they are treated;
if treated as responsible members of the computing community, in general, they will
respond in kind.  if constantly placed in an adversarial role, they become your nemesis.

					bruce howard
-----------[000511][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 16:15:55 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Van Jacobson TCP mods (in_cksum.c)


	I'm just getting around to installing the Van Jacobson TCP mods in
our MtXinu 4.3BSD/NFS Vax.  I noticed that in_cksum.c is in netinet/
instead of machine/.  Am I correct in assuming that I should NOT install
the portable version, but rather stay with the vax-optimized one I already
have?

	I'm also assuming that these mods should just drop in to both my
MtXinu Vax and my Suns runing SunOS-3.5.2.  Yes?  Or does 3.5.2 already
have Van Jacobson in it, in which can I need not bother?  I suspect the
latter might be the case since we already get far better ftp performance
over a serial link from our Suns than from our Vax (i.e. 80% of the 64 kbps
theoretical bandwidth available instead of 10-15%).
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

-----------[000512][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 16:22:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Food for thought

This is to elaborate on David Herron's reply, about MMDF.

The philosophical differences between sendmail and MMDF have always been
quite basic.  sendmail puts essentially full address parsing and mapping
decisions into the hands of the system administrator.  MMDF builds the
rules into code and gives the administrator access to certain parameterized
choices.  While the latter would seem to be simpler for administrators, the
presence of the domain system, as a logical indirection to the routing
information, makes the actual practise more painful that one would like.

In any event, when a message comes in, from ANYWHERE, address specifications
are mapped to a single canonical representation.  The works because,
ultimately, addresses reduce to a routing sequence.  That is, most of the
brouhaha about addresses has to do with syntax.  The range of semantic
choices seems to be rather small.

When the message is being sent, the channel doing the sending knows how to
map from canonical to channel-specific format.  This is built into the code.

To anticipate a concern:  You might fear that this makes MMDF too rigid in
its address handling.  To some extent, this is correct.  And intentional.

In reality, it is not very often that a new mapping algorithm needs to be
invented.  On the other hand, configuration files need to be built quite
frequently.  The world is quite sensitive to incorrect mappings and it is
not always easy to specify the mapping -- Eric Allman's efforts with
developing a language for it, in sendmail, were quite impressive -- and,
sure enough, random folk like system administrators, get it wrong frequently.

Hence the decision to bury as much of this thought into rigid code.

Dave

-----------[000513][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 16:58:00 GMT
From:      zweig@p.cs.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Virus Terminology Survey


  There have been a number of not-always-consistent schemes for talking
about nasty things on both the InterNet and on PC's and Mac's and stuff
floating around the net and the news media these past few weeks.
Perhaps the TCP-IP group can come up with a definitive nomenclature.
  Here is an off the cuff reading of what I can remember/surmise from what's
been floating around:

VIRUS -- a program which replicates itself and causes damage; so-called
  because of similatrites to viruses which make people/animals sick.

WORM -- a program which copies itself to other systems over a network.
  Sometimes it seems to be taken for granted that worms are nasty, others
  it seems necessary to add modifiers to that effect.

TROJAN HORSE -- a program which sits on a system until someone runs it;
  then it attacks the system using the priviledges of whoever activated
  it. Since this term is taken from Greek mythology, a TH is always nasty
  (the image is something that you let into your address-space/file system
  and something leaps out of it and kills you).

MOLE -- a program which sneaks into systems via a method not normally
  known/allowed. I think -- there seem to be other conflicting usages
  out there.

LOGIC BOMB -- a program/process which causes havoc ("explodes") when a
  certain logical criterion is met -- usually when a certain time has
  elapsed. I have heard these called "sleepers" since a LB sleeps until
  it is supposed to go off.

HACKER -- a person who maliciously breaks into systems. I hate this term,
  since I call myself a hacker pretty often. CRACKER is a better term,
  much more widely used in Europe I am told ("crackers are" in British
  slang). Hacker originally referred to someone who could look at
  10,000+ lines of assembly code and figure out the 6 bytes that needed
  to be changed (a "hack" at the giant block of code) to fix the thing.
  It is supposed to be a term of some reverence indicating someone who
  both fervently and successfully pursues a given discipline. Thus terms
  like "UNIX hacker", "AI hacker", "Network hacker" and "cracker hacker."

HOLE -- an aspect of a program which allows unauthorized/unexpected use.
  (Other, of course, than mere existence which has also been cited as a
  widely-exploited security loophole in much software.)

Not all of these terms are mutually exclusive: the Morris worm can be
viewed as a virus as well as a mole, given the above definitions.

I'd appreciate postings/e-mail of other terms/usages people have seen
and/or are using. Maybe we could get UPI to broadcast a list so the
news media will start calling a spade a spade, a hacker a hacker, a
worm a worm and so forth....


Johnny Zweig
University of Illinois at Urbana-Champaign
Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------

-----------[000514][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 17:25:13 GMT
From:      kwang@bud.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Performance

Recently, I improved "ftp" in one of our products which is 4.2BSD based.
When I typed ftp> bin
             ftp> get /syst /dev/null, 
I had:
             351465 bytes received in 1 second ( 3.4 e + 02 Kbytes/sec )

I didn't use Van Jacobson's Algorithm.

Is there anybody has better "ftp" performance than mine ???

Bye Bye

Kwang Sung
Sr. Software Engineer
ARIX Corp
408-922-1822
408-251-5040(H)
UUCP: ...!sun!aeras!smaug!kwang
.

-----------[000515][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 18:23:56 GMT
From:      trn@aplcomm.jhuapl.edu (Tony Nardo)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.wizards,news.admin,news.sysadmin,news.groups
Subject:   Re: comp.security - LET'S DO IT!  CALL FOR VOTES

In article <32417@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes:
>In article <5493@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes:
>}There is a misc.security already - don't believe there has been anything
>}in it for quite some time.
>
>[description of fact that misc.security moderator has been unable to reconnect
> to news world for 8 months...]
>Instead of rushing off to start a new newsgroup, why don't we just unmoderate
>misc.security and see how it works moving all of the security stuff OUT of
>the random newsgroups for a while.

While I'm in favor of a system security group, I an *not* in favor of an
unmoderated group.

Moderation of the group would accomplish two positive goals:

	1) help reduce S/N ratio, and
	2) keep overly-descriptive articles from being posted.

I can apprieciate the latter goal as a means of protecting the poster as well
as the rest of the Usenet community.  There are some people (myself included)
who find it difficult to describe the solution to a problem without describing
the problem itself in nit-picking detail.

Perhaps we should form comp.security with a new moderator.  I assume that we
will be discussing *computer* security, not miscellaneous security issues.


Note that the followup field is restricted to news.groups.

===============================================================================
ARPA, BITNET:   trn@aplcomm.jhuapl.edu
UUCP:		{backbone!}mimsy!aplcomm!trn

50% of my opinions are claimed by various federal, state and local governments.
The other 50% are mine to dispense with as I see fit.
===============================================================================

-----------[000516][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 18:26:04 GMT
From:      morgan@Jessica.stanford.edu (RL "Bob" Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: Morris bashers...


Milo Medin writes:

> ... let's not forget this was a computer problem, not a network problem.

I'd like to see people think of it as a "networked computer problem".

The point is that our major operating systems, Unix in particular,
were designed in the era of unconnected machines, hardwired terminals,
and small, computer-knowledgeable user communities.  We have seen
substantial improvements in ease of use, and we now know how to design
communication hardware and software to get reasonable performance from
systems attached to large heterogeneous networks.  We are still a long
way from any general acceptance of the fact that our networked
environment requires a fundamental rethinking of the concepts of
"users" and "systems", the vigilance with which machines must defend
their integrity, and the protocols and services by which reliable
communication is accomplished.

There's important research going on in these topics.  One can only
hope that the worm incident will encourage more people to pursue this
research, and more computer vendors and system designers to implement
systems based on their results.  If this doesn't happen, the days of
our useful, open networks will be numbered.

 - RL "Bob" Morgan
   Networking Systems
   Stanford University

-----------[000517][next][prev][last][first]----------------------------------------------------
Date:      MON, 21 NOV 88 10:07:48 JST
From:      Shingo Ichii <ICHII%JPNKEKVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: tn3270 on WIN/TCP for VMS
I'm very interested in tn3270 on VMS too.  Please post the summary.
Shingo Ichii
KEK, Tsukuba
Japan
-----------[000518][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 19:17:29 GMT
From:      bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic)
To:        comp.protocols.tcp-ip
Subject:   UNIX security


There are two points I would like to make regarding recent articles I've
seen on tcp-ip, phage, comp.unix.whatever and several other mailing lists.

The first concerns the widespread belief that "everybody" knew about the
bugs used by the worm.  This is not true.  Rick Adams has been trying to
contact "everybody" for about two weeks and he's come up emptyhanded.  The
number of people that knew about fingerd seems to be less than five, with
a like number knowing about the sendmail debug problem.  Counting whomever
wrote the worm.  Neither Sun nor UC Berkeley knew about the bug.

My second concern is the equally widespread belief that UNIX isn't secure
and that it cannot be made secure; this belief is typified by quotes along
the lines of "I have known about the security holes in Unix for almost ten
years" and "I've got lists of UNIX security problems you wouldn't believe."

UNIX is neither more or less secure than any other general purpose operating
system I'm aware of.  It can be made as secure as you wish -- Gould, Sun,
and AT&T, among others, have done interesting work in this area.

Now, the lists of security problesm, the ten-year-old bug lists, and the fact
that the tiger team from somewhere broke the su command in 1970-something,
that's ancient history.  UNIX is a fairly fast moving target, and we might as
well get used to that.  It's a feature, not a bug.  Ten years ago we were
running Version 7 on PDP 11/34's; I trust that most of the split I/D security
issues have been addressed.

Keith Bostic

-----------[000519][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 19:28:33 GMT
From:      alex@aipna.ed.ac.uk (Alex Zbyslaw)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Laser printers on the ethernet


We might want to get a laser printer that sits on the ethernet sometime in
the near future.  Is there anything in particular to be wary of?  Are there
any tests to carry out?  Too many machines seem to generate ethernet garbage
these days and I wouldn't like to be lumbered with another one.

Please reply by email and I will summarise.  Thanks in advance,

--Alex

     JANET:  alex@uk.ac.ed.eusip	ARPA:   alex%ed.eusip@nss.cs.ucl
	    UUCP:   ...{uunet, decvax, ihnp4}!mcvax!ukc!eusip!alex
        [CSNET BITNET]:  alex%ed.eusip%nss.cs.ucl@[csnet-relay cunyvm]

-----------[000520][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 88 19:43:53 GMT
From:      mckenney@distek4.uucp (Paul E. McKenney)
To:        comp.protocols.tcp-ip
Subject:   Re: password aging (from worm discussion)

In article <8811181901.AA12769@pinocchio.UUCP> bzs@pinocchio.UUCP
(Barry Shein) writes (in regard to shadow password files):
>>> You're turning the file into pure gold.
>> [ . . . ]
>>But even if someone did capture a copy of a shadow pw file, you'd only be
>>in the same situation you always were when /etc/passwd contained passwds.
>>So is it really the kind of catastrophe you suggest?
>>	Stuart Levy
>That's the idealized situation. In reality once you've decided that
>the security of your system depends on the read security of one file
>then any breech of that must be responded to, common sense would
>dictate it. Otherwise, why did you make it unreadable? I don't think
>going forth with the idea "oh, we did it, but we never *really* needed
>to, it doesn't matter if a copy got out" is a rational approach.
> [ . . . ]
>I still contend it's a bad idea, concentrate on the other aspects.
>If some form of publicly readable encryption is deemed impossible
>as a concept I sincerely hope that argument gets published.
>	-Barry Shein, ||Encore||

World-readable encrypted passwords allow an attacker to verify that he
has correctly guessed a particular password, and to perform this verification
on a host other than the one being attacked.

This will allow the attacker to crack a significant fraction of the
passwords (I have seen claims that over 30% of passwords are easily
guessed) without leaving any traces of his attack, aside from a single
(possibly legitimate) access to the system using the privileges of a
normal user.  Even if all passwords are well-chosen, the attacker has
a non-zero chance of guessing a given password.  If the attacker has
enough fast hardware at his disposal, he may in fact have a pretty
good chance.  And there is always the chance that someone might come
up with a clever attack on DES . . .

Given a properly implemented and configured shadow password file, the attacker
must have privileged access to the machine to get the encrypted passwords
(assuming that all people that -do- have such know not to release the
encrypted passwords).  The attacker can of course use the target host's
own login prompt to verify guesses at passwords, but this sort of activity
should alert the host's administrators.

If someone who does not have legitimate privileged access to the machine
is seen with a list of the encrypted passwords, it can be assumed that the
host's (network's) security has been compromised, and appropriate steps
can be taken.

It is still a good idea to encrypt the passwords (rather than relying solely
on the filesystem permissions) in order to reduce vulnerability to the
infamous ``disgruntled employee'' security hole.

In short, the idea behind shadow password files is to make it at least as
difficult to crack a password as it is to crack the system itself.
This is an especially good idea for machines that have a password for
the user ``root''.

					Thanx, Paul

-----------[000521][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 01:11:00 GMT
From:      bhoward@SOL.ENGIN.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: rtm and uucp


	From louie.udel.edu!law Mon Nov 21 18:22:58 1988
	From: law@louie.udel.edu
	Sender: tcp-ip-request@sri-nic.arpa
	To: tcp-ip@sri-nic.arpa
	Date: 13 Nov 88 19:24:53 GMT
	Organization: University of Delaware
	Message-Id: <5356@louie.udel.EDU>
	References: <8409@alice.UUCP>, <8597@rpp386.Dallas.TX.US>
	Subject: Re: rtm and uucp
	
	In article <8597@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
	>It would be so nice if someone would undertake a security audit to
	>insure that work other college students did, which *is* currently
	>in production, doesn't contain any surprizes.
	>Our friendly enchilada may not be the only prankster out there ...
	I sincerely hope you are not making a general statement about college
	students.  I take great pride in the fact that UDel allows some students
	to work at the system level, even in system administration, I happen
	to be one of those students and have taken slight offense to the recent
	messages that seem to knock college students as being like RTM.  Not
	all of us write worms and think about how to break security in our spare
	time.
	 
	--
	Jeffrey A Law
	University of Delaware  PHONE: (302)-451-8005,  (302)-451-6339
	ARPA: law@udel.EDU,  UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!law
	
the computer aided engineering network (caen) at the university of michigan depends
on a core of 23 fulltime professionals and a roughly equal number of "student"
professionals to maintain our network of 500+ apollos, 50+ suns, 350 macs and maciis
and assorted ibm machines.  the distinction is mostly an artificial one, emphasizing
a difference in pay, rather than responsibility or skill.  these students are help
maintain basic systems services, software development and (perhaps not surprisingly)
systems security.  they are routinely given the root password and determine with
the rest of the systems group who else also requires its use.  there has never been
any question of their integrity.

the suggestion that college students are any more unreliable as a group than, for
example, professional systems staff, is unfounded.  people respond as they are treated;
if treated as responsible members of the computing community, in general, they will
respond in kind.  if constantly placed in an adversarial role, they become your nemesis.

					bruce howard

-----------[000522][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 02:02:26 GMT
From:      johnm@vaxc.cc.monash.edu.au (John Mann)
To:        comp.protocols.tcp-ip
Subject:   Re: Worms and fixing blame

In article <8811100539.AA27545@ACC-SB-UNIX.ARPA>, lars@ACC-SB-UNIX.ARPA 
(Lars J Poulsen) writes:
> As a minumum, everybody who buys system software should add the following
> clause to their purchase orders: "The system shall identify each user by
> a unique user identification, and password validation shall be used to
> ensure that no unauthorized access occurs". This will ensure that you can
> hold the vendor liable for losses you might incur in a situation like this.

Does this mean that everyone who wants to send mail to your machine has
to have their own usercode and password on that machine?

I guess this also means that the vendor has to disble the ".rhosts" facility
to prevent users from being able to open up their own security.
Are you going to disable other TCP/IP services like finger?  ARP?

I am not trying to put you down, just raise the question of what you really
mean by "authorized" and "access".  Does running a TCP/IP server of any
type automatically "authorize" everyone to "access" your system.  Does putting
your machine on Ethernet/modem connection "authorize" other people to send
packets to it/dial you phone number.

I presume someone will say that by "access", it really means people 
"Logging on" where they shouldn't.  But the worm didn't involve a person 
"Logging on" where they shouldn't.  

Didn't the worm invoke Telnet where it had guessed the password?  If it had
a valid username and password, it is by definition "authorized" isn't it?

> UCB, of course would likely refuse to accept this responsibility, thus
> making the problem with non-commercial software explicit.

I guess they could say that straight off the tape the netwoking doesn't work
(not configured etc.), and you don't *have* to turn the networking on. :-)

	John
--
John Mann, Systems Programmer, Computer Centre, Monash Uni. VIC 3168, Australia
Internet: JohnM@Vaxc.CC.Monash.Edu.Au   Phone: +61 3 565 4774

-----------[000523][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Nov 88 11:34:35 -0500
From:      kolb@nisc.nyser.net
To:        leo@wheaties.ai.mit.edu (Leonardo C. Topa)
Cc:        tcp-ip@sri-nic.arpa, kolb@nisc.nyser.net
Subject:   Re: subscription


	done!

	chris kolb
	kolb@nisc.nyser.net
-----------[000524][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 03:14:53 GMT
From:      pavlov@hscfvax.harvard.edu (G.Pavlov)
To:        comp.protocols.tcp-ip
Subject:   Re:  "Morris did it"--the new excuse?

In article <8811142005.AA02573@milk10>, robert@SPAM.ISTC.SRI.COM (Robert Allen) writes:
>       (re the autjor of the worm): 
> 	
>   ......  He DIDN`t tell anyone how to combat it when it got out of control,
>   nor did he come forth to assure people that the virus was benign.  This
>   is a mistake that I might expect of a freshman student, but certainly not
>   a grad student.  This single fact is the most damning of the perpetrator
>   in my opinion.  

    I don't defend the individual.  But I would not interpret his failure to
    communicate as a sign of malevolence.  I assume that he became scared and
    panicked.  It's happened to the best of us.

    greg pavlov, fstrf, amherst, ny 

-----------[000525][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 04:25:05 GMT
From:      hd@kappa.rice.edu (Hubert D.)
To:        comp.protocols.tcp-ip
Subject:   Re: callable ftp library

Having just snarfed the pcip package from MIT and CMU I noticed
the obvious lack of an ftp package.  There is a tftp application
but it doesn't include the init functionality.  If anyone has
a PD implimentation which uses the pcip libraries or knows of the
location of same, please send me mail.

Hubert Daugherty
hd@rice.edu

-----------[000526][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Nov 88 11:21 EST
From:      "John G. Ata" <Ata@RADC-MULTICS.ARPA>
To:        bostic%okeeffe.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Keith\, Bostic)
Cc:        tcp-ip@SRI-NIC.ARPA, phage@PURDUE.EDU
Subject:   Re: UNIX security


    From:  bostic%okeeffe.Berkeley.EDU at UCBVAX.BERKELEY.EDU (Keith Bostic)
    Subject:  UNIX security
    
    UNIX is neither more or less secure than any other general purpose operating
    system I'm aware of.  It can be made as secure as you wish -- Gould, Sun,
    and AT&T, among others, have done interesting work in this area.

My apologies for continuing the security discussion on the TCP/IP list,
however, I feel that I must reply to the above comment which shows a
profound lack of understanding of general operating system security.

Such a blanket statement on security in general implies that all general
purpose operating systems in existence have the SAME level of security
built into each one of them.  This is simply NOT the case.  If it were,
then measuring levels of operating system security (such as what NCSC
does) wouldn't make any sense.  It turns out, that if one looks at the
operating systems that have been evaluated, some have indeed done better
than others.  In some systems, security has been carefully architected
from the design phase, while in other systems, it has been added as an
afterthought.  Needless to say, this does not yield identical results.
While it's true that Gould, etc. have done work on providing a MORE
secure UNIX, that is really relative to the non-enhanced versions and
does not even boast a security rating that would allow DOD to run
multi-level security.  That is not to say that one day, a version of
UNIX won't exist with a higher security rating, but today it just isn't
there.

I am not trying to bash UNIX, I'm just trying to correct a misconception
that your comment raised.

                                        John G. Ata
-----------[000527][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Nov 88 11:37:11 est
From:      Barry Shein <encore!pinocchio!bzs@talcott.harvard.edu>
To:        jbvb@vax.ftp.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   System security & networks & vendors

From: jbvb@vax.ftp.com (James Van Bokkelen)
>If I can get sued for negligence for not padlocking the gate to my home's
>swimming pool, I don't think you can call it justice to imprision or even
>fine Mr. Morris.

That makes no sense, the alleged Morris can't claim in a defense to
have been a victim of an unsecured system. You're utterly confused.

A more apt example might be if you were sold a car with a design
defect making it especially easy to get in and steal your radio you
might well have a gripe against the manufacturer, but that in no way
exonerates whoever stole your radio, they still committed a crime,
both could be culpable. There's no need in law for exactly one party
to be held responsible for something, multiple parties can be held
equally or partially culpable, it's not physics.

Actually, these pseudo-legalese arguments only seem to indicate
people's emotions, lack of understanding of the law and most
importantly their personal gripes about perceived injustices which is
what I assume motivated the comment about swimming pools. I suppose
sooner or later someone will tie it all into welfare abuse...

	-Barry Shein, ||Encore||


-----------[000528][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 09:48:58 GMT
From:      thomas@uplog.se (Thomas Hameenaho)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson TCP mods (in_cksum.c)

In article <3610@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>	I'm just getting around to installing the Van Jacobson TCP mods in
>our MtXinu 4.3BSD/NFS Vax.

Where do I get it from?
-- 
Real life:	Thomas Hameenaho		Email:	thomas@uplog.{se,uucp}
Snail mail:	TeleLOGIC Uppsala AB		Phone:	+46 18 189406
		Box 1218			Fax:	+46 18 132039
		S - 751 42 Uppsala, Sweden

-----------[000529][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 10:47:58 GMT
From:      ICHII@JPNKEKVM.BITNET (Shingo Ichii)
To:        comp.protocols.tcp-ip
Subject:   Re: A supdup client for X Windows?

>
>I have seen various public-domain supdups written at MIT, but none
>that runs under X.  Any suggestions as to where to look?
>

How can I get and use supdups (original version, not on X, of course)?
Please show me the pointer to it.  Thank you.

Shingo Ichii
Data Handling Center
National Laboratory for High Energy Physics (KEK)
Tsukuba 305 Japan

-----------[000530][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 16:10:52 GMT
From:      dji@sbcs.sunysb.edu (the dirty vicar)
To:        comp.protocols.tcp-ip
Subject:   Re: Virus, Worm or?


Robert Butler says:
> What I'm hearing is a lot of protectionism for a programmer. Like we need
> more of his quality to keep the paranoid security wraps on this middle-aged
> Internet. Does anyone think `wormer' will get his hands slapped, providing
> the allegations are true?

	I hope he gets more than a hand-slapping, but somehow I doubt it.
On the other hand, I don't think he should be fined excessively or (certainly
not) put in prison.  It was not a malicious action.  What then??  I don't
know.  Probably he should be kicked out of Cornell.  Maybe a reasonable fine
and public service??

> The cost to Internet alone will be in the millions of dollars figure (all
> those leased lines). Then add in all the lost computer time for another
> hundreds of millions of dollars figure.

	These figures seem completely outrageous to me.  Would you like
to try to justify them?

> What ever happend to "Integrity"?  I have a personal integrity that will not
> allow me to do what was done. I do believe that I know right from wrong and I 
> will not do wrong, by conscious choice. Simplistic hey!.

	That's wonderful, so do I.   But there's no use complaining about
lack of integrity and morality in society, because it has pretty much always
been the exception rather than the rule, and will no doubt continue to be
so, and probably get worse.

> What would a drug dealer do if someone cost him several hundreds of dollars, 
> intended or accidentally? I guarantee that he will make an example for others
> that that is not acceptable behavior. Is this the type of mentality or
> attitude that we want?           

	Huh??  Do you mean the mentality of exacting retribution, or the
mentality that caused the worm?  In any case, what would you suggest be
done to RTM??  Try to keep something in mind.  The mentality that caused
the worm is little more than boyish mischief.  Until recently, there was
not much a little pranksterism could do to cause serious wide-scale harm.
But the information revolution is at hand -- the world is a far smaller
place than it used to be.  Society at large has yet to adjust to many
of the changes that have taken place recently, and here's someone who
has grown up in the computer age, knowing no other way of life.  We should
KEEP THINGS IN PERSPECTIVE.  Computer down-time and system administrator
inconvenience are not reasons to hang someone by the testicles.  I won't
defend him for pointing out a particular hole in UNIX, but the incident
*has* brought the issue of computer security into the public conscious-
ness, which is a good thing.  Punish him, but don't make him out to be
public enemy number one.  We should be far more concerned with murderers
and rapists getting off the hook.

--
 Dave Iannucci   Computer Science, SUNY at Stony Brook, Long Island, New York
///////////////  UUCP: {allegra, philabs, <arpa-gateway>}!sbcs.sunysb.edu!dji
\ Beru lives! \  ARPA-Internet or CSNet: dji@sbcs.sunysb.edu
///////////////  BITNET: dji%sbcs.sunysb.edu@SBCCVM.BITNET

-----------[000531][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 17:52:05 GMT
From:      mo@prisma.UUCP
To:        comp.protocols.tcp-ip
Subject:   FDDI headers


Why not just define the official Internet Encapsulation(s) on
FDDI to require alignment to a 32-bit boundary.  At worst you
burn a few bytes at the front of a packet.

	-Mike O'Dell

-----------[000532][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 18:04:57 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Dynamic IP address assignment


   From: agate!bionet!lear@ucbvax.Berkeley.EDU  (Eliot Lear)
   Organization: Natl Computer Resource for Mol. Biology

   Wouldn't you run into a problem with ARP caches if you dynamically
   assign internet addresses to ethernet based machines?

   Eliot

Possibly, but probably not.

If you dyanically assign a machine to an address that either hasn't
been used before, or hasn't been used in a long enough time that
everyone's ARP cache has timed out, you have no problem.

If a machine is assigned an IP address for which ARP cache entries do
exist on the local ethernet pointing to a different ethernet address,
you still might not lose.  Since you've just assigned this dynamic
address, this new machine probably has an empty ARP cache which it
will need entries in before it can talk to any other hosts.  In the
process of sending ARP requests for other hosts, those other hosts
will get the new mapping for this host.

So the only problem is if a machine which has a stale ARP entry
attempts to contact this new machine, rather than the new machine
contacting it.

A way to avoid this entirely is to have the new machine broadcast an
ARP reply when it starts up.  This gratuitous ARP reply will prime
everyone's cache with its information.  Some operating systems do this
(broadcast) already, and every ARP implementation following the RFC
will get its cache primed.
					-Mark

-----------[000533][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 19:17:46 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: An Obvious Security Problem?

In article <2215@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes:
>In article <881109143927.20402284@Csa3.LBL.Gov> forrest@CSA3.LBL.GOV writes:
>    (Node M is actually one or more gateways.) Couldn't a bad guy
>    on   M   monitor   the  TCP/IP  traffic  looking  for  Telnet
>    connections and then follow through  the  exchange  of  login
>    names  and  passwords,  thereby  capturing  a  node/login and
>    password pair? (I realize that  the  path  from  A  to  Z  is
>    dynamic and that this might not always be possible.)
>
>The DoD people have a solution: encrypt the comm-line.  There  is
>a  secure  version  on  the  Internet  that does just that.  Even
>better is to use end-to-end encryption  for  each  communications
>circuit.  The  basic  problem  with all of this is the encryption
>overhead and the key and authentication problems.

	Link encryption won't solve this problem.  The two links are
encrypted independently and someone with access to the system M could
still pick up traffic and snoop ids and passwords.
	You need either a trusted router (trusted network actually); or
application layer encryption, which is not part of telnet, to avoid
snooping from inside the network.
	Secure networks or secure applications.  Better both.

-----------[000534][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 19:43:16 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Dynamic IP address assignment

In article <Nov.20.13.30.19.1988.26043@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes:
>Wouldn't you run into a problem with ARP caches if you dynamically
>assign internet addresses to ethernet based machines?

	Age the arp cache.  Then set a "re-use" timer on the IP
address to be, say 3x, the arp cache time-out.
	Of course, how do you know when an IP address is released?
There oughta be a protocol.

-----------[000535][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 21:57:27 GMT
From:      HEILNER_K@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   DEC and TCP/IP

Greetings -


	Is anyone out there thinking about, or in the process of developing
applications that will run on top of DEC's TCP/IP. For example, TELNET,
SMTP, FTP. It is my understanding that DEC will only be releasing enough
of the protocol stack to implement a NFS. 



Keith Heilner
Network Coordinator
Stevens Institute
------------

-----------[000536][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 88 22:16:33 GMT
From:      swatt@rt1.eng.yale.edu
To:        comp.protocols.tcp-ip
Subject:   Toward Better Security

From: Alan S. Watt <swatt@rt1.eng.yale.edu>

     To: The Internet
   From: Alan S. Watt
   Date: 10-November-88
Amended: 22-November-88
Subject: Towards Better Computer Security

The recent discussions on the internet virus were interesting and
informative, but I do not see any convergence on what to do about The
Bigger Problem of foiling future virii.  One camp favors the "... take
him out and shoot him as a deterrent" approach; the other camp has the
"... we should be grateful he dramatized these long-latent weaknesses"
view.  While there is some justification in both views, neither really
provides any direction to take which will give us any improved
security.

There are also some who regret that all the publicity is going to
result in more restrictions, I suppose taking the view that we are all
consenting adults and we "should have known" the whole network is
insecure.  I must register a strong rebuttal to complacency in computer
security; computer and computer-controlled systems are coming to
dominate more and more operations which make up our daily lives.  The
foundations of our commercial and social services are increasingly
computer-mediated, if not outright computer-controlled.

No Big Deal?
------------
Computers keep my bank account, transfer money from Yale's bank to
mine, control stock and bond trading, keep track of planes in flight,
land the space shuttle, time the fuel injection in my car, control
brakes in some new cars, etc., etc.  The list is very long and becoming
longer every day.  It is at the point where people sufficiently expert
in compromising these computer systems could steal billions of dollars,
disrupt national air traffic (perhaps even cause crashes), and so on.
My point here is that when the potential gain, either in stolen money,
or political effects, of computer-assisted crime gets large enough, you
can be sure someone will work very hard to find a way.

We should all be concerned with computer security, and in a much wider
sense than just keeping someone from breaking into "our" system.  The
social consequences of a deliberate, organized, and large-scale assault
on our computer systems of today are hard enough to enumerate; the
effects after 5 or 10 more years of computerization probably cannot be
imagined.  Think of the mafia gaining control of promising young
computer professionals through bribery and intimidation and ask
yourself where that leads.  What happens when white collar computer
crime gets "organized"?

The Political Response
----------------------
All of this reminds me of the hysteria some months back over the
dangers to air safety posed by so-called "plastic guns".  The news
media, ever in need of sensational stories, totally ignored repeated
authoritative statements (from the FAA, from the manufacturers of
airport X-ray equipment) that the particular gun in question (Glock-17)
was easily detectible on current equipment which was properly adjusted
and maintained and staffed by properly alert operators.

The Congress, ever in need of appearing to "do something", promptly
readied legislation to "cure" this problem by outlawing "plastic
guns".  Never mind audits by the FAA and GAO which showed lax airport
personnel and procedures were the most prevalent and easiest ways to
sneak weapons or explosives on board; the "plastic gun" scare got
everybody's attention and Congress would remove the threat by making
them illegal.  Lost in the predictable pro- vs. anti-gun debate which
ensued was the original goal to improve airport security.

I suspect we will face this same mindless approach to computer security
sometime soon.  The press will do their usual sloppy (or outright
distorted) job of reporting some incident, and the Congress will enact
some ill-considered and possibly damaging legislation just to appear
busy.  I have really been surprised by the extent (but not the
quality!) of media coverage given to this incident.  Given the
visibility, it can't be too long before legislation results.

The Ethics Response
-------------------
There have also been proposals that we should require computer science
people to pass ethics courses, or perhaps just one-day seminars on
being a good network citizen.  While probably less damaging than letting
Congress into the act, this approach also ignores the problem.  It is
indicative of an attitude that we're all good members of "the club",
and social pressures will make us conform through fear of censure.

I believe strongly in ethics, but I believe even more strongly in a
society which is robust despite the lack of ethics in some members.
Running a bank on the honor system where depositors kept their own
balances is a prescription for bankruptcy; running a national network
assuming everyone who has access will be "ethical" is equally doomed to
failure.

The rule I use for predicting behavior of states, institutions, groups,
and individuals is simply this:

	When the interests get strong enough, the scruples get
	correspondingly weak.

You can keep most people honest enough to pass up $10; it gets
real hard to expect honesty at the level $1,000,000.

Concentrating on the Real Problem
---------------------------------
The goal should be to make computer systems more secure.  Every
proposal should be judged by this criterion.

I think people who like to tinker with breaking computer security do so
because of a special set of attitudes.  People who like to do software
testing have similar attitudes: they like to break things which other
people have said "can't" be broken.  A good software development
organization appreciates such people and rewards them when they succeed
in finding a fault.  A society truly concerned with computer security
would similarly appreciate those with the bent and persistence to prove
security defects.  The question is: how to harness the natural
tendencies of such people in a socially acceptable and technically
useful way?

Security "Privateers"
---------------------
When the airport security debate was going on, I thought the proper
approach was to issue licenses to people who wanted to try to defeat
airport security (let's call them "crackers").  Licensed "crackers"
would then be free to try to prove that security at some particular
airport could be evaded.  If they succeeded by smuggling in approved
facsimilie weapons, the FAA would impose a fine on the airport and the
cracker would get a percentage of it.

The point is, you create a financial incentive for people to go into
the business of proving airports are insecure.  If the fines are big
enough, all the easy ways to get weapons on planes will be quickly
foreclosed.  In effect, the government would issue modern-day "letters
of marque" and create airport security privateers.

The other point is that NO security system is any good unless it is
tested frequently.  If nothing else, constant cracker attempts might
make people manning those security checkpoints a lot more alert.

I believe a similar approach would have a prompt and positive effect on
computer security.  It may not solve any of the genuinely hard
technical problems, but at least it will cause all the well-known and
obvious holes to be closed.  The real question is what agency would
have authority to levy fines, and against whom?  Unlike the FAA, there
is no agency which has regulatory authority over computer vendors.
However, the federal government buys a LOT of equipment, and it could
certainly use that power to make all its suppliers fix demonstrated
security problems.

The Feds might require, for instance, that any vendor of computer or
network gear to the government maintain a sample configuration accessable
on the internet, and publicise its name and location.  Licensed crackers
would then be free to attempt computer break-ins.  If successful, the
Feds would in some manner collect money from the vendors and pay a
portion of it to the crackers.

Similarly, any government installation which has computers publically
accessible on phone lines or the internet would be required to publish
the name of one of them as the "sitting duck".  If a cracker could
break into it due to laxness of the installation administrators, the
government would impose the fine and pay the cracker.

It Won't Always Be a Prank
--------------------------
Whatever the merits of this particular proposal, we must remember that
very soon we will be faced with not just mis-guided pranksters, but
professional criminals.  The problem will not go away; we must face it
squarely and expend effort toward making our computer systems much,
much, much more secure.

	- Alan S. Watt
	  High Speed Networking, Science and Engineering Computing Facility
	  Dunham 232; (203) 432-4243,4007
	  watt-alan@cs.yale.edu

-----------[000537][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 00:26:07 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   ICMP echo of host on undefined subnet mystery

Can some one give me a reason why I can trigger beaucoup ICMP messages on
an ethernet with just one measly icmp packet?

Configuration:
			        GW for 192.5.16 (subnets 192.5.16.32 and
			               |         192.5.16.64, mask =
			               		 255.255.255.224)
			         128.165.4.16   
                                       |
	=============================================================
	   |                                                    | 
	   |                                                    |
     128.165.4.10                                         128.165.4.4
      route (192.5.16 128.165.4.16 UG ...)
      
Scenario:

	128.165.4.10 sends exactly one icmp echo to 192.5.16.1 
	   192.5.16.1 is a bogus hostname on an undefined subnet.
	   
	128.165.4.4 sends 100* ICMP packets to 128.165.4.10
	   with a 'redirect for network to 128.165.4.16'
	   
	128.165.4.10 sends 128* ICMP 'echo' packets to 192.5.16.1
	   (via 128.165.4.16)
	   
	Remember the 'ping' program only sent ONE icmp echo packet.
	   
* these are the numbers I observed.  There could have been more.

Thanks for your consideration,

Phil Wood,  cpw@lanl.gov

-----------[000538][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 02:04:34 GMT
From:      rbj@nav.icst.nbs.gov (Root Boy Jim)
To:        comp.protocols.tcp-ip
Subject:   shadow passwords?

? From: rick@seismo.css.gov (Rick Adams)

? A better implementation of shadow passwords is not to replace
? the encrypted password field with * or something obvious, but to
? replace it with the correct number of random characters. Let the
? wouldbe cracker TRY and decrypt something that isn't encrypted!

? --rick

My point exactly, except that DES is dense, that is, given all possible
64 bit codes input codes, all possible 64 bit codes will be generated.
Upon reflection, this is obvious; were it not so, the algorithm would
be unreversible (impossible to decrypt). BTW, there are four keys which
which when applied twice reproduce the plaintext. That is,
des_encrypt(des_encrypt(plaintext)) = plaintext. Two of them are all
zeros and all ones. I don't know what the other two are.

Of course, even with successful cracking in the above case, they wouldn't
match the data in the shadow file.

	(Root Boy) Jim Cottrell	(301) 975-5688
	<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
	Crackers and Worms -- Breakfast of Champions!

-----------[000539][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 11:16:03 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        mkl@sri-nic.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: The TCP-IP List

> It takes the mailer about 3 hours to mail out one message to the whole
> list.  This means it can't handle more than about 8 messages a day
> without getting backlogged.  Please don't clutter things up with one
> line responses, flames, or other useless personal comments.

Mark:

    While I generally agree with the gist of your posting, the notion that
the TCP-IP community is limited to 8 messages (substantive or not) of
discussion per day is highly disturbing.  How can we increase the NIC's
delivery capacity?

Craig
-----------[000540][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 11:19:46 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        kwe@bu-it.bu.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Dynamic IP address assignment

> In article <Nov.20.13.30.19.1988.26043@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes:
> >Wouldn't you run into a problem with ARP caches if you dynamically
> >assign internet addresses to ethernet based machines?
> 
> 	Age the arp cache.  Then set a "re-use" timer on the IP
> address to be, say 3x, the arp cache time-out.
> 	Of course, how do you know when an IP address is released?
> There oughta be a protocol.

A protocol won't help with the release of IP addresses -- what happens if
the machine goes down, or its owner disconnects his portable PC and walks
away, before the machine gets a chance to release its address?  I think
any system one develops for reclaiming addresses has to assume the system
might silently go away.

Note that this is one reason why I feel that there is a difference between
transient assignment (IP addresses dynamically assigned for short term use,
and thus addresses that must be reclaimed) and one-time configuration
assignment (unpack the box and have it learn its IP address once and for
all -- you may want to reclaim addresses once every few years, but that
can probably be done by hand).

Craig
-----------[000541][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 08:47:11 EST
From:      Steve Howie <SCOTTY%UOGUELPH.BITNET@CORNELLC.ccs.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: comp.security - LET'S DO IT!  CALL FOR VOTES
Please do it! let's get this list back to it's intended topic i.e.
TCP/IP

Scotty
-----------[000542][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 09:06:03 EST
From:      Steve Howie <SCOTTY%UOGUELPH.BITNET@CORNELLC.ccs.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   re: TCP-IP Information
This is outrageous! I checked the price of the book up here in Canada.

     $324.00   Cdn.            !!!!!

With all due respect to IBM, what is the point of offering a textbook
normally cost $35-40 for this completely exorbitant price? It was a noble
gesture to offer it to aid sites which are not too 'up to speed' on
Internet/TCP concepts, but why bother if no one will buy it?

Scotty
-----------[000543][next][prev][last][first]----------------------------------------------------
Date:      TUE, 22 NOV 88 19:47:58 JST
From:      Shingo Ichii <ICHII%JPNKEKVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: A supdup client for X Windows?
>
>I have seen various public-domain supdups written at MIT, but none
>that runs under X.  Any suggestions as to where to look?
>

How can I get and use supdups (original version, not on X, of course)?
Please show me the pointer to it.  Thank you.

Shingo Ichii
Data Handling Center
National Laboratory for High Energy Physics (KEK)
Tsukuba 305 Japan
-----------[000544][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 09:03:20 EDT
From:      Daniel Trujillo <DANIEL%TECMTYVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
unsubscribe
-----------[000545][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 10:15:37 EST
From:      Steve Howie <SCOTTY%UOGUELPH.BITNET@CORNELLC.ccs.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Performance
We got approx 160 Kbytes/sec using FTP under VM in loopback i.e.
FTP'ing from a CMS userid to the FTP server. This is effectively
a very fast file copy. Mind you, this doesn't go out through our
8232 Ethernet controller :-)

Scotty
-----------[000546][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Nov 88 13:40:51 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        ykluger@hawk.ulowell.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Brouters

My understanding is that a brouter is a box which:

    (1) acts as a router for those protocol suites it understands

	and

    (2) bridges those protocol suites it doesn't understand

It figures out which protocol suites it understands by looking at the
link level protocol identifier.

The idea is to get around the problem of choosing between routers (which
are relatively good firewalls but only handle the protocol suites they
understand) and bridges (which are lousy firewalls but handle all protocol
suites).

Craig
-----------[000547][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 11:05:00 EDT
From:      "AMSP6::CHRISTEVT" <christevt%amsp6.decnet@wpafb-ams1.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Virus article, ETHICS article
                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      23-Nov-1988 10:58 
                                        From:      Victor ET Christensen 
                                                   CHRISTEVT 
                                        Dept:      
                                        Tel No:    

TO:  _MAILER!                             ( _DDN[VIRUS-L@LEHIIBM.BITNET] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )
TO:  _MAILER!                             ( _DDN[ETHICS-L%MARIST.BITNET@CUNYVM.CUNY.EDU] )


Subject: Virus article, "ethics" article



      The 21 November 1988 issue of "Government Computer News" (GCN) has two 
articles that might be of interest to y'all:

      "BIG GUNS TAKE AIM AT VIRUS," by Neil Munro, starting on page one and 
      continuing on page 100; subject matter should be pretty obvious.

      "WHY SOFTWARE DEFECTS SO OFTEN GO UNDISCOVERED," by William E Perry, on 
      page 85; mentions some reasons why bugs/holes like those exploited by 
      the current worm don't get fixed...sounds like a bit of ethics to me.

      So as not to violate any copyright laws, I have not included either 
article in part/full...if there's enough interest to have them posted here, 
I'll contact GCN and ask them for permission to do so; reply to my account, 
not the mailing list, if you'd like to see them here.


                                   ET B ME
                                     VIC
                                      !


------
-----------[000548][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 07:43:56 GMT
From:      mec@ardent.com (Michael Chastain)
To:        comp.protocols.tcp-ip
Subject:   Breaking up the monoculture

Here are my assumptions:

(1) Attacks against a known binary server (e.g. Vendor X, Release Y) are
easier to accomplish than general attacks "through the interface".

(2) Some machines on the Internet were unaffected by the recent virus
because they had recompiled /etc/fingerd; e.g., with nameserver
support.  Sorry, I can't find references.

How about a "salt" utility that transforms an executable to another
executable, while adding extra bytes here and there to make all the
data addresses come out different?

This is even easier to do at link time.  Suppose that you have the
capability to relink your operating system (e.g., to add device
drivers).  Do so, and stick in some padding here and there.

Now imagine that Internet Worm II shows up on your system and tries to
read kernel data space to get juicy network data (e.g. /dev/kmem on
Unix).  Your physical memory doesn't look like everybody else's!  So if
the worm is carrying around kernel data addresses, it doesn't get to do
what it wants on your system.

I think this idea can be taken further.  For instance, if you have
source, you could protect private data structures by randomizing the
order of their structure members.  This wouldn't fool a smart hacker,
but it might fool a dumb worm.  This would protect against "read the
clist and discover what people are typing" attacks.

An unrelated, controversial statement: protecting your user's files is
now the second most important thing.  The first most important thing is
protecting your network connections.

Michael Chastain
Ardent Computer
mec@ardent.com
"He who dies with the most FRIENDS wins."

-----------[000549][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 09:59:03 GMT
From:      jfc@athena.mit.edu (John F Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: An Obvious Security Problem?

In article <8811162311.AA09389@vax.ftp.com> stev@VAX.FTP.COM writes:

>yep. even on a single ethernet someone could use a lan monitor to catch
>your passwords as they fly over the net. i believe the Athena people
>use Kerberos (sorry about butchering the spelling) to deal with some
>of this. (or at least they could . . . . .)

Kerberos does provide for encrypted connections (the Kerberos server 
generates a random session key for use by the client-service pair
[this key is encrypted using the user and/or service key when it is
sent over the net]).  To the best of my knowledge, there is only
one program that uses it (an encrypted version of rlogin).  Kerberos
authenticated login cuts down on the need to type passwords over the 
net.  As long as the remote host accepts authenticated rlogin AND you 
do not need a set of tickets on that host, your initial tickets are 
sufficient.  There are some cases when Kerberos is insufficient (the 
issue of ticket forwarding [getting tickets valid on a remote host 
without entering a password] is not yet solved; the security tradeoffs 
are a problem).

>i would think that we would
>want to use diffrent "well known ports" for the new secure versions.

That is what is done with Kerberos.

--
   John Carr             "When they turn the pages of history,
   jfc@Athena.mit.edu     When these days have passed long ago,
   bloom-beacon!          Will they read of us with sadness
   athena.mit.edu!jfc     For the seeds that we let grow?"  --Neil Peart

-----------[000550][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 11:21:18 GMT
From:      van@HELIOS.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   re: Performance

> Recently, I improved "ftp" in one of our products which is 4.2BSD based.
> I had 351465 bytes received in 1 second ( 3.4 e + 02 Kbytes/sec )
> ...
> Is there anybody has better "ftp" performance than mine ???

It would be interesting to see what performance you would get
with a good tcp.  I think Dave Borman of Cray Research holds the
current ftp speed record:  He routinely gets 30 Megabytes/sec
(of course, some of us think using two Cray-IIs gives him an
unfair competitive advantage).  If you're using more
conventional hardware, 340 KB/s still isn't spectacular.  Here's
a typescript between two of our Sun 3/60s across an ethernet.
Both machines are running stock 4.3bsd-tahoe ftp & ftpd with
Mike Karels' and my tcp & kernel hacks:

    Script started on Wed Nov 23 02:40:44 1988
    [vs 1]% ftp yak
    Connected to yak.ee.lbl.gov.
    220 yak FTP server (Version 4.27 Sat Nov 5 02:20:42 PST 1988) ready.
    Name (yak:van): 
    331 Password required for van.
    Password:
    230 User van logged in.
    ftp> bin
    200 Type set to I.
    ftp> get /usr/lib/libcore.a /dev/null
    200 PORT command okay.
    150 Opening data connection for /usr/lib/libcore.a (669336 bytes).
    226 Transfer complete.
    669336 bytes received in 0.82 seconds (8e+02 Kbytes/s)
    ftp> get /usr/lib/libcore.a /dev/null
    200 PORT command okay.
    150 Opening data connection for /usr/lib/libcore.a (669336 bytes).
    226 Transfer complete.
    669336 bytes received in 0.82 seconds (8e+02 Kbytes/s)
    ftp> bye
    221 Goodbye.
    [vs 2]% exit
    script done on Wed Nov 23 02:41:23 1988

-----------[000551][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 13:37:35 GMT
From:      jam@RADC-LONEX.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  Performance

>From: aeras!bud!kwang@sun.com  (Kwang Sung)
>
>Recently, I improved "ftp" in one of our products which is 4.2BSD based.
>When I typed ftp> bin
>             ftp> get /syst /dev/null, 
>I had:
>             351465 bytes received in 1 second ( 3.4 e + 02 Kbytes/sec )
>
>I didn't use Van Jacobson's Algorithm.
>
>Is there anybody has better "ftp" performance than mine ???

	Huh?  Your going to have to provide a little more than this
	if you want people to sit up and take notice!

	First of all, what did you do (in general terms if not specifics)
	to "improve" the ftp on your 4.2 based system?  Ftp is not all
	that complicated when it transfers a file.  I find it hard to
	see much room for tremendous speed increase at the application level.

	Secondly, what kind of networking are you using?  ethernet?  other?

	Third, were you staying on your net, or going to an internet host?

	In order to compare anything (be it ftp or ?) you have to have
	a compatible situation.  For instance, if I ftp to Europe, it
	ain't never gonna keep up with calling the guy next door.

	Please elaborate if you desire to continue this.

Joel A. Mussman
Contel Federal Systems
(this company has no opinion on ftp)

-----------[000552][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 13:47:03 GMT
From:      ykluger@HAWK.ULOWELL.EDU (Yoav Kluger)
To:        comp.protocols.tcp-ip
Subject:   Brouters

Hi,
I have been hearing lately too much the term BROUTER.
Is there a formal or even an informal but well agreed upon definition
for this creature?
  - Is it a bridge and a router in one box?
  - Is it a back-bone bridge?
  - Is it a bridge that does some LLC-header replacement (depending
    on the interface the packet is coming from and going to)?
  - Is it none of the above?

There was a bird-of-a-feather session about brouters in the conference,
which wasn't much helpful at all, and I haven't been able to find
this term in any of the literature I know of.

Could you help in this?

Thanks,

Yoav.

-----------[000553][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 13:47:11 GMT
From:      SCOTTY@UOGUELPH.BITNET (Steve Howie)
To:        comp.protocols.tcp-ip
Subject:   Re: comp.security - LET'S DO IT!  CALL FOR VOTES

Please do it! let's get this list back to it's intended topic i.e.
TCP/IP

Scotty

-----------[000554][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 14:06:03 GMT
From:      SCOTTY@UOGUELPH.BITNET (Steve Howie)
To:        comp.protocols.tcp-ip
Subject:   re: TCP-IP Information

This is outrageous! I checked the price of the book up here in Canada.

     $324.00   Cdn.            !!!!!

With all due respect to IBM, what is the point of offering a textbook
normally cost $35-40 for this completely exorbitant price? It was a noble
gesture to offer it to aid sites which are not too 'up to speed' on
Internet/TCP concepts, but why bother if no one will buy it?

Scotty

-----------[000555][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 15:05:00 GMT
From:      christevt%amsp6.decnet@WPAFB-AMS1.ARPA ("AMSP6::CHRISTEVT")
To:        comp.protocols.tcp-ip
Subject:   Virus article, ETHICS article


                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      23-Nov-1988 10:58 
                                        From:      Victor ET Christensen 
                                                   CHRISTEVT 
                                        Dept:      
                                        Tel No:    

TO:  _MAILER!                             ( _DDN[VIRUS-L@LEHIIBM.BITNET] )
TO:  _MAILER!                             ( _DDN[TCP-IP@SRI-NIC.ARPA] )
TO:  _MAILER!                             ( _DDN[ETHICS-L%MARIST.BITNET@CUNYVM.CUNY.EDU] )


Subject: Virus article, "ethics" article



      The 21 November 1988 issue of "Government Computer News" (GCN) has two 
articles that might be of interest to y'all:

      "BIG GUNS TAKE AIM AT VIRUS," by Neil Munro, starting on page one and 
      continuing on page 100; subject matter should be pretty obvious.

      "WHY SOFTWARE DEFECTS SO OFTEN GO UNDISCOVERED," by William E Perry, on 
      page 85; mentions some reasons why bugs/holes like those exploited by 
      the current worm don't get fixed...sounds like a bit of ethics to me.

      So as not to violate any copyright laws, I have not included either 
article in part/full...if there's enough interest to have them posted here, 
I'll contact GCN and ask them for permission to do so; reply to my account, 
not the mailing list, if you'd like to see them here.


                                   ET B ME
                                     VIC
                                      !


------

-----------[000556][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 88 15:06:27 GMT
From:      tpc@bnr-fos.UUCP (Tom Chmara)
To:        comp.protocols.tcp-ip
Subject:   Needed:  timeouts for connections to dead/dying hosts

We've been examining the 4.3BSD tcp-ip code from Berkeley, and I'm a bit
confused.  From what I can se