postmaster@nssdca.gsfc.nasa.gov (11/14/88)
*** VMS error in delivery mail, error message follows *** EXOS Mail server: delivery error: %MAIL-E-OPENOUT, error opening NCF_VAXPERTS:[PIPES]MAIL$00040091BCEE4FBE.MAI; as output EXOS Mail server: delivery error: -RMS-E-CRE, ACP file create failed_VAXPERTS:[PIPES]MAIL$00040091BCEE4FBE.MAI; as output EXOS Mail server: delivery error: -SYSTEM-F-EXDISKQUOTA, disk quota exceededS:[PIPES]MAIL$00040091BCEE4FBE.MAI; as output EXOS Mail server: delivery error: %MAIL-E-OPENOUT, error opening NCF_VAXPERTS:[PIPES]MAIL$00040091BCEE4FBE.MAI; as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-EXDISKQUOTA, disk quota exceeded *** Original message follows *** From : UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V6#017 Return-path: <unix-wizards-request@sem.brl.mil> Received: from SEM.BRL.MIL by nssdca.GSFC.NASA.GOV id 20C05087002 ; Sun, 13 Nov 88 16:44:45 EST Received: from SEM.BRL.MIL by SEM.brl.MIL id aa09382; 13 Nov 88 3:08 EST Received: from sem.brl.mil by SEM.BRL.MIL id aa09309; 13 Nov 88 2:45 EST Date: Sun, 13 Nov 88 02:45:26 EST From: The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL> To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Message-ID: <8811130245.aa09309@SEM.BRL.MIL> UNIX-WIZARDS Digest Sun, 13 Nov 1988 V6#017 Today's Topics: Re: Makefile Re: Implications of recent virus (Trojan Horse) attack Re: Crackers and Worms BSD passwd() [was Re: How to stop future viruses.] Readable Password File Re: Bigger "dev_t"s Re: Bigger process IDs and "dev_t"s (was: Re: RISC v. CISC...) Re: Internet Virus: SunOS patches Re: Process restart. Re: various worm questions Re: Worm/Passwords Re: /etc/shadow Re: BSD passwd() [was Re: How to stop future viruses.] Re: Internet Virus: SunOS patches Re: Worm/Passwords Re: The Internet Virus--A Commentary Re: How to stop future viruses. Re: How do I get *8* data bits *no* parity? Re: The Internet Virus--A Commentary Re: Implications of recent virus (Trojan Horse) attack Re: Crackers and Worms Re: Worm/Passwords Morris Tech Report Re: Crackers and Worms Re: Worm/Passwords Re: Implications of recent virus (Trojan Horse) attack Re: How do I get *8* data bits *no* parity? Re: Internet Virus: SunOS patches Re: Process restart. Re: The Internet Virus--A Commentary Re: Crackers and Worms Re: Bigger process IDs and "dev_t"s (was: Re: RISC v. CISC...) ----------------------------------------------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Makefile Date: 11 Nov 88 22:14:09 GMT To: unix-wizards@sem.brl.mil >Is it possible to use the inbuilt commands of the shell >from a makefile ? The shell is csh. Well, I would suggest you not use "csh", unless you know you're always going to be on a system that has it, but that's a separate issue. "make" tends to pass commands containing shell meta-characters to a shell, rather than running them itself. This means such commands could include built-in commands, etc., as long as the command line also contains such a meta-character. However, many "make"s always pass them to "/bin/sh". Others pass them to the shell specified by the SHELL Makefile variable, which is generally inherited from the environment. Thus, while you can usually guarantee that the Bourne shell will get the commands, you're less likely to be able to guarantee that the C shell will get them. (Then again, with UNIX systems, you can usually guarantee that there's a Bourne shell available, but you're less likely to be able to guarantee that there's a C shell available.) Furthermore, some commands won't do what you expect; e.g., "cd". If your Makefile contains <commands...> cd <directory>; <more commands...> The <more commands> will be executed in the same directory as the <commands>, the "cd" nonwithstanding; the <commands> will either be executed directly by "make" or by a subshell, the "cd" will be executed by a different subshell (the ";" is there to ensure that "make" doesn't try to execute a program named "cd"), and the <more commands> will either be executed by "make" (which hasn't changed its current directory) or by a different subshell run from "make" (which will inherit "make"s current directory). Also, "make" passes commands to the shell with the "-c" flag; it passes a single command line to the shell. You can put the command on multiple lines in the Makefile, using backslashes at the end of the lines to continue the command, so that you can put a Bourne shell construct on multiple lines: for i in $(MAKEVARIABLE); do \ command $$i; \ done which gets passed to the shell as /bin/sh -c "for i in <expanded Makevariable>; do command $i; done" The Bourne shell doesn't mind this; I don't know if the C shell does or not. ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Implications of recent virus (Trojan Horse) attack Date: 11 Nov 88 22:43:55 GMT Keywords: virus security To: unix-wizards@sem.brl.mil >If this hole exists, it can be traced to getpwent() not being careful >enough when it parses /etc/passwd records. See UNIX System V for the >simplest fix. If that fix is "have 'getpwent()' return NULL if the entry it looks at is syntactically incorrect," the fix is simple but rather rude; the net result is that any program scanning the password file linearly - e.g., "passwd" - will think it's at the end of the file if it sees such a syntactically incorrect line. Having "passwd" cut off the password file as soon as it sees a blank line isn't very nice; ignoring the syntactically-invalid lines, or passing them through unchanged, is probably a better idea. The former could be done by having "getpwent" skip over those entries, rather than return NULL on them; the latter requires that "passwd" not just naively use "(f)getpwent" and "putpwent" to update the password file. ----------------------------- From: Rick Adams <rick@seismo.css.gov> Subject: Re: Crackers and Worms Date: 11 Nov 88 20:57:16 GMT Keywords: bug reality To: unix-wizards@sem.brl.mil At the very least, you should mail the suspected (or proven) problem to Berkeley. They do listen. There's no security argument against sending it to Berkeley. Let them decide to post it or not (if you have doubts yourself). There is no legitimate reason to keep things like that to yourself. (and Berkeley is aware of the details of the setuid shellscript bug. They know of no fix other than to stop using setuid shellscripts. Thats the bug fix they posted. They chose not to post the bug, but the only fix they knew) --rick ----------------------------- From: "Paul M. Aoki" <aoki@faerie.berkeley.edu> Subject: BSD passwd() [was Re: How to stop future viruses.] Date: 12 Nov 88 05:45:33 GMT Sender: news@pasteur.berkeley.edu To: unix-wizards@sem.brl.mil In article <10436@eddie.MIT.EDU> jbs@fenchurch.UUCP (Jeff Siegal) writes: >In article <10835@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >>You don't need to use all 4096 salts; you simply need the ones used >>on the target system. > >It turns out that, due to a (apparent) bug in passwd.c, at least on >Berkeley systems, only about 400 salts ever get used. > >Jeff Siegal Hmm. I just pawed over the password file on ernie.berkeley.edu [ that's right, the place the worm was transmitting its location to ... ] and found 630 salts for 671 accounts with passwords. Some of those passwords have been there for an awfully long time. Where did you get this information? ---------------- Paul M. Aoki CS Division, Dept. of EECS // UCB // Berkeley, CA 94720 (415) 642-1863 aoki@postgres.Berkeley.EDU ...!ucbvax!aoki ----------------------------- From: Brad Templeton <brad@looking.uucp> Subject: Readable Password File Date: 11 Nov 88 07:21:31 GMT To: unix-wizards@sem.brl.mil The philosophy behind the readable password file is old, but was valid at the time, I think. The idea was that non-ecrypted passwords in an unreadable file is no kind of password security, although it's exactly the kind of security that GCOS has. If you use this method, than any problem which allows mere *read* access to disks is enough to get complete, often undetectable, access to the system. For example, just physical access to disk packs or backup tapes is enough. So when they made the Unix password file, as I understand it, they said, "We have to assume people will get at the password entries, so let's put all or security into encryption." With hindsight, it seems a combination is in order, but the philosophy that you should assume that any sophisticated cracker will get to read them still should apply. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473 ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Bigger "dev_t"s Date: 12 Nov 88 05:45:13 GMT To: unix-wizards@sem.brl.mil >Better yet, have /dev be a special file system of its own (using the >file system switch) that takes care of the details of mapping strings >to driver entries. One nuisance with this would be that, unless the contents of this file system were somehow recorded (completely or partially) in some form of non-volatile storage, you'd have to stick bunches of "chown" commands in some place such as "/etc/rc" in order to be able to administer permissions on files. The simplest implementation of such a file system would give all "/dev" files the same permissions, and that would either be too restrictive or too permissive a default; fancier implementations would quite likely put policy code into the kernel, which I would oppose both for philosophical and practical reasons. I don't have any great problem with the "chown"s being stuck in "/etc/rc" (the moral equivalent of those "chown"s are in "/dev/MAKEDEV" on BSD systems and systems that have adopted MAKEDEV from BSD, for example), but it may be a minor inconvenience to have to stick them there. ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Bigger "dev_t"s Date: 12 Nov 88 05:52:30 GMT To: unix-wizards@sem.brl.mil (Continued from previous rock) Some people at Sun have suggested the same idea, with "specfs" becoming not just a class of vnodes but a "real" mountable file system. Bill Shannon suggested making "/dev/fd" a file system; this has the advantages that 1) you might not have to whack up the VFS kernel's "open" code to pass an extra argument to device drivers (as in Arnold Robbins' "/dev/fd" driver); 2) you would't have to create or destroy entries based on the maximum number of file descriptors per process supported by your kernel. (You could even get *truly* perverse and have it look different in different processes, so that it reflects the number of *open* file descriptors....) ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Bigger process IDs and "dev_t"s (was: Re: RISC v. CISC...) Date: 12 Nov 88 05:54:19 GMT To: unix-wizards@sem.brl.mil >So, what is the problem with just making dev_t bigger? Is there some magic >code out there that would be hurt by making it 32 bits wide? It's mostly a binary-compatibility issue, not a source-compatibility issue. ----------------------------- From: "G.Pavlov" <pavlov@hscfvax.harvard.edu> Subject: Re: Internet Virus: SunOS patches Date: 12 Nov 88 01:36:57 GMT Posted: Fri Nov 11 20:36:57 1988 To: unix-wizards@sem.brl.mil In article <426@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > > You can argue, probably justifiably, that they [Sun] should either have turned > DEBUG off when building it, or at least made debug mode not have the > side-effect of allowing addresses other than user names in RCPT lines, > but you can also argue that Berkeley should have done that as well.... I have not seen Berkeley advertising the suitability of their work for end- user or commercial applications. Sun's does daily. greg pavlov, fstrf, amherst, ny ----------------------------- From: Keith Gabryelski <ag@elgar.uucp> Subject: Re: Process restart. Date: 11 Nov 88 19:19:14 GMT Keywords: Fork, Process, migration, remote, a.out, core Posted: Fri Nov 11 11:19:14 1988 To: unix-wizards@sem.brl.mil In article <8857@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Only rather simple-minded uses of processes can >be properly restarted from snapshots. Snapshots are not the only mean of process restart, but they are the most likely for what I was thinking. >To take a specific example, I defy you to restart a snapshot >of the "layers" program using any general-purpose mechanism. I doubt a shell is something some one would want to restart (although migrate is a different matter). You would probably want some of the proceses that are running under the shell, though. Long running procesess that don't have any means of shutdown/restart built into them are what I am thinking of. Let's say we have this process computing prime numbers (or some other simple case) and the system needs to be shutdown because of some fatal error. Can a snapshot be done? -- ag@elgar.CTS.COM Keith Gabryelski ...!{ucsd, jack}!elgar!ag ----------------------------- From: Doug Gwyn <gwyn@smoke.brl.mil> Subject: Re: various worm questions Date: 12 Nov 88 05:51:29 GMT To: unix-wizards@sem.brl.mil In article <935@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: > I've a couple of worm questions. First, we all know that a >bug in the program caused it to propagate wildly. Does anybody >know what the bug was? No source code, just a general idea.... This wasn't characterized quite correctly in the media reports. The biggest flaw in the design was that no provision was made to avoid propagation back to an already-infested host. > Second, if Mr. Morris had decided to hide himself, and >assuming nobody stumbled across his files on his home machine, is >there any chance that this whole thing could have gone one >without a clue as to where it came? It should be noted that Morris is only the ALLEGED perpetrator. I suggest that discussions should use "the perpetrator" until the perpetrator's identity has been legally established. Investigators made considerable progress in tracing the origin of the attacks without help from any alleged confession. I don't think it would be wise to explain publicly how this could be done. ----------------------------- From: Doug Gwyn <gwyn@smoke.brl.mil> Subject: Re: Worm/Passwords Date: 12 Nov 88 05:59:51 GMT To: unix-wizards@sem.brl.mil In article <8563@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >I have been working on a drop-in replacement for login and friends since I >learned of the Internet virus. Why? Your replacement would not have stopped this virus. Making life harder for legitimate users does not necessarily increase security, and it often achieves the opposite effect. ----------------------------- From: Doug Gwyn <gwyn@smoke.brl.mil> Subject: Re: /etc/shadow Date: 12 Nov 88 06:27:07 GMT To: unix-wizards@sem.brl.mil In article <2189@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >The documentation is scattered in the Release Notes for System V >Release 3.2. Thanks for posting the information. It is sites that DON'T HAVE SVR3.2 that are most in need of this information. >If there is no entry in >/etc/shadow we accept the /etc/passwd as gospel [in case someone >forgot to run /usr/lib/pwconv after adding a user.] That seems like a mistake. Far better to detect this omission when the new user first tries to log in than to gradually accumulate security holes. It also seems that the following are missing: "pwvalid" utility (necessarily privileged) to SLOWLY check a (user,password) pair for validity. Since it is insecure to pass this information as command-line arguments, they should be read from standard input (typically via a pipe connection). Obviously the exit status would be 0 if and only if the pair checks out ok. (The temptation to also log failures should be resisted!) A two-second delay should be acceptably slow. "int pwvalid(const char *user, const char *password)" C library function that simply opens a pipe to the above utility and returns true only when the arguments constitute a valid pair. In the above, probably it would be safest to use the encrypted form of a trial password instead of plaintext. It bothers me that some network protocols send unencrypted passwords over the network. All password-checking programs should use these interfaces to validate passwords. ("passwd" can use them for part of its job, but it also has to update the shadow file. So far as I know no other program needs to write (encrypted) passwords in such that it couldn't use "passwd" to do this for it.) ----------------------------- From: Jeff Siegal <jbs@fenchurch.mit.edu> Subject: Re: BSD passwd() [was Re: How to stop future viruses.] Date: 12 Nov 88 16:35:40 GMT Sender: uucp@eddie.mit.edu To: unix-wizards@sem.brl.mil In article <7311@pasteur.Berkeley.EDU> aoki@faerie.Berkeley.EDU (Paul M. Aoki) writes: >In article <10436@eddie.MIT.EDU> jbs@fenchurch.UUCP (Jeff Siegal) writes: >>[...]only about 400 salts ever get used. >Hmm. I just [...] found 630 salts for 671 accounts [...]. Yes, it is pretty clear now that my claim is wrong. >Where did you get this information? I was told this a while ago--I don't remember by whom. Before posting the information, I did check the source code but I did not think very hard about what I saw. After looking again and thinking a bit, I see now why it isn't true. Jeff Siegal ----------------------------- From: ekh@ho4cad.att.com Subject: Re: Internet Virus: SunOS patches Date: 11 Nov 88 12:27:24 GMT Sender: nuucp@ho7cad.att.com To: unix-wizards@sem.brl.mil In article <754@m10ux.UUCP>, rgr@m10ux.UUCP (Duke Robillard) writes: . . . > The long term solution is to write anti-bodies. After all, that's > what evolution came up with, and she had 4 billion years to work on it. . . . OH MY GOD WHAT ARE YOU TRYING TO DO???? I can see it now, 500 articles a day in comp.unix.wizards, debating creation vs. evolution. The resulting network traffic would make the recent virus seem like child's play!!!! ----------------------------- From: Barry Shein <bzs@encore.com> Subject: Re: Worm/Passwords Date: 12 Nov 88 19:02:23 GMT Sender: news@husc6.harvard.edu Followup-To: comp.unix.wizards To: unix-wizards@sem.brl.mil Which is better, improved password security or shadow passwd files? Do we really need both? The following proposals seem to be on the table: 1. Improve the encryption algorithm so brute force attack on even relatively "easy" passwords becomes difficult. This is typically done by slowing down the fastest possible implmentation of the algorithm. 2. Improve software which ensures users choose hard to crack passwords. This is fuzzy although major problems are certainly easy to avoid (eg. dictionary words.) I'm sure people will still manage to come up with bad pw's but I'm also sure we can minimize most of this with a little software, at worst it may have to be improved and extended from time to time. 3. Shadow passwords, this is the only one of the above which might require some changes to a lot of software and possibly cause backwards compatability problems which may or may not be acceptable. It's also a major philosophical shift. The last point, of course, assumes that the passwd file is the weak link and sort of throws up its hands on the problem admitting that if a listing of the one true passwd file gets out yer dead meat (eg. thru a carelessly discarded listing or other methods, like snatching other people's bitmap window screen images when you notice a vipw running, cough cough.) I tend towards the original idea of a publicly readable password file on the assumption that if you can't make that secure you're finished, it's not going to be THAT hard to get a listing of your systems password file from all sorts of sources, like operators who might not understand or don't care or just plain accidents. Are we really interested in creating a situation where every time we suspect someone has gotten a listing of the shadow password file we then must force all users to change their passwords? It certainly seems like that is what this creates. -Barry Shein, ||Encore|| ----------------------------- From: Barry Shein <bzs@encore.com> Subject: Re: The Internet Virus--A Commentary Date: 12 Nov 88 19:36:30 GMT Sender: news@husc6.harvard.edu Followup-To: comp.unix.wizards To: unix-wizards@sem.brl.mil >So tell me: how will a *class* in ethics make someone more responsible >and concerned about right and wrong? I don't think I've ever seen a >person become responsible or moral as a result of a class -- this seems >to be a set of values kids acquire (or don't acquire) pretty young. >-- >Clayton E. Cramer You're missing the point. The intention is not to mend the broken, the intention is to try to get a bunch of mostly young people in a room once and try to convince them not to do some of these things. Part of the method would be: a) Convincing them that *most* of the obnoxious things they are going to think up are not clever and have been tried before. Making them memorize a long list of pranks might really dampen the adolescent enthusiasm that they've thought up something clever. NOTE: I DO NOT THINK WHAT RTM (ALLEGEDLY) DID WAS CLEVER, it was stupid and obvious, all of it. b) Informing them of the possible outcome of their behavior, if they must, is useful. I wish I had a nickel for every kid who said "gee, it was *only* a joke". F**K YOU! That's not a JOKE! YOU WANT A JOKE, HERE'S A JOKE!..."rm -rf ~yourname" HA HA HA, now go away... Someone has to say at least once that files are property and represent people's work, that the support staff's time is valuable and is as amused at your horsing around as your typical chemical lab TA is amused at you throwing reagants about the room. AND, that there could very well be legal implications of your actions beyond our control, what they are, and what results you might expect (eg. if you break into someone else's private files and they decide to press charges or sue you may very well be up the proverbial creek if the evidence is there, and it has *nothing* to do with local policy, sorry.) c) Finally, what is expected of people on public networks, beyond "the obvious". Things like which ones frown on commercialism (an error I've seen new users make innocently trying to help a friend make a buck.) The whole problem here is ignorance. If given the information they still choose to ignore it (and hopefully there will be less such problems as at least some will be convinced, even if only of the detectability of their acts and consequences) well you did the best you could. At least you did *something* which probably helped somewhat. Actually, I'd go one step further and require a course like the above and certification of completion as a minimum requirement to obtain access to a computer attached, even indirectly, to a public network. Failure to obey this could result in an institution's loss of access to networks and quite possibly denial of contracts from research agencies, at least as a second-order effect. Failure by the individual (at any point in his/her career) could result in revocation of his/her certification and consequent loss of ability to earn a living or an education (etc) in this field (after due process) and permanent notation of the facts of the case available for security or employment review (maybe, I'd be glad to hear arguments about the accessibility issue tho it's not critical.) Seems better than facing 20 years in prison and other lynch-mob stuff the public will dream up, allows professionals to have an effective hand in reviewing infractions rather than going immediately to the public courts where there's no requirement that the judge or jury have any understanding of the details of the infraction and provides an effective and direct method of punishment for those who are found guilty, loss of livelihood in this field. Of course further criminal and economic liabilities are possible, but at least there is a first line of action. -Barry Shein, ||Encore|| P.S. This is an argument for absolute minimal and mostly ethical competence, not for actual competence in the field which I will agree is a whole other can o' worms. Think of it more like a driver's or ham radio operator's license than a professional certification of competence. Proof that you might know actions and consequences relating to misuse of shared computing facilities and the opportunity to lose access. ----------------------------- From: Anders Bj|rnerstedt <anders@suadb.uucp> Subject: Re: How to stop future viruses. Date: 11 Nov 88 12:15:36 GMT To: unix-wizards@sem.brl.mil I would like to add: 6. A less blunt use of the set-user-id mechanism. Sendmail apparently needs to do rights amplification, but I dont see why it needs superuser rights. The uucp binaries have thier own owner/domain "uucp". Why cant the binaries related to mail have a similar domain "mail". I am sure there are other suid programs which are today owned by root, but which dont actually need full superuser priviliges. 7. It should be *possible* to physically write lock filesystems including the root file system. The disk write lock could perhaps be used, but the fact that it is tied to a device usually creates problems. What is needed is a physical togle for a logical concept: secure filesystems. It should be possible to place stable things like system programs in file systems marked "secure". The kernel (which would itself be placed in a secure filesystem) would only allow writes to a secure filesystem if a physical togle was in the "open" position. Normally the togle would be in the closed position. The togle is opened only when changes are really needed and requires a person to physically do it on-site. Sometimes this would be perceived as an inconvenience, but for those willing to pay the price it should be possible ------------------------------------ Anders Bjornerstedt Department of Computer & Systems Sciences University of Stockholm S-106 91 Stockholm Sweden INTERNET: anders@sisu.se OR anders%sisu.se@uunet.uu.net UUCP:{uunet,mcvax,cernvax}!enea!sics!sisus!anders. ----------------------------- From: Gert Illemann <gerti@ncrdk.dk> Subject: Re: How do I get *8* data bits *no* parity? Date: 8 Nov 88 02:22:39 GMT Keywords: tty_configuration, /etc/gettydefs To: unix-wizards@sem.brl.mil In article <130@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: > We're running Micrport System V/AT release 2.4 and need to change the tty > default for incoming modem calls from the default (7 data bits even parity) > to 8 data bits no parity ... > ... I tried changing the standard entry: ... to: > 1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > but it didn't make any significant difference. Why not? Because you are using SANE, that will - among other settings - give you CS7 and PARENB > Why does UNIX default to 7 data bits/even parity, anyway? Most ports defaults to 7+even, because it used to be a good guess, as to what the terminal would like. That is even today a very good guess; the majority of terminals, used world-wide, are ASCII (more or less) based (not extended ASCII, just plain ASCII). As the character-width (unfortunately) still is only 8 bits in UNIX and as it's very nice to have some measure of assurance of what you type is what the program gets, most people prefer to use the eighth bit for parity checking. > ...If I succeed in switching to 8 data bits will > there be any unwanted side effects I should beware of? Yes ! dont use TAB3, it means "expand tabs to spaces"; normally that would be wrong (VERY wrong sometimes) for uucp-traffic. > I was told by one of the tech support folks at microport that the "#" in the > center of the gettydefs record delimits line condition BEFORE login from > line condition AFTER login. Is this correct? Yes, he was right there, syntax : name# initial settings (i.e. for opening and writing the login-message) \ # final settings (i.e. sat just before login is executed) # login-message \ #next-name >In general, I'd be fascinated > to hear the full story of what is really going on in a gettydefs entry. > While I can look up the supposed definition of some of these field mnemonics > (e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely > inadequate in describing the available options and interactions in line > control settings. I wont't give you more of the story here, but, have you studied getty(1M), termio(7), gettydefs(4), stty(1) and maybe ioctl(2), I'm sure you know what to do. It's more than the part-time system-administrator cares to do, I know, so maybe you should ask your support-person(s) to do it :-) Gert Gert Illemann / gerti@ncrdk.dk (...uunet!mcvax!dkuug!ncrdk!gerti) NCR Danmark A/S, System Service Division Teglv{rksgade 31, DK-2100 Copenhagen O >>DISCLAIM.ABSOLUTE<< Nobody or -one, but I, claims to think so as it's probably incorrect, inconsistent, incoherent and generally untrustworthy ----------------------------- From: Pete Holsberg <pjh@mccc.uucp> Subject: Re: The Internet Virus--A Commentary Date: 12 Nov 88 17:13:46 GMT Followup-To: comp.unix.wizards To: unix-wizards@sem.brl.mil The function of a class on ethics is to raise the consciousness of the attendees. There are probably *many* young programmers/students/?? who don't realize that breaking into someone's machine is wrong. Of course, it will not deter those who know it is wrong but do it anyway. -- Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh Mercer College CompuServe: 70240,334 1200 Old Trenton Road GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800 ----------------------------- From: Mike Haertel <mike@stolaf.uucp> Subject: Re: Implications of recent virus (Trojan Horse) attack Date: 12 Nov 88 20:37:31 GMT To: unix-wizards@sem.brl.mil In article <8562@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >Do you *really* trust college students to write real software? If so, you >must have never attended a university similiar to the one I graduated from. I am a college student. Also the author of GNU grep, coauthor of GNU diff, and working on GNU sort . . . all of my programs are faster and (I hope) more robust than the Unix programs they replace. I am glad to hear that you don't trust me to write real software, and that you will not be using my programs. Do you really trust your vendor to write real software? Most of them won't distribute source, so you can't check for trojan horses et. al. You can't fix bugs that arise, unless you are good at reading and patching binaries. Most of them have license agreements that prevent you from doing this, if you are a person who keeps your word. I have heard that the reason some vendors don't distribute source is that they don't want their customers to see how badly written it is. --- Mike Haertel Really mike@stolaf.UUCP, but I read mail at mike@wheaties.ai.mit.edu. ----------------------------- From: Rahul Dhesi <dhesi@bsu-cs.uucp> Subject: Re: Crackers and Worms Date: 12 Nov 88 20:46:57 GMT Keywords: bug reality To: unix-wizards@sem.brl.mil In article <14505@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Actually, you get a `daemon' shell---not as bad, but, as Keith put it, >`not my idea of a good time'. But at's jobs to be executed are owned by daemon, so isn't being daemon just a trivial step away from being root? Somebody mentioned this earlier and nobody contradicted him. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ----------------------------- From: Ron Elliott <ron@embossed.uucp> Subject: Re: Worm/Passwords Date: 12 Nov 88 15:15:07 GMT To: unix-wizards@sem.brl.mil In article <8563@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > In article <17830@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > > Some years ago, I posted a small piece of code to the net which > ... > >troubles, I am reposting it to comp.sources.unix. > > It has been posted to alt.sources and pubnet.sources. I truly welcome > comments and invite your participation. I'd have posted it to > comp.unix.sources but it is far from finished. > -- THANKS, WE DON'T SEE ENOUGH OF THESE POSITIVE REACTIONS!! I guess it's too much to hope for, but here goes: 1) There are more and better minds avaliable to fix problems regarding virii, worms, bugs, and the like than there are people who will exploit these problems. However, if these problems aren't widely and openly discussed, the more and better minds won't be thinking about solutions. Hence, count one vote for net.security. 2) The courts and society will have their way with the Morriss'. That's the American way. I doubt that net.fuzzy.opinions will count for much. Let's move on. 3) Thousands of us out here don't have source code, and have to rely on software venders. These venders are mostly unresponsive to any problem brought up by end-users. Only high level publicity and threat of negative corporate image will move these venders to react. Often, even these these threats aren't enough. Until there are more responsive venders, we source-code-users are vunerable to all kinds of attack -- and will remain vunerable. 4) Many of you talk about the thousands of hours lost due to the Morris Worm. How about something like "rm *" ? How many hours have been lost over the last 15 years over that bug-feature.? Yes, I know the workarounds, and have installed them. How come though Un*x venders still havn't issued fixed rm's or even discuss the matter in their documentation? Or even supplied the workarounds in their distribution? Just had to put in my $0.02. Thanks for your attention. Ron Elliott. Flames Burn Bandwidth. Better Sent to /dev/null ----------------------------- From: dmr@alice.uucp Subject: Morris Tech Report Date: 12 Nov 88 07:10:32 GMT To: unix-wizards@sem.brl.mil Those interested in earlier works of Robert T. Morris, or interested in network security in general, might wish to read AT&T Bell Laboratories CSTR #117, "A Weakness in the 4.2BSD Unix TCP/IP Software," by Robert T. Morris, dated Feb. 25, 1985. An abstract of the abstract: ... [E]ach 4.2BSD system "trusts" some other set of other systems, allowing users logged into trusted systems to execute commands via a TCP/IP network without supplying a password. These notes describe how the design of TCP/IP and 4.2BSD implementation allow users on untrusted and possibly very distant hosts to masquerade as users on trusted hosts. Bell Labs has a growing TCP/IP network connecting machines with varying security needs; perhaps steps should be taken to reduce their vulnerability to each other. This technical report, as well as others, may be ordered by writing to Ellen Stark Room 2C579 AT&T Bell Laboratories 600 Mountain Ave. Murray Hill, NJ 07974 These reports are free of charge. Dennis Ritchie research!dmr dmr@research.att.com ----------------------------- From: Chris Torek <chris@mimsy.uucp> Subject: Re: Crackers and Worms Date: 12 Nov 88 22:54:28 GMT Keywords: bug reality To: unix-wizards@sem.brl.mil In article <4713@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >But at's jobs to be executed are owned by daemon, so isn't being daemon >just a trivial step away from being root? Somebody mentioned this >earlier and nobody contradicted him. Who runs `at'? :-) (We use MDQS; `at' is a front-end for the batch queue.) To forestall the inevitable: MDQS is available from BRL. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: John Mashey <mash@mips.com> Subject: Re: Crackers and Worms Date: 12 Nov 88 21:14:01 GMT Keywords: bug reality To: unix-wizards@sem.brl.mil In article <2373@aplcomm.jhuapl.edu> jwm@aplvax.UUCP (Jim Meritt) writes: >In article <829@mcrware.UUCP> droid@mcrware.UUCP (Andy Nicholson) writes: >}I'll bet the KGB are laughing their asses off. >Bet they're not: They see what a kid without malacious intention can do, >and then they look at their rather pitiful computer systems, look at our >trained personnel WITH malicious intent, and probably shudder.... On the other hand, is the state of networking in the USSR such that 6000 machines could easily be infected in a day?....I have no personal knowledge, but I'd guess not. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 ----------------------------- From: Anthony Burzio <burzio@mmlai.uucp> Subject: Re: Worm/Passwords Date: 11 Nov 88 15:39:04 GMT To: unix-wizards@sem.brl.mil Hmmm... Seems to me that with all the media hype this problem has been getting, a group of concerned UNIX wizzards could ask the government for a few million to once and for all close the security holes in UNIX (no one argues there are none, just how big they are :-) If this group could also kind of accidentally :-) solve the old SYSV vs BSD rowl at the same time, so much the better. *************************************************************** Tony Burzio * UNIX is a portable operating system... Martin Marietta Labs * By the way, which UNIX are you using? *************************************************************** ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Implications of recent virus (Trojan Horse) attack Date: 12 Nov 88 21:25:20 GMT Keywords: virus security To: unix-wizards@sem.brl.mil >Or, to keep someone else from doing this, remove lines like: > >::0:0:: > >from your password file. Most Sun systems have this as a default >(stupid!). Excuse me, but to what are you referring? Most Sun systems have a line like +::0:0::: as a default, but this is INequivalent to ::0:0:: Lines of the latter sort are generated by the scenario Doug Gwyn described; the problem is that "getpwent" doesn't, in some systems, check that the login name field is non-null before returning a value. (S5R3's version checks, but unfortunately returns NULL rather than skipping the invalid entry, which causes programs to think a blank line in "/etc/passwd" is really the end of the file.) ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: How do I get *8* data bits *no* parity? Date: 12 Nov 88 21:34:27 GMT Keywords: tty_configuration, /etc/gettydefs To: unix-wizards@sem.brl.mil >As the character-width (unfortunately) still is only 8 bits in UNIX It's not just a question of UNIX, it's a question of hardware. In the case of asynchronous serial ports, the hardware ultimately controls how many bits the system is willing to accept between the start and stop bits. Some asynchronous serial port hardware (most such hardware, I suspect) is capable of framing characters with a start bit, 9 other bits, and a stop bit; such hardware will treat 8 of those bits as data bits and the 9th as a parity bit. Not all software that controls that hardware will put it in this mode, however. Systems with a full System V-style tty driver interface will do so; just set CS8 and PARENB. This should include the system in question (it also includes SunOS 4.0 and later, and will probably include the next BSD release, since it will at least support a POSIX-style tty driver interface, and that permits 8 bits plus parity). Systems with a V7-style tty driver interface, such as current BSD systems, won't put the hardware in that mode; the software running inside some terminals may not do so either, in which case setting the host up to support this doesn't help you any. >> ...If I succeed in switching to 8 data bits will >> there be any unwanted side effects I should beware of? > >Yes ! dont use TAB3, it means "expand tabs to spaces"; normally that would >be wrong (VERY wrong sometimes) for uucp-traffic. If the guy wants 8-bit support for a user's terminal, rather than UUCP or some other software that wants an 8-bit "pass-through" binary data path, there should be no problem with setting TAB3; if the guy wants 8-bit support for a "pass-through" binary data path, the proper advice is "don't use OPOST", not "don't use TAB3", because *any* tty driver transformation of data on output - or input, for that matter - will be wrong. ----------------------------- From: Guy Harris <guy@auspex.uucp> Subject: Re: Internet Virus: SunOS patches Date: 12 Nov 88 21:37:45 GMT To: unix-wizards@sem.brl.mil >> You can argue, probably justifiably, that they [Sun] should either have turned >> DEBUG off when building it, or at least made debug mode not have the >> side-effect of allowing addresses other than user names in RCPT lines, >> but you can also argue that Berkeley should have done that as well.... > > I have not seen Berkeley advertising the suitability of their work for end- > user or commercial applications. Sun's does daily. This hardly argues that it was OK for Berkeley to consciously leave that trap door in without warning people about it. (It also doesn't argue that Sun should, but then I wasn't arguing that it *was* OK for Sun to do this. I was just pointing out that Sun didn't consciously make the software *less* secure than it was as it came from Berkeley; the original poster was asserting that Sun and Mt. Xinu had done precisely that, which was simply not true.) ----------------------------- From: Bennet Yee <bsy@play.mach.cs.cmu.edu> Subject: Re: Process restart. Date: 13 Nov 88 01:14:58 GMT Keywords: Fork, Process, migration, remote, a.out, core To: unix-wizards@sem.brl.mil In article <18@elgar.UUCP> ag@elgar.UUCP (Keith Gabryelski) writes: > >Long running processes that don't have any means of shutdown/restart >built into them are what I am thinking of. > >Let's say we have this process computing prime numbers (or some other >simple case) and the system needs to be shutdown because of some fatal >error. Can a snapshot be done? I've done exactly this about two years ago. My implementation of M.O.Rabin's probabilistic primality test ran for about a week of real time on a uVax II surviving multiple reboots/system crashes before finding a 1000 digit probabilistic prime.... I don't know how much real CPU time it took -- the machine was a general purpose machine (I ran my program niced 19) and I didn't keep track of timing info. In retrospect it would have been easy: I had it checkpoint every 5 minutes of CPU time anyway, so all I needed to do is to increment a counter. Anyway, since the program's I/O behavior is very simple (it generated output only just before completing, and I only redirected its stdout to a file), it was particularly simple to checkpoint the process. I thought about the case of replacing open/close with library routines and syscall'ing the traps after saving state; at a checkpoint, we can lstat the known descriptors so we can restore. This would work only for files, of course, and I didn't bother. I may do this at a later date.... The code that I _do_ have simply checkpoints the data/stack portion of the address space. Note that this includes the stdio buffers etc, so if I _did_ decide to save file descriptor states all I need to do at restart is to lseek to the old location... assuming the program doesn't lseek around also. If it did, I'd have to copy all the files to get _their_ state at the time of the checkpoint (bleh). Restart is performed by running the program with a switch specifying the checkpoint file, whereupon the state from the file is loaded into the current address space (i.e, your program would have to recognize a flag and call my restore function). I have versions of this code running on Vaxen and IBM RTs. I currently have 3 1000 digit probabilistic primes. Does any factoring wizard want a 2000 digit compos... :-) To generate 100 digit probabilistic primes (probability 1 - 2^-40), it takes 129.3u 0.7s 2:28 87% on an IBM RT/APC and 290.2u 0.1s 8:49 54% on a uVax III. The primality code uses the cmump library package developed here at CMU (cmump is based on the mp package from BTL), so probably won't be useful unless you have source license or you're willing to rewrite it. As for the checkpointing code, I'm willing [and able] to share. I only use Unix syscalls and the code should have no Mach dependencies. -bsy -- Internet: bsy@cs.cmu.edu Bitnet: bsy%cs.cmu.edu%smtp@interbit CSnet: bsy%cs.cmu.edu@relay.cs.net Uucp: ...!seismo!cs.cmu.edu!bsy USPS: Bennet Yee, CS Dept, CMU, Pittsburgh, PA 15213-3890 Voice: (412) 268-7571 -- ----------------------------- From: "Ross M. Greenberg" <root@utoday.uucp> Subject: Re: The Internet Virus--A Commentary Date: 12 Nov 88 18:25:57 GMT To: unix-wizards@sem.brl.mil Perhaps a class in ethics over the next few years might show how many users of the net were adversely affected by this worm attack, and how doing such a thing (affecting so many people without their permission) might be something called "unethical"? Perhaps just using RTM (if, indeed, he was the bad guy) as an example of what happens to a person when they lack ethics? Ross M. Greenberg {my own views} ----------------------------- From: Paul Vixie <vixie@decwrl.dec.com> Subject: Re: Crackers and Worms Date: 13 Nov 88 03:42:43 GMT Keywords: bug reality To: unix-wizards@sem.brl.mil In article <3380@emory.uucp> arnold@emory.UUCP (Arnold D. Robbins {EUCC}) writes: # In article <44440@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: # >I have not been able to find ONE person who claims to # >have known that sendmail compiled with DEBUG on would have allowed # >anyone with SMTP access to run an arbitrary program on their machine. # # Didn't Paul Vixie say he knew it? If not, I apologize in advance. Yes, Paul Vixie did indeed say that he knew it. Rick Adams and I exchanged some mail about this, and he pointed out basically that if I knew this was possible but didn't recognize it as a security hole, the knowledge was pretty much useless. At the time I was first digging into sendmail, some time in 1986, I was not at all sure what it was all for, what it all meant, and whether I understood any single part of it. (This seems normal among sendmail proto-hackers :-)). When I discovered all the various functional changes you could make in debug mode, I assumed that there was a good reason for all of them and I dutifully ported and patched and debugged the complete program, with all holes intact. Even when I found what I thought was a bug, I tried very hard to re-understand intention and implementation, on the constant assumption that it was supposed to be the way it was, all details included. I know better today, of course. If I had had occasion to poke into sendmail three weeks ago and notice that if (a->q_alias == NULL && !tTd(0, 1) && !QueueRun && !ForceMail) ^^^^^^^^^^^^^ in recipient() in recipient.c, you may safely bet you a** that I'd send off some mail to Berkeley. I now feel (somewhat arrogantly, I'm sure!) that I know what's intended in 90% of the sendmail code. This points up an interesting dynamic of publicly available source code. If the only people who are studying it carefully are those still wet behind their ears, and these people lack the overall knowledge and confidence to question what they see, we may all be in a heap of trouble. I hope we'll all learn to be a little bit nicer to the next person who asks a "stupid" question... -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013 ----------------------------- From: David Collier-Brown <daveb@geaclib.uucp> Subject: Re: Bigger process IDs and "dev_t"s (was: Re: RISC v. CISC...) Date: 12 Nov 88 02:44:32 GMT To: unix-wizards@sem.brl.mil From article <422@auspex.UUCP>, by guy@auspex.UUCP (Guy Harris): [ re major/minor numbers] |>correct me if i'm wrong, but isn't the <major, minor> manufactured |>by the client? <255, index-in-mnttab>? | | The "st_dev" is manufactured by the client, in the fashion you indicate | (more-or-less - I think it may be different in 4.0 so that multiple | distributed file systems can be supported); however, the "st_rdev", | which is what we're talking about, isn't manufactured by the client - | major/minors for special files living on a server are interpreted in the | same way as if they were local to the client (literally - the "specfs" | code handles special files, regardless of whether the special file is | gotten locally or over NFS). That sounds suspiciously like someone forgot that the mapping was going to be many-to-many and let it be one-to-one for the st_rdev. --dave c-b Any problem in computer science can be solved by using one more level of indirection -- attributed to Morven Gentleman, Waterloo. -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | HE's so smart he's dumb. Mississauga, Ontario | --Joyce C-B ----------------------------- End of UNIX-WIZARDS Digest **************************