The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Happy birthday Morris worm
@ 2019-11-12 20:56 Norman Wilson
  2019-11-12 22:00 ` Dave Horsfall
                   ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: Norman Wilson @ 2019-11-12 20:56 UTC (permalink / raw)
  To: tuhs

I think I recall an explicit statement somewhere from an
interview with Robert that the worm was inspired partly
by Shockwave Rider.

I confess my immediate reaction to the worm was uncontrollable
laughter.  I was out of town when it happened, so I first
heard it from a newspaper article (and wasn't caught up in
fighting it or I'd have laughed a lot less, of course); and
it seemed to me hilarious when I read that Robert was behind
it.  He had interned with 1127 for a few summers while I was
there, so I knew him as very bright but often a bit careless
about details; that seemed an exact match for the worm.

My longer-term reaction was to completely drop my sloppy
old habit (common in those days not just in my code but in
that of many others) of ignoring possible buffer overflows.
I find it mind-boggling that people still make that mistake;
it has been literal decades since the lesson was rubbed in
our community's collective noses.  I am very disappointed
that programming education seems not to care enough about
this sort of thing, even today.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-12 20:56 [TUHS] Happy birthday Morris worm Norman Wilson
@ 2019-11-12 22:00 ` Dave Horsfall
  2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
  2019-11-13  7:35 ` [TUHS] " arnold
  2 siblings, 0 replies; 44+ messages in thread
From: Dave Horsfall @ 2019-11-12 22:00 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, 12 Nov 2019, Norman Wilson wrote:

> I think I recall an explicit statement somewhere from an interview with 
> Robert that the worm was inspired partly by Shockwave Rider.

Yes, I noticed the similarity too.

> I confess my immediate reaction to the worm was uncontrollable laughter. 
> I was out of town when it happened, so I first heard it from a newspaper 
> article (and wasn't caught up in fighting it or I'd have laughed a lot 
> less, of course); and it seemed to me hilarious when I read that Robert 
> was behind it.  He had interned with 1127 for a few summers while I was 
> there, so I knew him as very bright but often a bit careless about 
> details; that seemed an exact match for the worm.

That was the trouble; had he bothered to test it on a private network (as 
if a true professional would even consider carrying out such an act)[*] he 
would've noticed that his probability calculations were arse-backwards, 
and so spread much faster than it "should" have.

> My longer-term reaction was to completely drop my sloppy old habit 
> (common in those days not just in my code but in that of many others) of 
> ignoring possible buffer overflows. I find it mind-boggling that people 
> still make that mistake; it has been literal decades since the lesson 
> was rubbed in our community's collective noses.  I am very disappointed 
> that programming education seems not to care enough about this sort of 
> thing, even today.

Yep.  Don't use fixed-length buffers unless you *know* that it will
not overflow (i.e. the data is under your control), and don't trust
user input (especially if the reader is an interpreter with the
possibility of spawning a shell); there are of course others.

This is what you get when people call themselves programmers because
they once took a course in programming or read a book; that's like
calling oneself a doctor because you took a first-aid course...

One of my favourite examples is "Barbie the Computer Engineer" (grep the 
net for it, but warning: the title contains a naughty word).

Oh, OK; here's a sanitised URL:

    http://www.gizmodo.com.au/2014/11/barbie-fks-it-up-again/

Yes, that really is the URL; I've just tested it (but contents may offend
some viewers; you have been warned).

[*]
And for those who slagged me off for calling him an idiot, try this quick 
quiz: on a scale from utter moron to sheer genius, what do you call 
someone who deliberately releases untested software designed to compromise 
machines that are not under his administrative control in order to make 
some sort of a point?  I don't know about other countries, but try that in 
Australia and you'd be seriously out of pocket and/or doing porridge.

-- Dave (BSc, majoring in Computer Science and Mathematics)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* [TUHS] buffer overflow (Re:  Happy birthday Morris worm
  2019-11-12 20:56 [TUHS] Happy birthday Morris worm Norman Wilson
  2019-11-12 22:00 ` Dave Horsfall
@ 2019-11-12 22:10 ` Bakul Shah
  2019-11-12 22:14   ` Larry McVoy
  2019-11-12 22:54   ` Dave Horsfall
  2019-11-13  7:35 ` [TUHS] " arnold
  2 siblings, 2 replies; 44+ messages in thread
From: Bakul Shah @ 2019-11-12 22:10 UTC (permalink / raw)
  To: tuhs

On Tue, 12 Nov 2019 15:56:15 -0500 Norman Wilson <norman@oclsc.org> wrote:
>
> My longer-term reaction was to completely drop my sloppy
> old habit (common in those days not just in my code but in
> that of many others) of ignoring possible buffer overflows.
> I find it mind-boggling that people still make that mistake;
> it has been literal decades since the lesson was rubbed in
> our community's collective noses.  I am very disappointed
> that programming education seems not to care enough about
> this sort of thing, even today.

Unfortunately strcpy & other buffer overflow friendly
functions are still present in the C standard (I am looking at
n2434.pdf, draft of Sept 25, 2019). Is C really not fixable?

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
  2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
@ 2019-11-12 22:14   ` Larry McVoy
  2019-11-12 22:41     ` Robert Clausecker
  2019-11-12 22:54   ` Dave Horsfall
  1 sibling, 1 reply; 44+ messages in thread
From: Larry McVoy @ 2019-11-12 22:14 UTC (permalink / raw)
  To: Bakul Shah; +Cc: tuhs

On Tue, Nov 12, 2019 at 02:10:46PM -0800, Bakul Shah wrote:
> On Tue, 12 Nov 2019 15:56:15 -0500 Norman Wilson <norman@oclsc.org> wrote:
> >
> > My longer-term reaction was to completely drop my sloppy
> > old habit (common in those days not just in my code but in
> > that of many others) of ignoring possible buffer overflows.
> > I find it mind-boggling that people still make that mistake;
> > it has been literal decades since the lesson was rubbed in
> > our community's collective noses.  I am very disappointed
> > that programming education seems not to care enough about
> > this sort of thing, even today.
> 
> Unfortunately strcpy & other buffer overflow friendly
> functions are still present in the C standard (I am looking at
> n2434.pdf, draft of Sept 25, 2019). Is C really not fixable?

Someone needs to do Strcpy() etc that have the length in the 
first bytes[s] of the string.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
  2019-11-12 22:14   ` Larry McVoy
@ 2019-11-12 22:41     ` Robert Clausecker
  2019-11-12 22:49       ` Arthur Krewat
                         ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: Robert Clausecker @ 2019-11-12 22:41 UTC (permalink / raw)
  To: tuhs

Oh please no.  One of the things we've hopefully all learned from Pascal
is that length-prefixed strings suck because you can't perform anything
useful without copying the entire string.  Rob Pike and friends showed
how to get strings and vectors right in the Go language where you have a
builtin slice type which is essentially a structure

    struct slice(type) {
            type *data;
            size_t len, cap;
    };

where data points to a buffer, len is the length of meaningful data in
that buffer and cap is the total buffer size.  This allows the language
to take subslices and to append to existing slices without requiring
copies in most cases.  If a copy is necessary, the runtime can allocate
a slightly larger buffer in advance to allow for appending in amortised
linear time.

Overall, much more versatile than Pascal strings.

But let's get back to the topic, after all I promised not to flame as
much as Jörg did.

Yours,
Robert Clausecker

On Tue, Nov 12, 2019 at 02:14:18PM -0800, Larry McVoy wrote:
> On Tue, Nov 12, 2019 at 02:10:46PM -0800, Bakul Shah wrote:
> > On Tue, 12 Nov 2019 15:56:15 -0500 Norman Wilson <norman@oclsc.org> wrote:
> > >
> > > My longer-term reaction was to completely drop my sloppy
> > > old habit (common in those days not just in my code but in
> > > that of many others) of ignoring possible buffer overflows.
> > > I find it mind-boggling that people still make that mistake;
> > > it has been literal decades since the lesson was rubbed in
> > > our community's collective noses.  I am very disappointed
> > > that programming education seems not to care enough about
> > > this sort of thing, even today.
> > 
> > Unfortunately strcpy & other buffer overflow friendly
> > functions are still present in the C standard (I am looking at
> > n2434.pdf, draft of Sept 25, 2019). Is C really not fixable?
> 
> Someone needs to do Strcpy() etc that have the length in the 
> first bytes[s] of the string.
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-12 22:41     ` Robert Clausecker
@ 2019-11-12 22:49       ` Arthur Krewat
  2019-11-12 23:45       ` Jon Steinhart
  2019-11-13  0:24       ` Larry McVoy
  2 siblings, 0 replies; 44+ messages in thread
From: Arthur Krewat @ 2019-11-12 22:49 UTC (permalink / raw)
  To: tuhs



On 11/12/2019 5:41 PM, Robert Clausecker wrote:
> Oh please no.  One of the things we've hopefully all learned from Pascal
> is that length-prefixed strings suck because you can't perform anything
> useful without copying the entire string.  Rob Pike and friends showed
> how to get strings and vectors right in the Go language where you have a
> builtin slice type which is essentially a structure
>
>      struct slice(type) {
>              type *data;
>              size_t len, cap;
>      };

And none of that stops some programmer from doing slice.cap=255 - or is 
it read-only? ;)



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
  2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
  2019-11-12 22:14   ` Larry McVoy
@ 2019-11-12 22:54   ` Dave Horsfall
  2019-11-12 23:22     ` Warner Losh
       [not found]     ` <alpine.DEB.2.20.1911191443530.10845@grey.csi.cam.ac.uk>
  1 sibling, 2 replies; 44+ messages in thread
From: Dave Horsfall @ 2019-11-12 22:54 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, 12 Nov 2019, Bakul Shah wrote:

> Unfortunately strcpy & other buffer overflow friendly functions are 
> still present in the C standard (I am looking at n2434.pdf, draft of 
> Sept 25, 2019). Is C really not fixable?

No; POSIX requires all sorts of broken functions be present, otherwise it 
is not compliant; heck, last I looked it even requires gets().  And let's 
not even mention pointers...  We are our own worst enemy.[*]

All is not lost, though; use strncpy() instead of strcpy() etc.  These 
days my first choice is Perl, despite it being bloated (I only use C if 
it's trivial or I need the speed).  I must look at Ruby, though...

[*]
Of if you were a Pogo fan, "We have met the enemy, and he is us".

-- Dave

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-12 22:54   ` Dave Horsfall
@ 2019-11-12 23:22     ` Warner Losh
  2019-11-12 23:27       ` Arthur Krewat
       [not found]     ` <alpine.DEB.2.20.1911191443530.10845@grey.csi.cam.ac.uk>
  1 sibling, 1 reply; 44+ messages in thread
From: Warner Losh @ 2019-11-12 23:22 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Tue, Nov 12, 2019 at 3:54 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Tue, 12 Nov 2019, Bakul Shah wrote:
>
> > Unfortunately strcpy & other buffer overflow friendly functions are
> > still present in the C standard (I am looking at n2434.pdf, draft of
> > Sept 25, 2019). Is C really not fixable?
>
> No; POSIX requires all sorts of broken functions be present, otherwise it
> is not compliant; heck, last I looked it even requires gets().  And let's
> not even mention pointers...  We are our own worst enemy.[*]
>

POSIX can't even recognize that leap seconds exist :(


> All is not lost, though; use strncpy() instead of strcpy() etc.  These
> days my first choice is Perl, despite it being bloated (I only use C if
> it's trivial or I need the speed).  I must look at Ruby, though...
>

strncpy has two issues. First, it doesn't guarantee NUL termination.
Second, it always writes N bytes. It's for a fixed width data field, not a
variable length string whose buffer size is known. strlcpy is much better,
but still has some issues...

Warner

[-- Attachment #2: Type: text/html, Size: 1654 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-12 23:22     ` Warner Losh
@ 2019-11-12 23:27       ` Arthur Krewat
  0 siblings, 0 replies; 44+ messages in thread
From: Arthur Krewat @ 2019-11-12 23:27 UTC (permalink / raw)
  To: tuhs


On 11/12/2019 6:22 PM, Warner Losh wrote:
> strncpy has two issues. First, it doesn't guarantee NUL termination. 
> Second, it always writes N bytes. It's for a fixed width data field, 
> not a variable length string whose buffer size is known. strlcpy is 
> much better, but still has some issues...
Maybe he meant strcpy_s()

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-12 22:41     ` Robert Clausecker
  2019-11-12 22:49       ` Arthur Krewat
@ 2019-11-12 23:45       ` Jon Steinhart
  2019-11-13  0:38         ` Warren Toomey
  2019-11-13  1:09         ` Arthur Krewat
  2019-11-13  0:24       ` Larry McVoy
  2 siblings, 2 replies; 44+ messages in thread
From: Jon Steinhart @ 2019-11-12 23:45 UTC (permalink / raw)
  To: tuhs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3612 bytes --]

Robert Clausecker writes:
> Oh please no.  One of the things we've hopefully all learned from Pascal
> is that length-prefixed strings suck because you can't perform anything
> useful without copying the entire string.  Rob Pike and friends showed
> how to get strings and vectors right in the Go language where you have a
> builtin slice type which is essentially a structure
>
>     struct slice(type) {
>             type *data;
>             size_t len, cap;
>     };
>
> where data points to a buffer, len is the length of meaningful data in
> that buffer and cap is the total buffer size.  This allows the language
> to take subslices and to append to existing slices without requiring
> copies in most cases.  If a copy is necessary, the runtime can allocate
> a slightly larger buffer in advance to allow for appending in amortised
> linear time.
>
> Overall, much more versatile than Pascal strings.
>
> But let's get back to the topic, after all I promised not to flame as
> much as Jörg did.
>
> Yours,
> Robert Clausecker
>
> On Tue, Nov 12, 2019 at 02:14:18PM -0800, Larry McVoy wrote:
> > On Tue, Nov 12, 2019 at 02:10:46PM -0800, Bakul Shah wrote:
> > > On Tue, 12 Nov 2019 15:56:15 -0500 Norman Wilson <norman@oclsc.org> wrote:
> > > >
> > > > My longer-term reaction was to completely drop my sloppy
> > > > old habit (common in those days not just in my code but in
> > > > that of many others) of ignoring possible buffer overflows.
> > > > I find it mind-boggling that people still make that mistake;
> > > > it has been literal decades since the lesson was rubbed in
> > > > our community's collective noses.  I am very disappointed
> > > > that programming education seems not to care enough about
> > > > this sort of thing, even today.
> > > 
> > > Unfortunately strcpy & other buffer overflow friendly
> > > functions are still present in the C standard (I am looking at
> > > n2434.pdf, draft of Sept 25, 2019). Is C really not fixable?
> > 
> > Someone needs to do Strcpy() etc that have the length in the 
> > first bytes[s] of the string.
> > -- 
> > ---
> > Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

OK, been biting my tongue here.  I, for one, appreciate the fact that
it's still legal to purchase and use power tools.  I like being able
to use my chainsaw to cut up a tree without having to measure it first.
And I don't have a variety of tree here that contains its length at the
base.  Sure, things can go wrong; I have a scar on one leg to prove it.
But that just shows that I need to be more careful, not that I need to
try logging with a safety razor.

C strings were great at the time, and are still great, especially in
very small systems.  Go may be nicer in larger systems but I probably
wouldn't want the overhead in a small embedded system.  The length at
the start of a string has its issues too; do you want to consume 8
bytes at the start of each string on a 64-bit machine, or have strings
that can support different lengths and have to deal with converting
between them?

Programming isn't a good place for careless people.  I recognize that
what passes for "software technology" these days is coming up with
mechanisms that minimize the damage that can be done by unskilled
people.  But it's never gonna work.  Sure, you can replace pointer
problems with reference problems and so on, but that doesn't really
solve anything.

So let's not rehash our favorite arguments about strings until Warren
shuts down the discussion.  Use that energy to get out there and teach
people to be better and more careful programmers.

Jon

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
  2019-11-12 22:41     ` Robert Clausecker
  2019-11-12 22:49       ` Arthur Krewat
  2019-11-12 23:45       ` Jon Steinhart
@ 2019-11-13  0:24       ` Larry McVoy
  2 siblings, 0 replies; 44+ messages in thread
From: Larry McVoy @ 2019-11-13  0:24 UTC (permalink / raw)
  To: Robert Clausecker; +Cc: tuhs

On Tue, Nov 12, 2019 at 11:41:51PM +0100, Robert Clausecker wrote:
> Oh please no.  One of the things we've hopefully all learned from Pascal
> is that length-prefixed strings suck because you can't perform anything
> useful without copying the entire string.  Rob Pike and friends showed
> how to get strings and vectors right in the Go language where you have a
> builtin slice type which is essentially a structure
> 
>     struct slice(type) {
>             type *data;
>             size_t len, cap;
>     };
> 
> where data points to a buffer, len is the length of meaningful data in
> that buffer and cap is the total buffer size.  

We did something similar in BitKeeper but we added a spicy little twist.
We encoded len and cap in one word by making cap increase in powers of
2 only (which means you need log(n) bits for cap).  So it was a data
structure that scaled both up and down.

We used it everywhere in BitKeeper, it was super handy.

http://repos.bkbits.net/bk/dev/src/libc/utils/lines.c?PAGE=anno&REV=56cf7e34BTkDFx47E54DPNG51B2uCA

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-12 23:45       ` Jon Steinhart
@ 2019-11-13  0:38         ` Warren Toomey
  2019-11-13  1:09         ` Arthur Krewat
  1 sibling, 0 replies; 44+ messages in thread
From: Warren Toomey @ 2019-11-13  0:38 UTC (permalink / raw)
  To: tuhs

On Tue, Nov 12, 2019 at 03:45:23PM -0800, Jon Steinhart wrote:
> So let's not rehash our favorite arguments about strings until Warren
> shuts down the discussion.  Use that energy to get out there and teach
> people to be better and more careful programmers.

I agree on both points, and it's a good time to ask for discussion on
strings and worms to be moved over to the COFF list!

Thanks, Warren

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-12 23:45       ` Jon Steinhart
  2019-11-13  0:38         ` Warren Toomey
@ 2019-11-13  1:09         ` Arthur Krewat
  1 sibling, 0 replies; 44+ messages in thread
From: Arthur Krewat @ 2019-11-13  1:09 UTC (permalink / raw)
  To: tuhs

On 11/12/2019 6:45 PM, Jon Steinhart wrote:
> Use that energy to get out there and teach
> people to be better and more careful programmers.

If I was religious, you'd get an "Amen, brother!".

But since I'm not, a simple "exactly" will suffice ;)

ak

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-12 20:56 [TUHS] Happy birthday Morris worm Norman Wilson
  2019-11-12 22:00 ` Dave Horsfall
  2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
@ 2019-11-13  7:35 ` arnold
  2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
  2 siblings, 1 reply; 44+ messages in thread
From: arnold @ 2019-11-13  7:35 UTC (permalink / raw)
  To: tuhs, norman

Norman Wilson <norman@oclsc.org> wrote:

> I am very disappointed that programming education seems not to care
> enough about this sort of thing, even today.

I think this is the key. Universities focus (too much?) on the theory
and not enough on the practice, and "learn how to program" courses
and books focus on the mechanics (syntax, semantics) and not enough
(or at all) on the practicum of writing code well.

We continue to rely on the school of hard knocks, and we continue
to pay for this reliance.

I also think there's a sliding scale. The fancier or higher-end
the university, the more the focus on theory, and vice versa. Sigh.

Arnold


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm [ really programming education ]
  2019-11-13  7:35 ` [TUHS] " arnold
@ 2019-11-13 18:02   ` Jon Steinhart
  2019-11-13 18:49     ` Tyler Adams
                       ` (3 more replies)
  0 siblings, 4 replies; 44+ messages in thread
From: Jon Steinhart @ 2019-11-13 18:02 UTC (permalink / raw)
  To: tuhs

arnold@skeeve.com writes:
> Norman Wilson <norman@oclsc.org> wrote:
>
> > I am very disappointed that programming education seems not to care
> > enough about this sort of thing, even today.
>
> I think this is the key. Universities focus (too much?) on the theory
> and not enough on the practice, and "learn how to program" courses
> and books focus on the mechanics (syntax, semantics) and not enough
> (or at all) on the practicum of writing code well.
>
> We continue to rely on the school of hard knocks, and we continue
> to pay for this reliance.
>
> I also think there's a sliding scale. The fancier or higher-end
> the university, the more the focus on theory, and vice versa. Sigh.
>
> Arnold

OK, this is a bit of a tangential topic for this list.  But, what's the
point of obsessing on UNIX history unless it's coupled with some effort
to communicate the philosophy to a new generation of programmers?

This has been a real concern of mine for a while.  As a friend of mine
put it, processors are getting so cheap that pretty soon we won't be
able to purchase pencils that don't contain them.  This puts us all
at the mercy of not-great programmers.  And of course, it's not just
pencils, it's stuff like airplanes too.

In my opinion, the root of the problem is that programming today is
being taught in the abstract - as if programs don't run on computers.
Programming today is taught as if it consists of importing libraries
and gluing function calls together.

I recently visited my daughter's college and attended a number of CS
related presentations.  Was surprised that CS is taught in Java with
some advanced work in Python.  One can almost get a CS degree there
without ever using a compiler much less learning how computers function.
Too be fair, other schools such as Dartmouth where Doug hangs out have
a better curriculum.

At the K-12 level, the stage is set by combination of the "everybody
must learn to code" curriculum with "no child left behind".  School
administrators dispense with any critical thinking about the value of
the curriculum in order to chase grant dollars.

I used to be able to get into my local schools to volunteer-teach
programming.  But, the learn to code curriculum has eclipsed that;
schools are led to believe that they're teaching the right stuff
(because Bill Gates says so) and aren't interested in anything else.

I recently turned my course notes into a book as an attempt to make
some small difference.  Too soon to tell if it will.

Anyway, my question for you all is, how do we as seasoned practitioners
leverage our experience to contribute to the state of the art?  Any of
you found a way to pass on your knowledge?

BTW, I'm doing my first messing around with the Linux kernel these days;
if anyone knows the guts of the generic filesystem code I could use a bit
of help.  Here's something that I came across on the way in <sys/mount.h>:

enum
{
  MS_RDONLY = 1,		/* Mount read-only.  */
#define MS_RDONLY	MS_RDONLY
  MS_NOSUID = 2,		/* Ignore suid and sgid bits.  */
#define MS_NOSUID	MS_NOSUID
  MS_NODEV = 4,			/* Disallow access to device special files.  */
#define MS_NODEV	MS_NODEV
...
};

Can anyone explain the value of this programming style?  Is this just an
example of the result of how programming is taught today?

Be happy discuss this off-list.

Jon

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm [ really programming education ]
  2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
@ 2019-11-13 18:49     ` Tyler Adams
  2019-11-13 19:15     ` [TUHS] #defines and enums ron
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 44+ messages in thread
From: Tyler Adams @ 2019-11-13 18:49 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 5109 bytes --]

>
> OK, this is a bit of a tangential topic for this list.  But, what's the
> point of obsessing on UNIX history unless it's coupled with some effort
> to communicate the philosophy to a new generation of programmers?
>
100 times this.


A few hypotheses for why colleges teaching "theoretical programming"
(i.e. Computer Science).

- Universities, especially at the undergraduate level, have a mission
to teach students how to think, not how to do. This leads to more theory
and less practice.

- Universities are top down institutions with lecturers. Theory is easier
to teach in a top down institution than practical advice.

- Software engineering is evolving so quickly, it would be hard to put
together a software engineering program which had economic value.
CMU has a MS in Software Engineering, but their cirriculum is vague so it's
hard to tell what they do.
If anybody here has taken it I'd love to hear what you thought of it.

- A lot of good work needs to be done that doesn't require breaking
the JVM, python, or JS abstraction layer. Cycles are cheap.
Memory is cheap.  And not all programs have latency or uptime requirements.
UNIX culture of course was lightyears ahead of knowing this and
economized for the most expensive resource of all: developer time.

To bring this back to TUHS, how did (and do) UNIX developers teach
the UNIX way? As someone younger than Linux, I was only lucky enough to
read The Art Of Unix Programming by ESR and read Kernighan's books.

 Tyler


On Wed, Nov 13, 2019 at 8:03 PM Jon Steinhart <jon@fourwinds.com> wrote:

> arnold@skeeve.com writes:
> > Norman Wilson <norman@oclsc.org> wrote:
> >
> > > I am very disappointed that programming education seems not to care
> > > enough about this sort of thing, even today.
> >
> > I think this is the key. Universities focus (too much?) on the theory
> > and not enough on the practice, and "learn how to program" courses
> > and books focus on the mechanics (syntax, semantics) and not enough
> > (or at all) on the practicum of writing code well.
> >
> > We continue to rely on the school of hard knocks, and we continue
> > to pay for this reliance.
> >
> > I also think there's a sliding scale. The fancier or higher-end
> > the university, the more the focus on theory, and vice versa. Sigh.
> >
> > Arnold
>
> OK, this is a bit of a tangential topic for this list.  But, what's the
> point of obsessing on UNIX history unless it's coupled with some effort
> to communicate the philosophy to a new generation of programmers?
>
> This has been a real concern of mine for a while.  As a friend of mine
> put it, processors are getting so cheap that pretty soon we won't be
> able to purchase pencils that don't contain them.  This puts us all
> at the mercy of not-great programmers.  And of course, it's not just
> pencils, it's stuff like airplanes too.
>
> In my opinion, the root of the problem is that programming today is
> being taught in the abstract - as if programs don't run on computers.
> Programming today is taught as if it consists of importing libraries
> and gluing function calls together.
>
> I recently visited my daughter's college and attended a number of CS
> related presentations.  Was surprised that CS is taught in Java with
> some advanced work in Python.  One can almost get a CS degree there
> without ever using a compiler much less learning how computers function.
> Too be fair, other schools such as Dartmouth where Doug hangs out have
> a better curriculum.
>
> At the K-12 level, the stage is set by combination of the "everybody
> must learn to code" curriculum with "no child left behind".  School
> administrators dispense with any critical thinking about the value of
> the curriculum in order to chase grant dollars.
>
> I used to be able to get into my local schools to volunteer-teach
> programming.  But, the learn to code curriculum has eclipsed that;
> schools are led to believe that they're teaching the right stuff
> (because Bill Gates says so) and aren't interested in anything else.
>
> I recently turned my course notes into a book as an attempt to make
> some small difference.  Too soon to tell if it will.
>
> Anyway, my question for you all is, how do we as seasoned practitioners
> leverage our experience to contribute to the state of the art?  Any of
> you found a way to pass on your knowledge?
>
> BTW, I'm doing my first messing around with the Linux kernel these days;
> if anyone knows the guts of the generic filesystem code I could use a bit
> of help.  Here's something that I came across on the way in <sys/mount.h>:
>
> enum
> {
>   MS_RDONLY = 1,                /* Mount read-only.  */
> #define MS_RDONLY       MS_RDONLY
>   MS_NOSUID = 2,                /* Ignore suid and sgid bits.  */
> #define MS_NOSUID       MS_NOSUID
>   MS_NODEV = 4,                 /* Disallow access to device special
> files.  */
> #define MS_NODEV        MS_NODEV
> ...
> };
>
> Can anyone explain the value of this programming style?  Is this just an
> example of the result of how programming is taught today?
>
> Be happy discuss this off-list.
>
> Jon
>

[-- Attachment #2: Type: text/html, Size: 6190 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* [TUHS] #defines and enums
  2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
  2019-11-13 18:49     ` Tyler Adams
@ 2019-11-13 19:15     ` ron
  2019-11-13 21:11       ` Warner Losh
  2019-11-13 21:22     ` [TUHS] Happy birthday Morris worm [ really programming education ] Chet Ramey
  2019-11-15 22:49     ` Adam Thornton
  3 siblings, 1 reply; 44+ messages in thread
From: ron @ 2019-11-13 19:15 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: tuhs


>
> BTW, I'm doing my first messing around with the Linux kernel these days;
> if anyone knows the guts of the generic filesystem code I could use a bit
> of help.  Here's something that I came across on the way in <sys/mount.h>:
>
> enum
> {
>   MS_RDONLY = 1,		/* Mount read-only.  */
> #define MS_RDONLY	MS_RDONLY
>   MS_NOSUID = 2,		/* Ignore suid and sgid bits.  */
> #define MS_NOSUID	MS_NOSUID
>   MS_NODEV = 4,			/* Disallow access to device special files.  */
> #define MS_NODEV	MS_NODEV
> ...
> };
>
> Can anyone explain the value of this programming style?  Is this just an
> example of the result of how programming is taught today?
>
>

This really is more a C question than a UNIX one.    The problem is that
the preprocessor macros are really kind of a kludge.   Making things
either enums (or in later C/C++ const int definitions) is a lot cleaner.  
 The #define is just probably backwards a compatibility kludge (for people
using things like MS_RDONLY or whatever in other macros).



^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] #defines and enums
  2019-11-13 19:15     ` [TUHS] #defines and enums ron
@ 2019-11-13 21:11       ` Warner Losh
  0 siblings, 0 replies; 44+ messages in thread
From: Warner Losh @ 2019-11-13 21:11 UTC (permalink / raw)
  To: Ronald Natalie; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Wed, Nov 13, 2019, 12:15 PM <ron@ronnatalie.com> wrote:

>
> >
> > BTW, I'm doing my first messing around with the Linux kernel these days;
> > if anyone knows the guts of the generic filesystem code I could use a bit
> > of help.  Here's something that I came across on the way in
> <sys/mount.h>:
> >
> > enum
> > {
> >   MS_RDONLY = 1,              /* Mount read-only.  */
> > #define MS_RDONLY     MS_RDONLY
> >   MS_NOSUID = 2,              /* Ignore suid and sgid bits.  */
> > #define MS_NOSUID     MS_NOSUID
> >   MS_NODEV = 4,                       /* Disallow access to device
> special files.  */
> > #define MS_NODEV      MS_NODEV
> > ...
> > };
> >
> > Can anyone explain the value of this programming style?  Is this just an
> > example of the result of how programming is taught today?
> >
> >
>
> This really is more a C question than a UNIX one.    The problem is that
> the preprocessor macros are really kind of a kludge.   Making things
> either enums (or in later C/C++ const int definitions) is a lot cleaner.
>  The #define is just probably backwards a compatibility kludge (for people
> using things like MS_RDONLY or whatever in other macros).
>

It lets the users of these interfaces conditionally use them as ifdef. A
pure enum interface doesn't let you do that. This makes it harder to write
portable code that is driven directly by what is defined.

While it seems purer to use enum, it is problematic. C++ doesn't let you
use it for bit fields due to special rules around enums that aren't there
to get in the way in C.

Conditional code is important, as are providing enough compat scaffolding
when sharing code between many systems, or when different compilers are
used. Macro processing accomplishes this rather well, though not without
other issues. In an ideal world, you could put other constructs into the
language to accomplish these goals... But none that have been good enough
to gain any traction at all....

Warner

>

[-- Attachment #2: Type: text/html, Size: 2805 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm [ really programming education ]
  2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
  2019-11-13 18:49     ` Tyler Adams
  2019-11-13 19:15     ` [TUHS] #defines and enums ron
@ 2019-11-13 21:22     ` Chet Ramey
  2019-11-15 22:49     ` Adam Thornton
  3 siblings, 0 replies; 44+ messages in thread
From: Chet Ramey @ 2019-11-13 21:22 UTC (permalink / raw)
  To: Jon Steinhart, tuhs

On 11/13/19 1:02 PM, Jon Steinhart wrote:

> At the K-12 level, the stage is set by combination of the "everybody
> must learn to code" curriculum with "no child left behind".  School
> administrators dispense with any critical thinking about the value of
> the curriculum in order to chase grant dollars.

In my experience as a school board member, it's not grant dollars so much
as the amount of control the state exerts over the curriculum. The state
dictates the material and content that is taught. For AP classes, like
AP computer science, the College Board creates the courses and decides
what material is included. And in most cases, especially AP classes and
core classes where there are end-of-course proficiency requirements, the
material on those standardized tests dictates how the course is taught.

This is off-topic at this point.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm [ really programming education ]
  2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
                       ` (2 preceding siblings ...)
  2019-11-13 21:22     ` [TUHS] Happy birthday Morris worm [ really programming education ] Chet Ramey
@ 2019-11-15 22:49     ` Adam Thornton
  2019-11-15 23:59       ` Theodore Y. Ts'o
  3 siblings, 1 reply; 44+ messages in thread
From: Adam Thornton @ 2019-11-15 22:49 UTC (permalink / raw)
  To: Jon Steinhart, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Wed, Nov 13, 2019 at 1:03 PM Jon Steinhart <jon@fourwinds.com> wrote:

> arnold@skeeve.com writes:
> Programming today is taught as if it consists of importing libraries
> and gluing function calls together.
>

To be fair, this is basically what modern software development in
enterprise settings is.  Thing is, you don’t need a CS degree for that;
it’s a completely artificial barrier to entry.  You need an
apprenticeship.  That’s even kind of acknowledged, in that by your third
job, no one cares where or if you went to school or what for.

Anyway, my question for you all is, how do we as seasoned practitioners
> leverage our experience to contribute to the state of the art?  Any of
> you found a way to pass on your knowledge?
>

Find someone who’s interested and talk to them?  I mean, that’s kinda what
this list is, right?

The other part: it’s historically been a crap shoot whether the CS
department at any given place came out of EE, in which case it was the
bottom-up here’s a transistor, and here’s a flip-flop, and, look, logic
gates!  Adders!  Et cetera, or it came out of the math department and is a
theory-heavy specialization of some very particular parts of discrete
mathematics and combinatorics.

[-- Attachment #2: Type: text/html, Size: 1972 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm [ really programming education ]
  2019-11-15 22:49     ` Adam Thornton
@ 2019-11-15 23:59       ` Theodore Y. Ts'o
  0 siblings, 0 replies; 44+ messages in thread
From: Theodore Y. Ts'o @ 2019-11-15 23:59 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

On Fri, Nov 15, 2019 at 05:49:29PM -0500, Adam Thornton wrote:
> 
> The other part: it’s historically been a crap shoot whether the CS
> department at any given place came out of EE, in which case it was the
> bottom-up here’s a transistor, and here’s a flip-flop, and, look, logic
> gates!  Adders!  Et cetera, or it came out of the math department and is a
> theory-heavy specialization of some very particular parts of discrete
> mathematics and combinatorics.

And neither of these necessarily means that a person with CS
undergraduate degree will necessarily have a strong OS / Systems
background.  I remember running out of undergraduate CS classes at
MIT, so I started taking the graduate level classes --- and was
astounded when a first year graduate student raised their hand and
asked, "What's Virtual Memory"?  Turns out she came from a highly
math-centric program, and it was simply never covered --- which is why
the first level intro CS class, even at the graduate level, couldn't
make any assumptions about what admitted graduate students might have
as their background.

On the flip side, I remember talking to someone who had their CS
undergraduate program from the UK, and he was astounded that we didn't
cover type functions and type theory as part of MIT's undergraduate CS
program.  (It's covered in a graduate level class, and most undergrads
wouldn't have taken it.)

So the fundamental issue is there is no real consensus about what must
be in a CS undergraduate degree program.  It used to be one of my
favorite interview questions required that as part of answer, to
implement the moral equivalent of itoa().  What floored me was how
many interviewees with a 4 year CS degree program under their belt
foundered on what was supposed to be the warmup, "just checking to
make sure you know how to program" part of the problem.

     	      	       	  	   - Ted

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
       [not found]     ` <alpine.DEB.2.20.1911191443530.10845@grey.csi.cam.ac.uk>
@ 2019-11-21 20:02       ` Dave Horsfall
  2019-11-21 20:38         ` Warner Losh
  2019-11-21 21:48         ` Steffen Nurpmeso
  0 siblings, 2 replies; 44+ messages in thread
From: Dave Horsfall @ 2019-11-21 20:02 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, 19 Nov 2019, Tony Finch wrote:

> Amusingly POSIX says the C standard takes precedence wrt the details of 
> gets() (and other library functions) and C18 abolished gets(). I'm 
> slightly surprised that the POSIX committee didn't see that coming and 
> include the change in the 2018 edition...

Didn't know that gets() had finally been abolished; it's possibly the most 
unsafe function (OK, macro) on the planet.  I've long been tempted to 
remove gets() and see what breaks...

-- Dave

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-21 20:02       ` Dave Horsfall
@ 2019-11-21 20:38         ` Warner Losh
  2019-11-21 21:04           ` Clem Cole
  2019-11-21 22:06           ` Dave Horsfall
  2019-11-21 21:48         ` Steffen Nurpmeso
  1 sibling, 2 replies; 44+ messages in thread
From: Warner Losh @ 2019-11-21 20:38 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Thu, Nov 21, 2019 at 1:02 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Tue, 19 Nov 2019, Tony Finch wrote:
>
> > Amusingly POSIX says the C standard takes precedence wrt the details of
> > gets() (and other library functions) and C18 abolished gets(). I'm
> > slightly surprised that the POSIX committee didn't see that coming and
> > include the change in the 2018 edition...
>
> Didn't know that gets() had finally been abolished; it's possibly the most
> unsafe function (OK, macro) on the planet.  I've long been tempted to
> remove gets() and see what breaks...
>

A few things actually broke when FreeBSD removed it. Apart from 'wrappers'
that needed it for various reasons, it was only a few programs in our
'ports' package that needed to be corrected.

Most people have moved on with the 20 years of warnings when it was used...
Sadly only most...

Warner

[-- Attachment #2: Type: text/html, Size: 1333 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-21 20:38         ` Warner Losh
@ 2019-11-21 21:04           ` Clem Cole
  2019-11-21 22:06           ` Dave Horsfall
  1 sibling, 0 replies; 44+ messages in thread
From: Clem Cole @ 2019-11-21 21:04 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

On Thu, Nov 21, 2019 at 3:39 PM Warner Losh <imp@bsdimp.com> wrote:

> A few things actually broke when FreeBSD removed it. Apart from 'wrappers'
> that needed it for various reasons, it was only a few programs in our
> 'ports' package that needed to be corrected.
>
> Most people have moved on with the 20 years of warnings when it was
> used... Sadly only most...
>
> Warner
>
That is encouraging to hear.

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
  2019-11-21 20:02       ` Dave Horsfall
  2019-11-21 20:38         ` Warner Losh
@ 2019-11-21 21:48         ` Steffen Nurpmeso
  1 sibling, 0 replies; 44+ messages in thread
From: Steffen Nurpmeso @ 2019-11-21 21:48 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

Dave Horsfall wrote in <alpine.BSF.2.21.9999.1911220658250.33542@aneurin\
.horsfall.org>:
 |On Tue, 19 Nov 2019, Tony Finch wrote:
 |> Amusingly POSIX says the C standard takes precedence wrt the details of 
 |> gets() (and other library functions) and C18 abolished gets(). I'm 
 |> slightly surprised that the POSIX committee didn't see that coming and 
 |> include the change in the 2018 edition...

This week (on the 19th, to be exact) Geoff Clare made official the
desire to align a forthcoming POSIX Issue 8 with ISO C17.
Current POSIX (1003.1(2016)/Issue7+TC2) still aligns with C99.

And, compared to C99, the POSIX wording causes sympathy

d37021   APPLICATION USAGE
37022         Reading a line that overflows the array pointed to by s results in undefined behavior. The use of
37023         fgets( ) is recommended.
37024               Since the user cannot specify the length of the buffer passed to gets( ), use of this function is
37025               discouraged. The length of the string read is unlimited. It is possible to overflow this buffer in
37026               such a way as to cause applications to fail, or possible system security violations.
37027               Applications should use the fgets( ) function instead of the obsolescent gets( ) function.
37028   RATIONALE
37029         The standard developers decided to mark the gets( ) function as obsolescent even though it is in
37030         the ISO C standard due to the possibility of buffer overflow.
37031   FUTURE DIRECTIONS
37032         The gets( ) function may be removed in a future version.

 |Didn't know that gets() had finally been abolished; it's possibly the most 
 |unsafe function (OK, macro) on the planet.  I've long been tempted to 
 |remove gets() and see what breaks...

It seems to have been removed in C 2011, except get_s(), which is
still present in the C 2017 draft that i have.  (I have never used
any of the _s() functions.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm
  2019-11-21 20:38         ` Warner Losh
  2019-11-21 21:04           ` Clem Cole
@ 2019-11-21 22:06           ` Dave Horsfall
  1 sibling, 0 replies; 44+ messages in thread
From: Dave Horsfall @ 2019-11-21 22:06 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Thu, 21 Nov 2019, Warner Losh wrote:

> A few things actually broke when FreeBSD removed it. Apart from 
> 'wrappers' that needed it for various reasons, it was only a few 
> programs in our 'ports' package that needed to be corrected.

FreeBSD prints a stern warning (both at compilation and execution) if you 
use it; I quickly fixed all my programs when I saw them :-)

> Most people have moved on with the 20 years of warnings when it was 
> used... Sadly only most...

Yep :-(

-- Dave

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday, Morris worm
  2019-11-15 14:31 [TUHS] Happy birthday, Morris worm Doug McIlroy
@ 2019-11-15 14:39 ` Warner Losh
  0 siblings, 0 replies; 44+ messages in thread
From: Warner Losh @ 2019-11-15 14:39 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Fri, Nov 15, 2019, 7:32 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > That was the trouble; had he bothered to test it on a private network (as
> > if a true professional would even consider carrying out such an act)[*]
> he
> > would've noticed that his probability calculations were arse-backwards
>
> Morris's failure to foresee the results of even slow exponential
> growth is matched by the failure of the critique above to realize
> that Morris wouldn't have seen the trouble in a small network test.
>
> The worm assured that no more than one copy (and occasionally one clone)
> would run on a machine at a time. This limits the number of attacks
> that any one machine experiences at a time to roughly the
> number of machines in the network. For a small network, this will
> not be a major load.
>
>
> The worm became a denial-of-service attack only because a huge
> number of machines were involved.
>
> I do not remember whether the worm left tracks to prevent its
> being run more than once on a machine, though I rather think
> it did. This would mean that a small network test would not
> only behave innocuously; it would terminate almost instantly.
>

it had code to do that, but IIRC, there were bugs in that code that
prevented it being completely effective in some cases... the sorts of
cases, though, that a small scale test wouldn't likely catch.

Warner

[-- Attachment #2: Type: text/html, Size: 1847 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday, Morris worm
@ 2019-11-15 14:31 Doug McIlroy
  2019-11-15 14:39 ` Warner Losh
  0 siblings, 1 reply; 44+ messages in thread
From: Doug McIlroy @ 2019-11-15 14:31 UTC (permalink / raw)
  To: tuhs

> That was the trouble; had he bothered to test it on a private network (as
> if a true professional would even consider carrying out such an act)[*] he
> would've noticed that his probability calculations were arse-backwards

Morris's failure to foresee the results of even slow exponential
growth is matched by the failure of the critique above to realize
that Morris wouldn't have seen the trouble in a small network test.

The worm assured that no more than one copy (and occasionally one clone)
would run on a machine at a time. This limits the number of attacks
that any one machine experiences at a time to roughly the
number of machines in the network. For a small network, this will
not be a major load.


The worm became a denial-of-service attack only because a huge
number of machines were involved.

I do not remember whether the worm left tracks to prevent its
being run more than once on a machine, though I rather think
it did. This would mean that a small network test would not
only behave innocuously; it would terminate almost instantly.

Doug

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
@ 2019-11-13 13:47 Doug McIlroy
  0 siblings, 0 replies; 44+ messages in thread
From: Doug McIlroy @ 2019-11-13 13:47 UTC (permalink / raw)
  To: tuhs

Most of this post is off topic; the conclusion is not.

On the afternoon of Martin Luther King Day, 1990, AT&T's
backbone network slowed to a crawl. The cause: a patch intended
to save time when a switch that had taken itself off line (a
rare, but routine and almost imperceptible event) rejoined the
network. The patch was flawed; a lock should have been taken
one instruction sooner.

Bell Labs had tested the daylights out of the patch by
subjecting a real switch in the lab to tortuously heavy, but
necessarily artificial loads. It may also have been tested on
a switch in the wild before the patch was deployed throughout
the network, but that would not have helped.

The trouble was that a certain sequence of events happening
within milliseconds on calls both ways between two heavily
loaded switches could evoke a ping-pong of the switches leaving
and rejoining the network.

The phenomenon was contagious because of the enhanced odds of a
third switch experiencing the bad sequence with a switch that
was repeatedly taking itself off line. The basic problem (and
a fortiori the contagion) had not been seen in the lab because
the lab had only one of the multimillion-dollar switches to
play with.

The meltdown was embarrassing, to say the least. Yet nobody
ever accused AT&T of idiocy for not first testing on a private
network this feature that was inadvertently "designed to
compromise" switches.

Doug

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
@ 2019-11-12 22:24 Norman Wilson
  0 siblings, 0 replies; 44+ messages in thread
From: Norman Wilson @ 2019-11-12 22:24 UTC (permalink / raw)
  To: tuhs

Dave Horsfall:

  And for those who slagged me off for calling him an idiot, try this quick 
  quiz: on a scale from utter moron to sheer genius, what do you call 
  someone who deliberately releases untested software designed to compromise 
  machines that are not under his administrative control in order to make 
  some sort of a point?

=====

I'd call that careless and irresponsible.  Calling it stupid or
idiotic is, well, a stupid, idiotic simplification that succeeds
in being nasty without showing any understanding of the real problem.

Carelessness and irresponsibility are characteristic of people
in their late teens and early 20s, i.e. Robert's age at the time.
Many of us are overly impressed with our own brilliance at that
age, and even when we take some care (as I think Robert did) we
don't always take enough (as he certainly didn't).

Anyone who claims not to have been at least a bit irresponsible
and careless when young is, in my opinion, not being honest.  Some
of my former colleagues at Bell Labs weren't always as careful and
responsible as they should be, even to the point of causing harm
to others.  But to their credit, when they screwed up that way they
owned up to having done so, tried to make amends, and tried to do
better in future, just as Robert did.  It was just Robert's bad
luck that he screwed up in such a public way and did harm to so
many people.

I save my scorn for those who are long past that age and still
behave irresponsibly and harmfully, like certain high politicians
and certain high-tech executives.

Probably future discussion of this should move to COFF unless it
relates directly to the culture and doings in 1127 or other historic
UNIX places.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-06 10:37           ` arnold
@ 2019-11-06 13:35             ` Ronald Natalie
  0 siblings, 0 replies; 44+ messages in thread
From: Ronald Natalie @ 2019-11-06 13:35 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

The WIZ hack was well known by the time the worm exploited it.    I’d recompiled sendmail to get rid of it even being an option on all the machines directly under my control.    The 750 in question was operated ostensibly by the JVNCNet people, but I had the root pasword (I guess I really didn’t need it with that security hole in it anyhow).

> On Nov 6, 2019, at 5:37 AM, arnold@skeeve.com wrote:
> 
> Ronald Natalie <ron@ronnatalie.com> wrote:
> 
>> We got hit at Rutgers on some of our ancillary machines early in the day ...
> 
> Our Unix systems (Emory U. Computer Center and Math/CS systems) were running
> a custom sendmail config that I wrote, so the worm bypassed us. We were lucky. :-)
> 
> Arnold


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-05 16:04         ` Ronald Natalie
@ 2019-11-06 10:37           ` arnold
  2019-11-06 13:35             ` Ronald Natalie
  0 siblings, 1 reply; 44+ messages in thread
From: arnold @ 2019-11-06 10:37 UTC (permalink / raw)
  To: stewart, ron; +Cc: tuhs

Ronald Natalie <ron@ronnatalie.com> wrote:

> We got hit at Rutgers on some of our ancillary machines early in the day ...

Our Unix systems (Emory U. Computer Center and Math/CS systems) were running
a custom sendmail config that I wrote, so the worm bypassed us. We were lucky. :-)

Arnold

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-05  3:48       ` Lawrence Stewart
@ 2019-11-05 16:04         ` Ronald Natalie
  2019-11-06 10:37           ` arnold
  0 siblings, 1 reply; 44+ messages in thread
From: Ronald Natalie @ 2019-11-05 16:04 UTC (permalink / raw)
  To: Lawrence Stewart; +Cc: TUHS main list

We got hit at Rutgers on some of our ancillary machines early in the day (the 750 that belonged really to the the JVN computing center mostly) and I collected the evidence and learned through the internet grapevine where the vulnerabilities were and plugged them (also wrote some scripts to look for the holes and evidence of the worm on other machines at RU).    Got everything cleaned up by noon time or so and I figured that was the end.   The next day I was scheduled to be in DC on other business so I felt confident on leaving.

Apparently however, the biggest impact on us of the worm had yet to hit.   The news caught wind of it that evening and started calling the computer center early the next morning.   I wasn’t there so it pretty much chewed up all of Chuck Hedrick’s day answering press inquiries.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 19:24     ` Richard Salz
@ 2019-11-05  3:48       ` Lawrence Stewart
  2019-11-05 16:04         ` Ronald Natalie
  0 siblings, 1 reply; 44+ messages in thread
From: Lawrence Stewart @ 2019-11-05  3:48 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

I might have been the fan who called John Shoch and Jon Hupp’s attention to John Brunner.  At some point, Brunner came to visit PARC and we had a nice discussion about how Brunner had been able to anticipate this aspect of networking.

-Larry

> On 2019, Nov 4, at 2:24 PM, Richard Salz <rich.salz@gmail.com> wrote:
> 
> The John F. Shoch and Jon Hupp paper extensively credits Brunner, and uses quotes from the book as section intro's.
> 
> On Mon, Nov 4, 2019 at 1:58 PM Bakul Shah <bakul@bitblocks.com <mailto:bakul@bitblocks.com>> wrote:
> I am surprised no one mentioned The Shockwave Rider by John Brunner, published in 1975. Excerpt:
> 
> 


[-- Attachment #2: Type: text/html, Size: 1605 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 18:57   ` Bakul Shah
                       ` (2 preceding siblings ...)
  2019-11-04 20:27     ` Dan Cross
@ 2019-11-05  0:25     ` Anthony Martin
  3 siblings, 0 replies; 44+ messages in thread
From: Anthony Martin @ 2019-11-05  0:25 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

Bakul Shah <bakul@bitblocks.com> once said:
> I have been meaning to re-read [...] Stand on Zanzibar
> but [it] would be too depressing in the present era!

I read it shortly before my first vicennial. Even though
I'm closer now to my second, I still think about it from
time to time.

"Christ, what an imagination I've got."

Cheers,
  Anthony

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 20:27     ` Dan Cross
@ 2019-11-04 22:10       ` Michael Kjörling
  0 siblings, 0 replies; 44+ messages in thread
From: Michael Kjörling @ 2019-11-04 22:10 UTC (permalink / raw)
  To: coff; +Cc: tuhs

On 4 Nov 2019 15:27 -0500, from crossd@gmail.com (Dan Cross):
> On Mon, Nov 4, 2019 at 1:58 PM Bakul Shah <bakul@bitblocks.com> wrote:
>> I am surprised no one mentioned *The Shockwave Rider *by John Brunner,
>> published in 1975. Excerpt:
> 
> In the 1983 movie "Wargames", at the very end as the staff at NORAD
> desperately try and disable the rogue artificial intelligence hell-bent on
> starting World War III, at one point they make a suggestion to send a
> "tapeworm" into the system", but it's judged too risky.

In the 1984 movie _2010_, it seems using a tapeworm was more of a
standard, if unusual, procedure for solving a very different problem.

Copying from <https://en.wikiquote.org/wiki/2010:_The_Year_We_Make_Contact#Dialogue>

> Dr. Chandra: I've erased all of HAL's memory from the moment the
> trouble started.
> 
> Dr. Vasili Orlov: The 9000 series uses holographic memories, so
> chronological erasures would not work.
> 
> Dr. Chandra: I made a tapeworm.
> 
> Dr. Walter Curnow: You made a what?
> 
> Dr. Chandra: It's a program that's fed into a system that will hunt
> down and destroy any desired memories.
> 
> Dr. Floyd: Wait... do you know why HAL did what he did?
> 
> Dr. Chandra: Yes. It wasn't his fault.

I also suggest to migrate this part of the discussion to COFF as it
has very little to do with UNIX history per se.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 18:57   ` Bakul Shah
  2019-11-04 19:24     ` Richard Salz
  2019-11-04 19:25     ` SPC
@ 2019-11-04 20:27     ` Dan Cross
  2019-11-04 22:10       ` Michael Kjörling
  2019-11-05  0:25     ` Anthony Martin
  3 siblings, 1 reply; 44+ messages in thread
From: Dan Cross @ 2019-11-04 20:27 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

On Mon, Nov 4, 2019 at 1:58 PM Bakul Shah <bakul@bitblocks.com> wrote:

> I am surprised no one mentioned *The Shockwave Rider *by John Brunner,
> published in 1975. Excerpt:
>
> Then the answer dawned on him, and he almost laughed. Fluckner had
> resorted to one of the oldest tricks in the store and turned loose in the
> continental net a selfperpetuating tapeworm, probably headed by a
> denunciation group "borrowed" from a major corporation, which would shunt
> itself from one nexus to another every time his credit-code was punched
> into a keyboard. It could take days to kill a worm like that, and sometimes
> weeks.
>
>
In the 1983 movie "Wargames", at the very end as the staff at NORAD
desperately try and disable the rogue artificial intelligence hell-bent on
starting World War III, at one point they make a suggestion to send a
"tapeworm" into the system", but it's judged too risky. They ultimately
defeat the computer by getting it to play tic-tac-toe against itself and
learn that nuclear war is unwinnable.

        - Dan C.


I read it in late 70s/early 80s and don't remember much of it but this bit
> had burrowed its way in my subconscious. I have been meaning to re-read it
> along with Stand on Zanzibar but they would be too depressing in the
> present era!
>
> On Nov 4, 2019, at 10:10 AM, Paul McJones <paul@mcjones.org> wrote:
>
> Another possible source of inspiration — including the name “worm” — were
> the publications by John Shoch and Jon Hupp on programs they wrote at Xerox
> PARC around 1979-1980 and published in 1980 and 1982:
>
> John F. Shoch and Jon Hupp:
>  The “Worm" Programs — Early Experience with a Distributed Computation.
> Xerox SSL-80-3 and IEN 159. May 1980, revised September 1980
> http://www.postel.org/ien/pdf/ien159.pdf
>
> John F. Shoch and Jon Hupp:
>  The “Worm" Programs — Early Experience with a Distributed Computation.
> CACM V25 N3 (March 1982)
> http://www.eecs.harvard.edu/~margo/cs261/background/shoch.pdf
>
> On Nov 3, 2019, Paul Winalski <paul.winalski@gmail.com> wrote:
>
>
> On 11/2/19, Warner Losh <imp@bsdimp.com> wrote:
>
>
> the notion of a self propagating thing
> was quite novel (even if it had been theoretically discussed in many places
> prior to the worm, and even though others had proven it via slower moving
> vectors of BBS).
>
>
> Novel to the Internet community, perhaps, but an idea that dates back
> to the 1960s in IBM mainframe circles.  Self-submitting OS/360 JCL
> jobs, which eventually caused a crash by filling the queue files with
> jobs, were well-known in the raised-floor world.
>
> In hindsight people like to point at it and what a terrible thing it was,
> but Robert just got there first.
>
>
> Again, first on the Internet.  Back in 1980 I accidentally took down
> DEC's internal engineering network (about 100 nodes, mostly VAX/VMS,
> at the time) with a worm.  ...
>
> Robert Morris worked as an intern one summer in DEC's compiler group.
> The Fortran project leader told Morris about my 1980 worm incident.
> So he certainly had heard of the concept before he fashioned his
> UNIX/Internet-based worm a few years later.
>
> -Paul W.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 13782 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 18:57   ` Bakul Shah
  2019-11-04 19:24     ` Richard Salz
@ 2019-11-04 19:25     ` SPC
  2019-11-04 20:27     ` Dan Cross
  2019-11-05  0:25     ` Anthony Martin
  3 siblings, 0 replies; 44+ messages in thread
From: SPC @ 2019-11-04 19:25 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

El lun., 4 nov. 2019 19:58, Bakul Shah <bakul@bitblocks.com> escribió:

> I am surprised no one mentioned *The Shockwave Rider *by John Brunner,
> published in 1975.
>

What a *great* novel, as the previous of Brunner in the 60s. "Stand on
Zanzibar" and Salmanesser are guilty of my computing career. Visionary in
many ways.  You've made my day :-)

Excerpt:
>
> Then the answer dawned on him, and he almost laughed. Fluckner had
> resorted to one of the oldest tricks in the store and turned loose in the
> continental net a selfperpetuating tapeworm, probably headed by a
> denunciation group "borrowed" from a major corporation, which would shunt
> itself from one nexus to another every time his credit-code was punched
> into a keyboard. It could take days to kill a worm like that, and sometimes
> weeks.
>
>
> I read it in late 70s/early 80s and don't remember much of it but this bit
> had burrowed its way in my subconscious. I have been meaning to re-read it
> along with Stand on Zanzibar but they would be too depressing in the
> present era!
>
> On Nov 4, 2019, at 10:10 AM, Paul McJones <paul@mcjones.org> wrote:
>
> Another possible source of inspiration — including the name “worm” — were
> the publications by John Shoch and Jon Hupp on programs they wrote at Xerox
> PARC around 1979-1980 and published in 1980 and 1982:
>
> John F. Shoch and Jon Hupp:
>  The “Worm" Programs — Early Experience with a Distributed Computation.
> Xerox SSL-80-3 and IEN 159. May 1980, revised September 1980
> http://www.postel.org/ien/pdf/ien159.pdf
>
> John F. Shoch and Jon Hupp:
>  The “Worm" Programs — Early Experience with a Distributed Computation.
> CACM V25 N3 (March 1982)
> http://www.eecs.harvard.edu/~margo/cs261/background/shoch.pdf
>
> On Nov 3, 2019, Paul Winalski <paul.winalski@gmail.com> wrote:
>
>
> On 11/2/19, Warner Losh <imp@bsdimp.com> wrote:
>
>
> the notion of a self propagating thing
> was quite novel (even if it had been theoretically discussed in many places
> prior to the worm, and even though others had proven it via slower moving
> vectors of BBS).
>
>
> Novel to the Internet community, perhaps, but an idea that dates back
> to the 1960s in IBM mainframe circles.  Self-submitting OS/360 JCL
> jobs, which eventually caused a crash by filling the queue files with
> jobs, were well-known in the raised-floor world.
>
> In hindsight people like to point at it and what a terrible thing it was,
> but Robert just got there first.
>
>
> Again, first on the Internet.  Back in 1980 I accidentally took down
> DEC's internal engineering network (about 100 nodes, mostly VAX/VMS,
> at the time) with a worm.  ...
>
> Robert Morris worked as an intern one summer in DEC's compiler group.
> The Fortran project leader told Morris about my 1980 worm incident.
> So he certainly had heard of the concept before he fashioned his
> UNIX/Internet-based worm a few years later.
>
> -Paul W.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 13814 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 18:57   ` Bakul Shah
@ 2019-11-04 19:24     ` Richard Salz
  2019-11-05  3:48       ` Lawrence Stewart
  2019-11-04 19:25     ` SPC
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 44+ messages in thread
From: Richard Salz @ 2019-11-04 19:24 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

The John F. Shoch and Jon Hupp paper extensively credits Brunner, and uses
quotes from the book as section intro's.

On Mon, Nov 4, 2019 at 1:58 PM Bakul Shah <bakul@bitblocks.com> wrote:

> I am surprised no one mentioned *The Shockwave Rider *by John Brunner,
> published in 1975. Excerpt:
>
>
>

[-- Attachment #2: Type: text/html, Size: 683 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-04 18:10 ` Paul McJones
@ 2019-11-04 18:57   ` Bakul Shah
  2019-11-04 19:24     ` Richard Salz
                       ` (3 more replies)
  0 siblings, 4 replies; 44+ messages in thread
From: Bakul Shah @ 2019-11-04 18:57 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2894 bytes --]

I am surprised no one mentioned The Shockwave Rider by John Brunner, published in 1975. Excerpt:

Then the answer dawned on him, and he almost laughed. Fluckner had resorted to one of the oldest tricks in the store and turned loose in the continental net a selfperpetuating tapeworm, probably headed by a denunciation group "borrowed" from a major corporation, which would shunt itself from one nexus to another every time his credit-code was punched into a keyboard. It could take days to kill a worm like that, and sometimes weeks.

I read it in late 70s/early 80s and don't remember much of it but this bit had burrowed its way in my subconscious. I have been meaning to re-read it along with Stand on Zanzibar but they would be too depressing in the present era!

> On Nov 4, 2019, at 10:10 AM, Paul McJones <paul@mcjones.org> wrote:
> 
> Another possible source of inspiration — including the name “worm” — were the publications by John Shoch and Jon Hupp on programs they wrote at Xerox PARC around 1979-1980 and published in 1980 and 1982:
> 
> John F. Shoch and Jon Hupp:
>  The “Worm" Programs — Early Experience with a Distributed Computation.
> Xerox SSL-80-3 and IEN 159. May 1980, revised September 1980
> http://www.postel.org/ien/pdf/ien159.pdf <http://www.postel.org/ien/pdf/ien159.pdf>
> 
> John F. Shoch and Jon Hupp:
>  The “Worm" Programs — Early Experience with a Distributed Computation.
> CACM V25 N3 (March 1982)
> http://www.eecs.harvard.edu/~margo/cs261/background/shoch.pdf <http://www.eecs.harvard.edu/~margo/cs261/background/shoch.pdf>
> 
>> On Nov 3, 2019, Paul Winalski <paul.winalski@gmail.com <mailto:paul.winalski@gmail.com>> wrote:
>> 
>> On 11/2/19, Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>>> 
>>> the notion of a self propagating thing
>>> was quite novel (even if it had been theoretically discussed in many places
>>> prior to the worm, and even though others had proven it via slower moving
>>> vectors of BBS).
>> 
>> Novel to the Internet community, perhaps, but an idea that dates back
>> to the 1960s in IBM mainframe circles.  Self-submitting OS/360 JCL
>> jobs, which eventually caused a crash by filling the queue files with
>> jobs, were well-known in the raised-floor world.
>> 
>>> In hindsight people like to point at it and what a terrible thing it was,
>>> but Robert just got there first.
>> 
>> Again, first on the Internet.  Back in 1980 I accidentally took down
>> DEC's internal engineering network (about 100 nodes, mostly VAX/VMS,
>> at the time) with a worm.  ...
>> 
>> Robert Morris worked as an intern one summer in DEC's compiler group.
>> The Fortran project leader told Morris about my 1980 worm incident.
>> So he certainly had heard of the concept before he fashioned his
>> UNIX/Internet-based worm a few years later.
>> 
>> -Paul W.
> 


[-- Attachment #2: Type: text/html, Size: 16873 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
       [not found] <mailman.3.1572832803.30037.tuhs@minnie.tuhs.org>
@ 2019-11-04 18:10 ` Paul McJones
  2019-11-04 18:57   ` Bakul Shah
  0 siblings, 1 reply; 44+ messages in thread
From: Paul McJones @ 2019-11-04 18:10 UTC (permalink / raw)
  To: Paul Winalski; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

Another possible source of inspiration — including the name “worm” — were the publications by John Shoch and Jon Hupp on programs they wrote at Xerox PARC around 1979-1980 and published in 1980 and 1982:

John F. Shoch and Jon Hupp:
 The “Worm" Programs — Early Experience with a Distributed Computation.
Xerox SSL-80-3 and IEN 159. May 1980, revised September 1980
http://www.postel.org/ien/pdf/ien159.pdf

John F. Shoch and Jon Hupp:
 The “Worm" Programs — Early Experience with a Distributed Computation.
CACM V25 N3 (March 1982)
http://www.eecs.harvard.edu/~margo/cs261/background/shoch.pdf

> On Nov 3, 2019, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On 11/2/19, Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>> 
>> the notion of a self propagating thing
>> was quite novel (even if it had been theoretically discussed in many places
>> prior to the worm, and even though others had proven it via slower moving
>> vectors of BBS).
> 
> Novel to the Internet community, perhaps, but an idea that dates back
> to the 1960s in IBM mainframe circles.  Self-submitting OS/360 JCL
> jobs, which eventually caused a crash by filling the queue files with
> jobs, were well-known in the raised-floor world.
> 
>> In hindsight people like to point at it and what a terrible thing it was,
>> but Robert just got there first.
> 
> Again, first on the Internet.  Back in 1980 I accidentally took down
> DEC's internal engineering network (about 100 nodes, mostly VAX/VMS,
> at the time) with a worm.  ...
> 
> Robert Morris worked as an intern one summer in DEC's compiler group.
> The Fortran project leader told Morris about my 1980 worm incident.
> So he certainly had heard of the concept before he fashioned his
> UNIX/Internet-based worm a few years later.
> 
> -Paul W.


[-- Attachment #2: Type: text/html, Size: 15419 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-02 20:12 ` Warner Losh
@ 2019-11-03 17:12   ` Paul Winalski
  0 siblings, 0 replies; 44+ messages in thread
From: Paul Winalski @ 2019-11-03 17:12 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

On 11/2/19, Warner Losh <imp@bsdimp.com> wrote:
>
> the notion of a self propagating thing
> was quite novel (even if it had been theoretically discussed in many places
> prior to the worm, and even though others had proven it via slower moving
> vectors of BBS).

Novel to the Internet community, perhaps, but an idea that dates back
to the 1960s in IBM mainframe circles.  Self-submitting OS/360 JCL
jobs, which eventually caused a crash by filling the queue files with
jobs, were well-known in the raised-floor world.

> In hindsight people like to point at it and what a terrible thing it was,
> but Robert just got there first.

Again, first on the Internet.  Back in 1980 I accidentally took down
DEC's internal engineering network (about 100 nodes, mostly VAX/VMS,
at the time) with a worm.  The network used DECnet Phase 2, which
didn't have built-in packet routing.  If you wanted to talk to a
machine that wasn't physically connected to yours, you had to
explicitly specify the packet route.  Network topology maps were thus
very valuable.

All of the VAXen on the network were configured with an unprivileged
default DECnet account that was used for any connection that didn't
explicitly specify a username/password.  One could copy arbitrary DCL
command procedures (VMS's equivalent of shell scripts) to a machine
and execute them there.  I wrote a script to collect the raw
information for making a network topology map.  The script did this:

[1] Display the local DECnet connections and send this information
back over the network link.
[2] For each adjacent network node:
[2a]  Copy the script to that node.
[2b]  Execute the remote copy, sending its info back over the network link.

The problem, of course, is I had forgotten that network adjacency is
commutative.  I ran the script on node A, which told me that A is
connected to B and C.  It then told me that B was connected to A, D,
and E.  Then that A is connected to B and C....  I realized what had
happened immediately, but it was already too late.  The network had to
be taken down, the nodes cleared of the scripts, and then reconnected.
We learned the hard way that although the non-privileged default
DECnet accounts couldn't damage the system, they could be exploited
for what we now call DDoS attacks.

Robert Morris worked as an intern one summer in DEC's compiler group.
The Fortran project leader told Morris about my 1980 worm incident.
So he certainly had heard of the concept before he fashioned his
UNIX/Internet-based worm a few years later.

-Paul W.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
  2019-11-02 14:12 Doug McIlroy
@ 2019-11-02 20:12 ` Warner Losh
  2019-11-03 17:12   ` Paul Winalski
  0 siblings, 1 reply; 44+ messages in thread
From: Warner Losh @ 2019-11-02 20:12 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

On Sat, Nov 2, 2019 at 8:13 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> Full disclosure: I served as a character witness at Robert Morris's trial.
> Before the trial, the judge was quite incredulous that the prosecutor
> was pursuing a felony charge and refused to let the trial go forward
> without confirmation from the prosecutor's superiors in Washington.
>
> > I'm sure that Bob was proud of his son's accomplishments -- but not
> that one.
>
> As Bob ut it, "It {being the father] is not a great career move."
> Robert confessed to Bob as soon as he realized the folly of loosing
> an exponential, even with a tiny growth rate per generation. I
> believe that what brought computers to their knees was the
> overwhelming number of attacks, not the cost of cecryption. The
> worm did assure that only one copy would be allowed to proceed
> at a time.
>
> During high school, Robert worked as a summer employee for Fred
> Grampp. He got high marks for finding and correcting an exploit.
>
> > making use of known vulnerabilities
>
> Buffer overflows were known to cause misbehavior, but few people
> at the time were conscious that the misbehavior could be controlled.
> I do not know whether Berkeley agonized before distributing the
> "debug" feature that allowed remote super-user access via sendmail.
> But they certainly messed up by not documenting it.
>

Yes. The reason people freaked out when the worm came out was because it
was the first one to hit the scene. The exploints that allowed it to
propagate were known to a few, but the notion of a self propagating thing
was quite novel (even if it had been theoretically discussed in many places
prior to the worm, and even though others had proven it via slower moving
vectors of BBS). It caught a lot of people off guard with their pants down,
and it took a bunch of time to rectify (because it would reinfect if you
weren't careful). That's why people wanted to prosecute on felony charges.
But there was no intent to cause harm, and there was, at the time, no
applicable law that could be used to charge as a felony anyway (apart from
vague denial of property statues, which were at best a stretch).

In hindsight people like to point at it and what a terrible thing it was,
but Robert just got there first. Any number of people could have written it
given the extremely lax security profiles of the time (things are better
today, but we are not immune to buffer overflows or privilege escalation
attacks).

Warner

[-- Attachment #2: Type: text/html, Size: 3001 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] Happy birthday Morris worm
@ 2019-11-02 14:12 Doug McIlroy
  2019-11-02 20:12 ` Warner Losh
  0 siblings, 1 reply; 44+ messages in thread
From: Doug McIlroy @ 2019-11-02 14:12 UTC (permalink / raw)
  To: tuhs

Full disclosure: I served as a character witness at Robert Morris's trial.
Before the trial, the judge was quite incredulous that the prosecutor
was pursuing a felony charge and refused to let the trial go forward
without confirmation from the prosecutor's superiors in Washington.

> I'm sure that Bob was proud of his son's accomplishments -- but not
that one.

As Bob ut it, "It {being the father] is not a great career move."
Robert confessed to Bob as soon as he realized the folly of loosing
an exponential, even with a tiny growth rate per generation. I 
believe that what brought computers to their knees was the
overwhelming number of attacks, not the cost of cecryption. The
worm did assure that only one copy would be allowed to proceed
at a time.

During high school, Robert worked as a summer employee for Fred
Grampp. He got high marks for finding and correcting an exploit.

> making use of known vulnerabilities

Buffer overflows were known to cause misbehavior, but few people
at the time were conscious that the misbehavior could be controlled.
I do not know whether Berkeley agonized before distributing the
"debug" feature that allowed remote super-user access via sendmail.
But they certainly messed up by not documenting it.

Doug

^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2019-11-21 22:07 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-12 20:56 [TUHS] Happy birthday Morris worm Norman Wilson
2019-11-12 22:00 ` Dave Horsfall
2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
2019-11-12 22:14   ` Larry McVoy
2019-11-12 22:41     ` Robert Clausecker
2019-11-12 22:49       ` Arthur Krewat
2019-11-12 23:45       ` Jon Steinhart
2019-11-13  0:38         ` Warren Toomey
2019-11-13  1:09         ` Arthur Krewat
2019-11-13  0:24       ` Larry McVoy
2019-11-12 22:54   ` Dave Horsfall
2019-11-12 23:22     ` Warner Losh
2019-11-12 23:27       ` Arthur Krewat
     [not found]     ` <alpine.DEB.2.20.1911191443530.10845@grey.csi.cam.ac.uk>
2019-11-21 20:02       ` Dave Horsfall
2019-11-21 20:38         ` Warner Losh
2019-11-21 21:04           ` Clem Cole
2019-11-21 22:06           ` Dave Horsfall
2019-11-21 21:48         ` Steffen Nurpmeso
2019-11-13  7:35 ` [TUHS] " arnold
2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
2019-11-13 18:49     ` Tyler Adams
2019-11-13 19:15     ` [TUHS] #defines and enums ron
2019-11-13 21:11       ` Warner Losh
2019-11-13 21:22     ` [TUHS] Happy birthday Morris worm [ really programming education ] Chet Ramey
2019-11-15 22:49     ` Adam Thornton
2019-11-15 23:59       ` Theodore Y. Ts'o
  -- strict thread matches above, loose matches on Subject: below --
2019-11-15 14:31 [TUHS] Happy birthday, Morris worm Doug McIlroy
2019-11-15 14:39 ` Warner Losh
2019-11-13 13:47 [TUHS] Happy birthday " Doug McIlroy
2019-11-12 22:24 Norman Wilson
     [not found] <mailman.3.1572832803.30037.tuhs@minnie.tuhs.org>
2019-11-04 18:10 ` Paul McJones
2019-11-04 18:57   ` Bakul Shah
2019-11-04 19:24     ` Richard Salz
2019-11-05  3:48       ` Lawrence Stewart
2019-11-05 16:04         ` Ronald Natalie
2019-11-06 10:37           ` arnold
2019-11-06 13:35             ` Ronald Natalie
2019-11-04 19:25     ` SPC
2019-11-04 20:27     ` Dan Cross
2019-11-04 22:10       ` Michael Kjörling
2019-11-05  0:25     ` Anthony Martin
2019-11-02 14:12 Doug McIlroy
2019-11-02 20:12 ` Warner Losh
2019-11-03 17:12   ` Paul Winalski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).