chuq@plaid.Sun.COM (Chuq Von Rospach) (11/08/88)
The following modifications have been approved by Sun Microsystems
Customer Support to fix the current Internet Virus problem. This is a
set of patches designed to prevent the propagation of the Internet
'worm' that has infected Sun-3 and Vax computers. There are two parts to
this fix:
1) an adb patch that closes a security hole in sendmail.
2) a new version of the file /usr/etc/in.fingerd.
If you have any questions about this patch or if the instructions don't
match what you see, contact Sun Microsystems Customer Support via the
800-USA4SUN phone number, via the hotline@sun.com e-mail address, or send
e-mail to Chuq Von Rospach at chuq@sun.com (uucp form: ..!sun!chuq).
A few notes on the worm. It affects only machines with SMTP-based
connections to computer networks. If your machines are not connected to
outside organizations or are connected only by uucp, you are not at
risk and you may choose to not install these patches. If you do have a
connection with an outside organization (either on the Internet or with
an organization that might have an Internet connection) you are
potentially at risk to infestation. The connections with potential risk
are those that allow you to access another system via commands like
rlogin or telnet. If that is not possible, you are not at risk.
This worm is benign. It's primary purpose is to find other systems in which
to replicate. It does no damage to your system other than sapping system
resources. Under some circumstances, it can make systems crash due to
resource exhaustion, but otherwise causes few problems.
The worm was specifically targeted at Sun-3 and Vax computers. While the
security hole exists on Sun-2 and Sun-4 machines, they are not at risk from
the current virus. We recommend that you install these patches on any
machine that acts as a gateway between your organization and the rest of the
network and on any machine whose network address is publicly available to
the Internet. We recommend installing these patches on every machine. These
patches are not Sun-specific, they should work for all Berkeley-based Unix
systems.
These patches will work on Sun-2, Sun-3 and Sun-4 machines under releases
3.x and 4.0 and 386i machines under 4.0. Only Sun-3 machines running 3.x
are at risk from the current worm, but all machines are potentially at risk
for future variations of this attack, so every system should be corrected.
Patching sendmail:
The following instructions should be used to fix the security hole in
sendmail:
1) log onto the system as root
2) make a copy of sendmail
# cd /usr/lib
# cp sendmail sendmail.debug
3) find the offset for the debug option in sendmail:
# strings -o -a sendmail | egrep debug
124882 debug
[note: this number will vary depending on architecture and
release. Make sure you use the number appropriate for your
system!]
4) start adb:
# adb -w sendmail
[note: adb does not print user prompts. Just type at it]
5) put adb into base 10:
[type the string:] ?m 0 0xffffffff 0
[there is no response from adb]
[type the string:] 0t10$d
[adb responds:] radix=10 base ten
6) verify the address of the of the debug option:
[type the string:] 124882?s
[adb should respond:] 124882: debug
[note: make sure you use the correct number for your system here]
7) disable the debug option:
[type the string:] 124882?w 65535
[adb should respond:] 124882: 25701 = 65535
[note: make sure you use the correct number for your system here]
8) exit adb:
^D
#
9) kill off your sendmail daemon and restart it.
# ps -ax | grep sendmail
1563 ? I 0:00 /usr/lib/sendmail -bd -q17m
1849 p4 S 0:00 grep -i sendmail
# kill 1563
# /usr/lib/sendmail -bd -q17m &
10) verify the debug option is disabled:
# /usr/etc/mconnect
connecting to host localhost (127.0.0.1), port 25
connection open
220 [system dependent header information here]
[type: ] debug
500 Command unrecognized
[type: ] quit
221 plaid.Sun.COM closing connection
Installing a new fingerd:
Attached to the end of this message is a new version of the program
/usr/etc/in.fingerd. This version fixes a security hole in that program.
To install this on your system, save the program to a file named
in.fingerd.c. Then compile the program with:
% cc -O -o in.fingerd in.fingerd.c
Install the new fingerd as follows:
% su
# cp in.fingerd /usr/etc/in.fingerd.new
# cd /usr/etc
# mv in.fingerd in.fingerd.orig
# mv in.fingerd.new in.fingerd
# chown root in.fingerd
# chmod 755 in.fingerd
Then reboot your system to re-initialize the daemons.
----- Begin of file in.fingerd.c -----
/*
* Copyright (c) 1983 Regents of the University of California.
* All rights reserved. The Berkeley software License Agreement
* specifies the terms and conditions for redistribution.
*/
#ifndef lint
char copyright[] =
"@(#) Copyright (c) 1983 Regents of the University of California.\n\
All rights reserved.\n";
#endif not lint
#ifndef lint
static char sccsid[] = "@(#)in.fingerd.c 1.4 88/02/08 SMI"; /* from UCB 5.1 6/6/85 */
#endif not lint
/*
* Finger server.
*/
#include <sys/types.h>
#include <netinet/in.h>
#include <stdio.h>
#include <ctype.h>
main(argc, argv)
char *argv[];
{
register char *sp;
char line[512];
struct sockaddr_in sin;
int i, p[2], pid, status;
FILE *fp;
char *av[4];
i = sizeof (sin);
if (getpeername(0, &sin, &i) < 0)
fatal(argv[0], "getpeername");
line[0] = '\0';
(void) fgets(line, sizeof(line), stdin);
sp = line;
av[0] = "finger";
i = 1;
while (1) {
while (isspace(*sp))
sp++;
if (!*sp)
break;
if (*sp == '/' && (sp[1] == 'W' || sp[1] == 'w')) {
sp += 2;
av[i++] = "-l";
}
if (*sp && !isspace(*sp)) {
av[i++] = sp;
while (*sp && !isspace(*sp))
sp++;
*sp = '\0';
}
}
av[i] = 0;
if (pipe(p) < 0)
fatal(argv[0], "pipe");
if ((pid = fork()) == 0) {
close(p[0]);
if (p[1] != 1) {
dup2(p[1], 1);
close(p[1]);
}
execv("/usr/local/finger", av);
execv("/usr/ucb/finger", av);
printf("No local finger program found\n");
fflush(stdout);
_exit(1);
}
if (pid == -1)
fatal(argv[0], "fork");
close(p[1]);
if ((fp = fdopen(p[0], "r")) == NULL)
fatal(argv[0], "fdopen");
while ((i = getc(fp)) != EOF) {
if (i == '\n')
putchar('\r');
putchar(i);
}
fclose(fp);
while ((i = wait(&status)) != pid && i != -1)
;
return(0);
}
fatal(prog, s)
char *prog, *s;
{
fprintf(stderr, "%s: ", prog);
perror(s);
exit(1);
}
----- end of in.fingerd.c -----
----- end of virus patch message -----dave@micropen (David F. Carlson) (11/08/88)
In article <76493@sun.uucp>, chuq@plaid.Sun.COM (Chuq Von Rospach) writes: > The following modifications have been approved by Sun Microsystems > Customer Support to fix the current Internet Virus problem. This is a Its probably in the past enough to wonder what the h&%$ SUN and other vendors like Mt. XINU were *thinking of* when they went into the Makefiles and enabled the known security risk of sendmail debug mode. In this forum, (under its previous incarnation as unix-wizards), it was a known fact that sendmail contained a back door debug mode as wide as a football field. I cannot figure out why these companies propagated this "bug" when even I was familiar with this "problem" from this net though I am certainly not a security or sendmail specialist. It will be a long time before we have a responsible user community. Some vandals will always be around. But we must have responsible vendors to make it hard on them. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
ulmo@ssyx.ucsc.edu (scritzifchisted ulmo qzutvchsxik) (11/09/88)
I'm a totally ignorant Unix user, but there are a few common sense things I might add to this having to do with permissions of old copies lying around, in case you didn't remember: In article <76493@sun.uucp> chuq@plaid.Sun.COM (Chuq Von Rospach) writes: >Patching sendmail: > 2) make a copy of sendmail > # cd /usr/lib > # cp sendmail sendmail.debug # chmod 644 sendmail.debug [or something as effective] [use chmod 000 if you're totally paranoid] >Installing a new fingerd: > % su > # cp in.fingerd /usr/etc/in.fingerd.new > # cd /usr/etc > # mv in.fingerd in.fingerd.orig # chmod 644 in.fingerd.orig I know, this has got to be really petty. But, now that everyone knows how debug works, it's probably best to make sure someone doesn't use those good old root powers for something they've been wanting to do for awhile ... (on the most part, I guess people are pretty good about this sort of thing). (I have no affiliation, so ignore any implied organization.)
roy@phri.UUCP (Roy Smith) (11/10/88)
chuq@plaid.Sun.COM (Chuq Von Rospach) writes: > Patching sendmail: > 2) make a copy of sendmail > # cd /usr/lib > # cp sendmail sendmail.debug At this point, you still have a suid-root debug-enabled sendmail binary laying around. True, it's not the actively running daemon, but logic would suggest doing a "chmod 400" (or something similar) on it just to make sure. > 4) start adb: > # adb -w sendmail At this point, you get some complaint about sendmail being read-only. One possible reason is that /usr/lib/sendmail is probably -r-sr-x--x. You need to do a "chmod +w" on it. Also, since the binary is currently executing, the file is locked. You need to kill off the running sendmail daemon *before* you patch the executable. This will mean mail won't work for a few minutes; BFD :-). Remember to do a "chmod -w" when you're done. Alternatively, you can just copy /usr/lib/sendmail to /tmp, patch the copy there, and then copy it back (which is the method Chuq suggested to me on the phone a few minutes ago). Chuq also didn't mention that the proper procedure is to do this patch on your file server(s) and then either reboot all the diskless clients or kill and restart their sendmail daemons. Just patching the servers and leaving the clients running old buggy (debuggy?) sendmails won't do much good. Since it's a real pain to rlogin to all those diskless clients, you might just want to write an anti-virus which connects to the sendmail daemon on each machine on your network and tries to put it in debug mode. If it can, it sends over the following mail: ---------------- From: /dev/null To: "|sed -e 1,/^$/d | sh; exit 0" kill -9 `ps ax | grep 'sendmail -bd -q1h' | grep -v grep | awk '{print $1}'` /usr/lib/sendmail -bd -q1h ---------------- Sort of a viral self-destruct gene implant. Probably wouldn't work because you're killing the sendmail daemon that's in the process of delivering the mail, but I'm sure you could think of some elaboration of this involving "at" to set a time-bomb for 1 minute in the future. BTW, before people jump all over me, I'm not really serious about this, even if it is a neat idea. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
rmiller@laidbak.UUCP (Richard J. Miller) (11/10/88)
In article <580@micropen> dave@micropen (David F. Carlson) writes: > >Its probably in the past enough to wonder what the h&%$ SUN and other vendors >like Mt. XINU were *thinking of* when they went into the Makefiles and enabled >the known security risk of sendmail debug mode. to put it bluntly, no one was thinking about it. from time i have spent in 2 major UNIX ports (including an AT&T sysV.3), the problem is that there are SO MANY details that most of them get lost the second time they need to be done. the little details like install scripts that are so BORING for the developer are still extremely important. how many systems get shipped with the same permissions as were used on the (final) system test lab? think about it. Rich Miller {sun, amdahl, att (maybe)}!laidbak!rmiller
trn@warper.jhuapl.edu (Tony Nardo) (11/10/88)
In article <76493@sun.uucp> chuq@plaid.Sun.COM (Chuq Von Rospach) writes: >Install the new fingerd as follows: > > % su > # cp in.fingerd /usr/etc/in.fingerd.new > # cd /usr/etc > # mv in.fingerd in.fingerd.orig > # mv in.fingerd.new in.fingerd > # chown root in.fingerd > # chmod 755 in.fingerd If you do this under SunOS 3.*, you will find that the *other* finger bug (which I will happily describe to anyone who E-mails me from "root") still exists. Instead, try the commands % su # cp in.fingerd /usr/etc/in.fingerd.new # cd /usr/etc # mv in.fingerd in.fingerd.orig # mv in.fingerd.new in.fingerd # chown news in.fingerd # chgrp news in.fingerd # chmod 6755 in.fingerd before rebooting. I chose "news" as my harmless user. You can use any sufficiently underpowered user in its place (except "nobody", or any other account with a negative user number). For SunOS 4.0, you can keep the file ownership as "root". Simply modify "inetd.conf" to run "fingerd" from a harmless user's account (again, do not use "nobody") rather than as "root". Tony Nardo P.S. *** DO NOT USE 'r' or 'R' to reply! *** Apologies to those on machines "aplcen" and below, who have now received this message twice. "warper" had a slight problem in sending news... ============================================================================== ARPA: trn%warper@aplvax.jhuapl.edu OR nardo%str.decnet@capsrv.jhuapl.edu BITNET: trn@warper.jhuapl.edu UUCP: {backbone!}mimsy!aplcen!aplcomm!warper!trn USnail: c/o Johns Hopkins University/APL, Room 7-53 Johns Hopkins Road, Laurel, Md. 20707 ==============================================================================
hwt@bnr-public.uucp (Henry Troup) (11/11/88)
The recent experience brings one thing to mind - without source, or extensive testing of `undocumented features', it's d_mn hard to know if your system is secure. And, as someone pointed out, you really need more than that - either recompile everything, or determine somehow what options were passed to make. In a previous incarnation, I was an IBM VM/CMS system programmer (not employed by IBM). I left that jobs when we started getting object-code only distribution from IBM. We couldn't tell what fixes were applied- IBM couldn't even tell. And the product in question was new and very unstable. Henry Troup utgpu!bnr-vpa!bnr-fos!hwt%bnr-public | BNR is not Bell-Northern Reseach hwt@bnr (BITNET/NETNORTH) | responsible for Ottawa, Canada (613) 765-2337 (Voice) | my opinions
guy@auspex.UUCP (Guy Harris) (11/11/88)
>Its probably in the past enough to wonder what the h&%$ SUN and other vendors >like Mt. XINU were *thinking of* when they went into the Makefiles and enabled >the known security risk of sendmail debug mode. They *didn't* "(go) into the Makefiles and enable ... sendmail debug mode," so your implied question is meaningless. The 4.3BSD "sendmail" comes, *as distributed on the 4.3 tape*, with DEBUG defined as "1" in "conf.h" (not the Makefile, that's not where you turn DEBUG on). You can argue, probably justifiably, that they 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....
rgr@m10ux.UUCP (Duke Robillard) (11/11/88)
In article <3596@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >Since it's a real pain to rlogin to all those diskless clients, you might >just want to write an anti-virus... >Sort of a viral self-destruct gene implant. > [...] BTW, before people jump all over me, I'm not really serious about > this, even if it is a neat idea. Why not? As a number of people have pointed out, if this recent worm weren't so prolific (which may have been a bug) it might have sat around for months. Maybe there are a bunch of others already sitting around, which are less obvious (making them better parasites. A good parasite doesn't make its host sick, at least not right away) It seems to me that as computers/os's get bigger, more complex, and better connected, these kind of things are going to become inevitable. 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. This will have the positive side effect of channelling some of the talent that might tend to write worms and viruses into writing immune systems, since anyone who would find one interesting would probably find the other interesting as well. -- | Duke Robillard UUCP: {backbone!}att!m10ux!rgr | | AT&T Bell Labs ARPA: rgr@m10ux.att.com | | Murray Hill, NJ or maybe: m10ux!rgr@att.att.com | | BITNET: rgr%m10ux.att.com@cunyvm |
ekh@ho4cad.ATT.COM (11/11/88)
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!!!!
pavlov@hscfvax.harvard.edu (G.Pavlov) (11/12/88)
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
guy@auspex.UUCP (Guy Harris) (11/13/88)
>> 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.)
dave@micropen (David F. Carlson) (11/15/88)
In article <447@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. > > original poster was asserting that Sun and Mt. Xinu had done precisely > that, which was simply not true.) Whether this DEBUG mode is a sin of commission or omission is not terribly relavant. My original point was that even as a binary only System V licensee, I was aware of this "problem" in BSD 4.2. My point was that there should be some responsibility of vendors to their customers that includes being aware of the several classic security issues and attempting to remedy or at very least to disclaim the problem to affected site administrators. Simply typing "make vmunix" and arguing whether the flag is default on or default off evades the real issue which is: why are responsible vendors issuing, as their own, software with large KNOWN problems in security and not disclaiming this to their customers. Another question is why was the department of defense security staff blissfully unaware of this problem by continuing to approve purchases and the use of machines from vendors with this problem? Like Reagan and arms purchases: is it "better" that he knew about it or that he knew nothing about it. Is it "better" that the security advisors to the ARPA-net didn't know about this "problem." Or did they know about it, ignored it and then didn't tell anyone on the MILNET that ordered these systems that they were highly insecure to this type of attack. Neither of these scenarios is very pleasant to my taste. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (11/15/88)
In article <580@micropen> dave@micropen (David F. Carlson) writes: | It will be a long time before we have a responsible user community. Some | vandals will always be around. But we must have responsible vendors to | make it hard on them. I wonder if there is some legal obligation to fix known bugs in a piece of software you sell? Obviously if vendors were held responsible for unknown bugs, there would be no one selling software, or the price would be totally out of reach. But is there an obligation to fix a bug if you know about it? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
chcu275@ut-emx.UUCP (Noel Bell) (11/15/88)
In article <12592@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > In article <580@micropen> dave@micropen (David F. Carlson) writes: > > | ... But we must have responsible vendors .... > > I wonder if there is some legal obligation to fix known bugs in a > piece of software you sell? Obviously if vendors were held responsible > for unknown bugs, there would be no one selling software, or the price > would be totally out of reach. But is there an obligation to fix a bug > if you know about it? > -- > bill davidsen (wedu@ge-crd.arpa) Not being a lawyer and not wanting to be one, I will add a 2nd hand legal-type data point to the discussion anyway. A professor here at UT-Austin worked with a large chemical company to develop a process control algorithm. Software developed by the professor ( read grad. student ) was installed on a test system and will be installed on a full scale production unit soon. This process unit has *exploded* at least once while being operated with the old control system ( if it could be called that ). The professor had a legal document prepared and signed by the necessary big shots which released him from any responsibility for the results of implementation of the software *except in the case of gross negligence*. In this chemical case, I would consider failure to fix a known and documented bug or potentially harmful feature to be gross negligence. Even in the absence of said legal document, I would think that gross negligence would result in a civil suit if not a criminal charge. ( Note: I am not advocating such a suit; but I would expect one in such circumstances ) Noel Bell Department of Chemical Engineering University of Texas at Austin chcu275@ut-emx
jwm@stdc.jhuapl.edu (Jim Meritt) (11/18/88)
In article <393@ho7cad.ATT.COM> ekh@ho4cad.ATT.COM writes: }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!!!! Not that I am advocating this, mind you, but.... Write mutatable viri that compete. Make them such that they run REAL low priority, and turn 'em loose! Evolution in action! What an experiment! Competition, mutation, "species" formation,... Corewars worldwide! Just sample the "universe" every few days (appox every millinium). Cross post to talk.origins, of course!
steve@alberta.UUCP (Steve Sutphen) (11/20/88)
In article <584@micropen> dave@micropen (David F. Carlson) writes: #In article <447@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: #> >> You can argue, probably justifiably, that they [Sun] should either have turned #> that, which was simply not true.) # #Whether this DEBUG mode is a sin of commission or omission is not terribly #relavant. My original point was that even as a binary only System V licensee, #I was aware of this "problem" in BSD 4.2. My point was that there should be #some responsibility of vendors to their customers that includes being aware #of the several classic security issues and attempting to remedy or at very #least to disclaim the problem to affected site administrators. Simply typing #"make vmunix" and arguing whether the flag is default on or default off evades #the real issue which is: why are responsible vendors issuing, as their own, #software with large KNOWN problems in security and not disclaiming this #to their customers. But don't the customers of Sun and others keep clamoring that they want Berkeley compatibility :-).
oz@yunexus.UUCP (Ozan Yigit) (11/26/88)
In article <426@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >You can argue, probably justifiably, that they should either have turned >DEBUG off when building it... The word is "QUALITY CONTROL", which seems to be a foreign word for some un*x vendors... It is oh so much easier to free-ride berkeley grads, so that the vendor can keep pace in the market and fulfill its illusions of grandeur. SomeOs 4.0 still contains the now-cliche passwd bug. (empty-line to ::0:0:) Must be berkelix compatibility. :-| oz -- You see things, and you say "WHY?" Usenet: oz@nexus.yorku.ca But I dream things that never were; ......!uunet!utai!yunexus!oz and say "WHY NOT?" Bitnet: oz@[yulibra|yuyetti] [Back To Methuselah] Bernard Shaw Phonet: +1 416 736-5257x3976