The 'Security Digest' Archives (TM)

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

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #166 [worm lessons] (1 message, 1175 bytes)
NOTICE: recognises the rights of all third-party works.


From: [email protected] (Scott Bradner)
To: phage
Date: Tue 13:57:05 08/11/1988 EST
Subject: worm lessons
References: [Thread Prev: 165] [Thread Next: 168] [Message Prev: 164] [Message Next: 165]

Something that I think has been overlooked in the discussions
of the security "holes" & the worm.

The holes ( bugs, features...) provide an entry into an "area" of
computers.  Once there, the worm can propagate to other unix boxes
using .rhosts, hosts.equiv etc even though the target computer
had all of the above holes plugged.

Note also that a more mature worm, after finding out user's passwords,
could go around the other computers within the area trying to login to
other computers, unix or otherwise. ( Since people tend to use the
same logname & password on all the machines that they have accounts on. )

I, for one, think that posting the source for a version of passwd that
rejects "simple" or "common" passwords ( like the list in the worm
and in /usr/dict/words ) would be as important a security fix as the
plugging of the fingerd type of bug.  It takes someone more than a
bit sharp to take advantage of a bug where you have to push machine
code accross a net , or the type of bug that Peter referred to ( the
one that rtm reported when at bell & also fixed
here at Harvard ) but it would be easy for someone to make or take
programs like the perl based password checker and do much damage.

The other thing I'd like to see is some way to report security bugs
that 1/ is seperate from the normal BSD or vendor bug path so that
they will get real attention & 2/ widely known. ( Along with a
good way to get the fixed software out, for BSD sources this may
often be easy but for vendor bins its a bit of a bitch. )

A number of people have pointed out that the sendmail DEBUG option
problem has been known for years, at least 2 different programmers
working for me over the years have fond the fingerd problem & who
knows what else. Without a high priority & defined way to get
this type of thing into the "please fix yesterday" pipeline
we will keep refixing problems that we thought done with.