bzs@talcott.harvard.edu (Barry Shein) (11/10/88)
Spreading like the virus itself I am getting the following "thought virus" argument from some very predictable (old guard) people: This worm is a good reason to stop the widespread acceptance of Unix. (INSERT FAVORITE UPPER-CASE DYING O/S HERE) would not have been infected by this problem. Yeah, right, sort of like saying that if everyone drove their cars at 5MPH there'd be less fatalities on the highways. Doubtless, but wrong. The benefits of standards in operating systems far outweigh the risks. Running one of each O/S and making your users try to use them effectively is a pretty dumb way to try to achieve security. I hope we can nip *this* thought virus in the FUD. Nice try though. -Barry Shein, ||Encore||
jc@minya.UUCP (John Chambers) (11/14/88)
In article <17464@adm.BRL.MIL>, encore!pinocchio!bzs@talcott.harvard.edu (Barry Shein) writes: > > Spreading like the virus itself I am getting the following "thought > virus" argument from some very predictable (old guard) people: > > This worm is a good reason to stop the widespread acceptance > of Unix. (INSERT FAVORITE UPPER-CASE DYING O/S HERE) would > not have been infected by this problem. > Well, I've found it fairly easy to explain to novices why this is the wrong conclusion. How? I explain that the bug was based on exploiting a particular program called "sendmail" which is not part of Unix. It is part of an email package that is not even installed on the majority of Unix systems. The problem is that sendmail is normally run with "super-user" permissions, which means that Unix security is turned off while it is running. Most people understand that it isn't quite fair to criticise a security package's failures when it is not running. When they ask why sendmail needs to run with security suppressed, I just say "I don't know; its major competitor (uucp) doesn't require suppressing Unix security, and it runs fine." -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
allbery@ncoast.UUCP (Brandon S. Allbery) (11/25/88)
In his article <120@minya.UUCP> ["Re: Predictable"], jc@minya wrote: +--------------- | Most people understand that it isn't quite fair to criticise a | security package's failures when it is not running. When they | ask why sendmail needs to run with security suppressed, I just | say "I don't know; its major competitor (uucp) doesn't require | suppressing Unix security, and it runs fine." +--------------- Uucp, going through the password file (except on att.att.com, where it goes through /usr/lib/uucp/Permissions and is even more secure as a result), has plenty of security to play with. But the network entry point to sendmail is via a particular Internet port; while a random user cannot alter the shell for another user in /etc/password and cannot replace /usr/lib/uucp/uucico with another program (or so we hope), if the SMTP port weren't root-only *any* user could arrange for their own program to listen on the SMTP port and wreak all kinds of havoc on other systems. Or at minimum could read anyone's incoming net mail. Fun, eh? I'm not certain what to do about it, I'm not a network maven. Except that perhaps network ports should be handled the same way serial ports are; then *any* (incoming) port could be used to handle mail, and the "shell" for the port would be /usr/lib/sendmail. (In fact, one could use the same password file and thereby get SMTP over serial ports and an automatic "rlogin" (well, maybe "telnet") mechanism on Inet ports.) Remote mounts could log in to rmountd, etc. Anyone with a bit more knowledge about networking want to tell me what's wrong with this? What would break (yes, I know, *everything* at first -- but is there anything that absolutely depends on the current setup?) and what would require a prohibitive amount of rewriting? I'm just tossing out random ideas; they may not be useable as is, but may contain ideas that *can* be used in some other form.... ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
bzs@encore.com (Barry Shein) (11/25/88)
From: allbery@ncoast.UUCP (Brandon S. Allbery) >...But the network entry point to sendmail is >via a particular Internet port; while a random user cannot alter the shell >for another user in /etc/password and cannot replace /usr/lib/uucp/uucico >with another program (or so we hope), if the SMTP port weren't root-only >*any* user could arrange for their own program to listen on the SMTP port >and wreak all kinds of havoc on other systems. Or at minimum could read >anyone's incoming net mail. Fun, eh? In the first place that's one big *IF* (*IF* the SMTP port weren't root-only...) If a user can bypass root security on the system why is your main concern that they might intercept someone's incoming mail? Of course they can, they can just 'cat /usr/spool/mail/yournamehere' and delete what they want etc, why bother with the SMTP port? And what kind of havoc exactly can someone wreak on other systems by listening for incoming mail connections? I mean something peculiar to this ability and, what the hell, something they can't do otherwise via root permissions since that's a pre-requisite. I think people are now fully in panic mode and ceasing to make sense...I really hope this stops soon or people at least try very hard to be clear about what exactly they are concerned about, it's getting a tad bit neurotic and chicken-little'ish. -Barry Shein, ||Encore||
allbery@ncoast.UUCP (Brandon S. Allbery) (12/01/88)
As quoted from <4271@encore.UUCP> by bzs@encore.com (Barry Shein): +--------------- | From: allbery@ncoast.UUCP (Brandon S. Allbery) | >...But the network entry point to sendmail is | >via a particular Internet port; while a random user cannot alter the shell | >for another user in /etc/password and cannot replace /usr/lib/uucp/uucico | >with another program (or so we hope), if the SMTP port weren't root-only | >*any* user could arrange for their own program to listen on the SMTP port | >and wreak all kinds of havoc on other systems. Or at minimum could read | >anyone's incoming net mail. Fun, eh? | | In the first place that's one big *IF* (*IF* the SMTP port weren't | root-only...) If a user can bypass root security on the system why is | your main concern that they might intercept someone's incoming mail? | Of course they can, they can just 'cat /usr/spool/mail/yournamehere' | and delete what they want etc, why bother with the SMTP port? +--------------- The question was why the SMTP port *was* root-only. +--------------- | And what kind of havoc exactly can someone wreak on other systems by | listening for incoming mail connections? I mean something peculiar to | this ability and, what the hell, something they can't do otherwise via | root permissions since that's a pre-requisite. +--------------- Sorry. Dumb mistake. It didn't occur to me until a few days ago, in conjunction with a *different* network protocol, that there was no reason for SMTP commands to be bidirectional. (I.e. the fact that you can transmit SMTP *commands* to a program listening on port 25 doesn't mean that the receiving program can then transmit another SMTP command [e.g. DEBUG] *back*.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.