jack@cwi.nl (Jack Jansen) (11/16/88)
I think there's another side to the internet virus story that hasn't been mentioned yet: what do the manufacturers do. When a serious defect in a car is found the manufacturer usually calls all cars with the defect back and repairs them for free. So far, only Sun has done something similar by posting instructions on patching sendmail and a replacement for fingerd to the net (and, I assume that they'll also snail-mail it to the poor customers without net access). Applause, but where are the others? Even though only vaxen and suns have been affected by this virus, it is trivial now to write a virus that will also exploit the bug on any other system. Yet another issue, of course, is why sun compiled the distribution sendmail with the WIZ option in the first place. -- Fight war, not wars | Jack Jansen, jack@cwi.nl Destroy power, not people! -- Crass | (or mcvax!jack)
rick@seismo.CSS.GOV (Rick Adams) (11/17/88)
Sequent sent paper mail to all customers on November 8 giving instructions how to binary patch their sendmail and giving an 800 number to call if they didn't understand the patch. (and the "virus" didn't even run on Sequents) ---rick
jbn@glacier.STANFORD.EDU (John B. Nagle) (11/17/88)
In article <7715@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: > >When a serious defect in a car is found the manufacturer usually calls >all cars with the defect back and repairs them for free. Federal law requires this. Under heavy pressure from Ralph Nader, Congress, during the 1960s, required mandatory recalls for safety-related defects and for certain other problems. The manufacturers often initiate "voluntary" recalls as well, but this is to head off action by the Department of Transportation. Interestingly, the manufacturers are not required to inform vehicle owners of the recall; they can let the Government do that. However, if the manufacturer lets DOT send out the notice, it will, as required by the law, contain rather negative language (along the lines of "The United States Government Department of Transportation has determined that a serious safety defect exists in your car..."), so manufacturers usually prefer to inform customers themselves. The day may come when we see such legislation for computers. John Nagle
borynec@bnr-di.UUCP (James Borynec) (11/18/88)
It seems to me that everybody is assuming that the major security threat is some cracker deciding to show off his ego? I think that there are other, probably greater, risks at hand. Firstly, there is industrial espionage: We only hear about the 16 year old kids who attack the net with blunt instruments. Does anybody know anything about the incidence of industrial espionage (possibly by (gasp!) foreign nationals). I would guess that if they are at all professional they would likely not be caught for many a year. A second danger is a modern version of Arson. What if some unsavory character decided that life would be much more profitable if his chief competitor's computers were (figuratively) burnt to the ground. The chances of not being caught are pretty high. I think that the major reason that these things haven't happened all much in the past is because of the relative scarcity of expertise. This is changing FAST! Good ol Obnoxious has a point - We must take action NOW to prevent Billions of dollars in damage in the future. James Borynec utgpu!bnr-vpa!bnr-di!borynec Bell Northern Research borynec@bnr.ca.bitnet
trn@aplcomm.jhuapl.edu (Tony Nardo) (11/18/88)
In article <7715@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >So far, only Sun has done something similar by posting instructions >on patching sendmail and a replacement for fingerd to the net (and, >I assume that they'll also snail-mail it to the poor customers >without net access). Applause, but where are the others? And this was a half-measure. SUN's code to fix another 'finger' bug is, I am told, "in the system", but has yet to be released to the public. Also, was it SUN that released the patched ftpd sources? I'm not sure, but I don't think so. I don't wish to pick on SUN alone. It would sure be nice if vendors could maintain a system on the network, reachable via anonymous ftp, containing the patched sources/objects/binaries for bugs found in their operating systems. Granted, this wouldn't guarantee 100% coverage for distribution of patches, but it would be an awfully good start. ============================================================================== ARPA, BITNET: trn@aplcomm.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn DISCLAIMER: These are my opinions, and not necessarily those of JHU/APL. ==============================================================================
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/20/88)
In article <17849@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: In article <7715@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: When a serious defect in a car is found the manufacturer usually calls all cars with the defect back and repairs them for free. Federal law requires this. Under heavy pressure from Ralph Nader, Congress, during the 1960s, required mandatory recalls for safety-related defects and for certain other problems. The manufacturers often initiate "voluntary" recalls as well, but this is to head off action by the Department of Transportation. Interestingly, the manufacturers are not required to inform vehicle owners of the recall; they can let the Government do that. The day may come when we see such legislation for computers. There are major problems with software bug fixes and recalls. The main difference between software and computers on one hand and cars on the other is that someone knows exactly who owns each car by serial number. That is the DMV has a list. In theory a list of all defective vehicles could be supplied and somewhat later a mailing list returned by each of the 54 DMV's. [54 you say? Yes 50 states, DC, PR, VI and Guam. I ignore CZ and non-US jurisdictions.] Of course most car manuafacturers keep their own private list [also good for sending mail on new models, etc.] Consider computers. These days the computer is sold by a distributor or a Value Added Reseller (VAR) or by your local computer shop. The manufacturer probably doesn't have a foggiest idea who has it. Similarly for the software -- its sold in shrink wrapped packages at the 7-11 these days [honest injun!]. And even if they could track the original purchase, do they track re-sold computers and software? Thus the value of the "warranty registration" cards appliance manufacuturers have. Of course most software warranties are "if the floppies are bad we'll send a new set". Hence the reason major vendors offer support for their products at a fee. But how many PC or even UNIX(R) owners pay for support? -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
henry@utzoo.uucp (Henry Spencer) (11/20/88)
In article <2490@aplcomm.jhuapl.edu> trn@aplcomm.jhuapl.edu (Tony Nardo) writes: >I don't wish to pick on SUN alone. It would sure be nice if vendors could >maintain a system on the network, reachable via anonymous ftp, containing >the patched sources/objects/binaries for bugs found in their operating >systems... There would be some small licensing problems with this, given that not everybody on the network is licensed for the same stuff. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/23/88)
In article <7715@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: >Yet another issue, of course, is why sun compiled the distribution sendmail >with the WIZ option in the first place. Because, unfortunately, there is no "WIZ" option. There are about a hundred different options all covered by the -DDEBUG defined variable, in the C source. 98% of these are useful, and I have wished that DEC compiled them into the versions of Ultrix I have used (they don't - no bugs (see their manual entries!), so no need for -DEBUG). The other 2% are potential problems, some of which can be eliminated by replacing such pseudo-keywords as "debug", "shell", and "wiz" with "noop" or something similar in your binaries. Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM} arinc,att,avatar,blkcat,cos,decuac,dtix,\ ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy kcwc,lepton,netex,netxcom,phw5,rlgvax, / seismo,sms,smsdpg,sundc,uunet /
brian@apollo.COM (Brian Holt) (11/23/88)
In article <1988Nov19.235026.29419@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2490@aplcomm.jhuapl.edu> trn@aplcomm.jhuapl.edu (Tony Nardo) writes: >>I don't wish to pick on SUN alone. It would sure be nice if vendors could >>maintain a system on the network, reachable via anonymous ftp, containing >>the patched sources/objects/binaries for bugs found in their operating >>systems... > >There would be some small licensing problems with this, given that not >everybody on the network is licensed for the same stuff. >-- >Sendmail is a bug, | Henry Spencer at U of Toronto Zoology >not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Not to mention that most of the vendors are on the DARPA Internet portion of the internet, which explicitly disallows commercial use except for the support of Defense Advanced Research Projects or DoD contracts. Those that aren't directly on the DARPA section are on a connected network (such as NSFnet) which has agreed to abide by DARPA's rules. An argument could be made that providing patched sources/objects/binaries via anonymous ftp is in support of DoD contracts, but I suspect most vendors aren't willing to push that fine gray line too far. I'm not a lawyer, and I don't even play one on TV, so don't quote me on any of this. =brian -- Internet: brian@apollo.COM UUCP: {decvax,mit-erl,yale}!apollo!brian NETel: Apollo: 508-256-6600 x5694 Home: 617-332-3073 FISA: 617-964-8938 USPS: Apollo Computer, Chelmsford MA Home: 29 Trowbridge St. Newton MA (Copyright 1988 by author. All rights reserved. Free redistribution allowed.)
marcel@hpindda.HP.COM (Marcel Burlet) (11/24/88)
/ kai@uicsrd.csrd.uiuc.edu / 8:44 pm Nov 17, 1988 / >(Some) other manufacturers are doing something about it. >Sequent mailed a shell script to patch sendmail to disable debug. >Alliant did one better. They have debug disabled in the sendmail they >distribute. HP also has debug disabled in the distribution. (Guess when I found this out. Right, *after* getting the scare of my life !) >Patrick Wolfe (pwolfe@kai.com, uunet!kailand!pwolfe) Marcel ************************************************************************** * Marcel Burlet | {ucbvax,hplabs}!hpda!hpindlm!marcel [UUCP] * * Information Net. Div(IND) | marcel%hpda@hplabs.HP.COM [INTERNET] * * Hewlett-Packard Co. | (408) 447-2503 [AT&T] * * 19420 Homestead Road,43LN | 1-447-2503 [HP-TELNET] * * Cupertino, CA 95014 USA | "What If..." [HP-TELEPATHY] * **************************************************************************
mak@ndc.UUCP (Mike Klaus) (11/30/88)
Today's Score: Crossover 1 LineEater 0 And, if you have an unauthorized copy of jay's mailer, it'll crash @ *the end* of the previous line. Who says that software can't be reposessed? mak BTW, to all those that have fingered my new password, it's poison.
dan@ccnysci.UUCP (Dan Schlitt) (11/30/88)
In article <4470010@hpindda.HP.COM> marcel@hpindda.HP.COM (Marcel Burlet) writes:
:/ kai@uicsrd.csrd.uiuc.edu / 8:44 pm Nov 17, 1988 /
:>(Some) other manufacturers are doing something about it.
:>Sequent mailed a shell script to patch sendmail to disable debug.
:>Alliant did one better. They have debug disabled in the sendmail they
:>distribute.
:
:HP also has debug disabled in the distribution. (Guess when I found this
:out. Right, *after* getting the scare of my life !)
:
I'm still waiting for Celerity's new parent to do something.
But there is really more to this than sendmail debug. After a bit of
fussing I got adb to fix sendmail on the Celerity. I haven't seen a
method for using adb to fix fingerd and ftpd. They need fixing too.
Before patting too many vendors on the back for fixing things (or
distributing safe versions) let's see them fix the harder problems.
--
Dan Schlitt Manager, Science Division Computer Facility
dan@ccnysci City College of New York
dan@ccnysci.bitnet New York, NY 10031
(212)690-6868
gandalf@csli.STANFORD.EDU (Juergen Wagner) (12/01/88)
In article <1026@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes: >... >But there is really more to this than sendmail debug. After a bit of >fussing I got adb to fix sendmail on the Celerity. I haven't seen a >method for using adb to fix fingerd and ftpd. >... Fixing ftpd and fingerd happens by replacement! There were postings in comp.bugs.4bsd.ucb-fixes and other newsgroups. ftpd needs three little changes to run under Ultrix, too. And if you're installing fingerd as setuid/setgid to nobody/nobody, you're pretty safe with these two guys, I think. -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
cudcv@warwick.ac.uk (Rob McMahon) (12/11/88)
In article <6624@csli.STANFORD.EDU> wagenr@arisia.xerox.com (Juergen Wagner) writes: >And if you're installing fingerd as setuid/setgid to nobody/nobody, you're >pretty safe with these two guys, I think. If you're using NFS where some remote accesses get done as nobody, I should think hard about this, since your setuid program could be replaced by anything, which will probably get run as root. You should be okay if you trust root on all the systems you export the filesystem to, but the idea of nobody is that it has no privileges, and this seems to be breaking that idea. If you've got an inetd.conf that takes a user to run the daemon as, I would also be careful about using users with -ve uids, someone said this can cause the daemon to get run as root when e.g. setuid(-2) fails (setuid expecting a 0 <= number < 2^16). Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
guy@auspex.UUCP (Guy Harris) (12/15/88)
>If you've got an inetd.conf that takes a user to run the daemon as, I would >also be careful about using users with -ve uids, someone said this can cause >the daemon to get run as root when e.g. setuid(-2) fails (setuid expecting a >0 <= number < 2^16). It seems to work under SunOS 4.0; the "pw_uid" field for the user is cast to "uid_t", which is "unsigned short", the net result being that it passes 65534 rather than -2 to "setuid". You do get some crap from "/usr/etc/sa" when it's run by "cron", but you can filter that out by changing the "crontab" line to 15 0 * * * /usr/etc/sa -s 2>&1 >/dev/null | egrep -v '^Preposterous user id, 65534: ignored$' (NOTE: the line is split because it's long - I don't think "cron" supports that sort of stuff, so don't enter it like that; join those two lines into one). A future release will probably join the rest of the world and make UIDs unsigned, so that "nobody" will become 65534.
cudcv@warwick.ac.uk (Rob McMahon) (12/18/88)
In article <66@titania.warwick.ac.uk> I wrote: >>If you've got an inetd.conf that takes a user to run the daemon as, I would >>also be careful about using users with -ve uids, someone said this can cause >>the daemon to get run as root when e.g. setuid(-2) fails (setuid expecting a >>0 <= number < 2^16). In article <716@auspex.UUCP> guy@auspex.UUCP (Guy Harris) replies: >It seems to work under SunOS 4.0; the "pw_uid" field for the user is cast to >"uid_t", which is "unsigned short", the net result being that it passes 65534 >rather than -2 to "setuid". Humble apologies. I really should have checked this out, because it seems to be safe in 4.3 too. Make sure you have unusable passwords on your -ve uid accounts though, because the pw_uid in a struct passwd is an int, and at least under 4.3 login neither casts it to uid_t nor checks the return from setuid. I believe this was fixed in SunOS 4.0.1. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England