goutier@ouareau.iro.umontreal.ca (Claude Goutier) (11/14/88)
In respect to the worm incident, remember that
Happyness doesn't rhyme with Sloppiness.
There could be much fun and challenge in tightening up
a system while keeping it friendly for the end user.
Releasing an official version of a program like SENDMAIL
with debugging options turned on (especially when those
are compromising the security of the system) seems to me
a lack of concern and responsability. Like the modeline
in VI, this make me think of mild trojan horses casually
left over just in case it might prove helpfull in some
futur.
About the worm creator, I think he lacks of maturity and
responsabilty. I dont think that his purpose was to make
people think more seriously about security. He should have
known that showing a flaw is not enough to remove that
flaw (Have you heard of new releases of UNIX systems with
the sendmail option turned off yet for thoses sites which
received/payed for binary only?). When he realised that his
worm/baby went astray, did he help to repair his mischief?
As for programming, he was clever but missed his point since
the worm didn't went unnoticed, rather the contrary. Thus
a faulty program and an experiment that turned sour. This
do not qualify as brilliant. On a second thought, would you
hire such a programmer? Now think of the other smart good
guy which do not put his name in the front page of the
newspapers but which nevertheless do a real contribution
to the field of computer science (think about Larry Wall,
Henry Spencer, Richard Stallman, etc. just a few names thrown
"pele-mele").
In conclusion, we should put more energy on closing up gaps
in our systems, than debating the mishap or virtue of the
people who illustrate the failures of our systems by absurdum.
To do otherwise is just a waste of resources and energy.
--
Claude Goutier Centre de calcul, Universite de Montreal
C.P. 6128, Succ "A", Montreal (Quebec)
goutier@iro.umontreal.ca Canada H3C 3J7 (514) 343-7234jc@heart-of-gold (John M Chambers) (11/22/88)
In article <746@mannix.iros1.UUCP>, goutier@ouareau.iro.umontreal.ca (Claude Goutier) writes: > In respect to the worm incident, remember that > Happyness doesn't rhyme with Sloppiness. > > There could be much fun and challenge in tightening up > a system while keeping it friendly for the end user. > > Releasing an official version of a program like SENDMAIL > with debugging options turned on (especially when those > are compromising the security of the system) seems to me > a lack of concern and responsability. Like the modeline > in VI, this make me think of mild trojan horses casually > left over just in case it might prove helpfull in some > future. > Not necessarily; I've seen just the opposite argument. The best metaphor I've seen so far goes as follows: Disabling debug code for customer releases is like a would-be pilot wearing a parachute to ground school, and taking it off when in the air. In other words, when you release code to customers, they invariably run it in environments very different from your development lab, and they (mis)use it in lots of ways that the developers didn't think of. You invariably get problem reports, and that's when you really need the debug code. With it, you can tell the customer "Re-run the 'foo' command with a '-d4' option and tell me what it says." Think of how much easier this is than analyzing the code to try to figure out by logic alone how it may generate the behavior reported by the customer (and which you can't get on your system no matter how much you try to set things up "just like" the customer's system). The problem really wasn't that sendmail included a remote-debug facility; I'd compliment its designers/installers for that. The problem was that this debug facility included a remote-execute "feature". Considering that sendmail is, in effect, a command interpreter (i.e., "shell") that runs as root, doesn't always require a password, and is accessible from the entire internet, such a shell escape seems a bit unwise. But a debug facility doesn't necessarily require such a powerful feature. I might also note that uucp's daemon potentially has similar problems, but it has a simple way of limiting the damage. There is a control file (L.cmds or Commands, depending on version) that contains a list of the allowed remote commands. Anything not in the list is just simply not executed. Perhaps sendmail's debug feature could profit from some such simple mechanism. -- From: John Chambers <heart-of-gold.mitre.org!jc> From ...!linus!!heart-of-gold!jc (John Chambers) Phone 617/217-7780 [The above opinions were packaged by volume, not by weight; some settling of contents may have occurred during distribution.]
woerz@iaoobelix.UUCP (Dieter Woerz) (11/26/88)
In article <177@heart-of-gold> jc@heart-of-gold (John M Chambers) writes: > ... >The problem really wasn't that sendmail included a remote-debug facility; >I'd compliment its designers/installers for that. The problem was that >this debug facility included a remote-execute "feature". Considering >that sendmail is, in effect, a command interpreter (i.e., "shell") that >runs as root, doesn't always require a password, and is accessible from >the entire internet, such a shell escape seems a bit unwise. But a debug >facility doesn't necessarily require such a powerful feature. > ... What I'd like to know is, what was this "feature" supposed to be used for, as you can't use this feature without the debug option enables. So you can't use the "shell escape" within normal operation, why was it included in the debug operation? ------------------------------------------------------------------------------ Dieter Woerz Fraunhofer Institut fuer Arbeitswirtschaft und Organisation Abt. 453 Holzgartenstrasse 17 D-7000 Stuttgart 1 W-Germany BITNET: iaoobel.uucp!woerz@unido.bitnet UUCP: ...{uunet!unido, pyramid}!iaoobel!woerz