Sun-Spots Digest, v7n18
William LeFebvre
Sun-Spots-Request at Rice.edu
Tue Nov 22 09:38:33 AEST 1988
SUN-SPOTS DIGEST Friday, 18 November 1988 Volume 7 : Issue 18
Today's Topics:
Official Sun-approved virus patch
Re: single user while dumping
Re: Wren V 94181 SCSI configuration
Re: Mail problems
Re: Remove booting on a Sun 3/290 -- failure!
Re: "filter to magnify bitmaps 2X"
Re: Opportunity for SEX at the SUG
Re: Bug in Gammontool
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Wed, 16 Nov 88 14:44:53 PST
From: chuq at sun.com (Chuq Von Rospach)
Subject: Official Sun-approved virus patch
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.
This is the second release of the patch, updated 11/16/88 to clean up
the sendmail instructions and strengthen the patch to sendmail based on
further feedback from Berkeley.
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 at sun.com e-mail address, or send
e-mail to Chuq Von Rospach at chuq at 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 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
# chown daemon sendmail.debug
# chmod 400 sendmail.debug
3) kill off your sendmail daemon.
# ps -ax | grep sendmail
1563 ? I 0:00 /usr/lib/sendmail -bd -q17m
1849 p4 S 0:00 grep -i sendmail
# kill 1563 [Note: process number will vary. Use the
value returned from ps]
4) find the offset for the debug and showq options in sendmail.
# strings -o -a sendmail | egrep debug
124882 debug
# strings -o -a sendmail | egrep showq
100508 showq
[note: this number will vary depending on architecture and
release. Make sure you use the number appropriate for your
system.]
5) start adb.
# adb -w sendmail
[adb does not print user prompts. Just type at it. Note: If adb
returns the message "warning: sendmail read-only" you didn't
kill the daemon and adb will not allow you to write into the
binary of a program that's active.]
6) 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
7) 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.
adb may respond with a hex address instead of a decimal address.
That's okay. Continue with the patch as long as the string
says 'debug']
8) disable the debug option.
[type the string:] 124882?w 65535 0
[adb should respond:] 124882: 25701 = 65535
124886: 25205 = 0
[note: make sure you use the correct number for your system here.
if adb responds with hex addresses, that's okay as long as the
values modified are 25701 to 65535 and 25205 to 0]
9) verify the address of the of the showq option.
[type the string:] 100508?s
[adb should respond:] 100508: showq
[note: make sure you use the correct number for your system here.
adb may respond with a hex address instead of a decimal address.
That's okay. Continue with the patch as long as the string
says 'showq']
10) disable the showq option.
[type the string:] 100508?w 65535 0
[adb should respond:] 100508: 29544 = 65535
124886: 28535 = 0
[note: make sure you use the correct number for your system here.
if adb responds with hex addresses, that's okay as long as the
values modified are 29544 to 65535 and 28535 to 0. What we have
done is disable both the 'debug' and 'showq' options in such a
way that anyone trying to use this security hole gets shunted
into the 'showq' function, which is harmless.]
11) exit adb:
^D
#
12) restart your sendmail daemon.
# /usr/lib/sendmail -bd -q17m
13) 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: ] showq
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 -----
------------------------------
Date: Wed, 9 Nov 88 8:34 GMT
From: Piete Brooks <pb%computer-lab.cambridge.ac.uk at nss.cs.ucl.ac.uk>
Subject: Re: single user while dumping
Reference: v7n9
> What is unclear to me at present is whether such files will or will not be
> picked up by subsequent level 1-9 dumps (if, for example, a user is editing
> a file during the level 0 dump session, and exits shortly after the dump
> ends)
dumps look for the last dump with a lower level number in /etc/dumpdates
and process all files with a modified date after the last relevant dump.
As the date in /etc/dumpdate is when dump STARTED processing the disc
partition, then I would assume that any edits during the dump would indeed
be candidates for dumping.
As I remember it, the problem about live systems was that it works
internally with inodes & that if an inode is re-used since the initial
scan, then the new data in the inode was dumped under the name that the
inode had at the time of the initial scan, rather than the new filename.
This meant that a restored file may have another file's data. [ sorry
about the odd use of tense in the above, but the problem may have been
fixed, hence the past tense in places ... ]
The other cases do not matter (I think)
Newly allocated inode: dump does not try to process the inode.
Deleted inode: dump may get confused, but ....
------------------------------
Date: Wed, 9 Nov 88 09:26:51 CST
From: nicmad!philbin%astroatc.UUCP at cs.wisc.edu (Bob Philbin)
Subject: Re: Wren V 94181 SCSI configuration
>Has anyone out there configured a Wren V 94181(702mb) disk on a Sun 3/60.
>If so, I would appreciate the cylinder/head/track information.
Here's what I used: 716+2/15/109. (716 data + 2 alt, 15 heads, 109
sec/trk). The Wren 5 (94181-702) actually has 1546 cylinders, 15 heads,
and a variable number of sectors/track - 50 or so, on the average. The
CDC documentation is annoyingly vague on this last point, as usual.
I initially formatted the drive on a Sun 3, using stand/diag. The above
fake geometry was arrived at by observing that the program would puke
trying to access block 1505/0/30 = 1173930 and above. Thus there are
1173930 = 2 * 3 * 5 * 109 * 359 available blocks. Take out 3 * 5 for the
heads and the remaining factors can be split up between the "number of
cylinders" and "sectors per track". Then reformat, partition and label it.
Once formatted this way, the drive works fine on the Sun 3 and Sun 386.
By "works fine", I mean you can use it and it's pretty fast. I don't know
that the BSD filesytem built on the drive is anything but pessimized to
some extent, but you get the same kind of problems with any embedded SCSI,
or other, drive that hides it's true geometry from the layer of software
that wants to know it.
OEM's, if not end users, should be able to get geometry information from
CDC. In my experience, this is tough. The CDC marketing folks don't know
much; they refer you to someone at the plant in Oklahoma who is supposed
to know. I think you would as likely get Santa Claus to return a call as
this guy.
Good luck.
Bob Philbin
Nicolet Instruments
------------------------------
Date: Wed, 9 Nov 88 14:04:14 GMT
From: mcvax!ecn!marcel at uunet.uu.net (Marcel Bernards)
Subject: Re: Mail problems
Reference: v7n3
In your Sun-spot posting v7n3 there was mentioned the wrong ID's of the
postings. I did the same NFS mounts on /var/spool/mail for a lot of sun
3/50 3/60 machines and it works fine:
What to do: use YP and mark for every user in /etc/aliases
an entry: <user>: <mailhost>!<user>
assume that these users are in YP passwd and group in case they are
locally assigned, create a fake entry in /etc/passwd on the yp server
machine:
foo:*:904:900:Foo yong hay:/var/spool/mail:
to force the correct UID & GID on the mailhost when creating the mail
files in /var/spool/mail
This works then also without YP
Local UNIX & Network System administrator,
Marcel Bernards | e-mail: ..!mcvax!ecn!marcel
Netherlands Energy Research Foundation, ECN | Telex : 57211 REACP NL
P.O. Box 1 | Fax : -31 2246 4480
1755 ZG Petten (NH), Holland. | Phone : -31 2246 4342
------------------------------
Date: Tue, 8 Nov 88 17:39:27 MST
From: woods at handies.ucar.edu (Greg Woods)
Subject: Re: Remove booting on a Sun 3/290 -- failure!
> From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
>We found that you can fake out setup(8) on our class B net. For example,
>if the tapeless diskful client is really 128.136.10.128, just tell setup
>that its host address is 128.136.2688 (2688 = 256*10 + 128). It's worked
>from SunOS 3.2 through 3.5
Yes, that works for setup(8), but it does NOT work for the remote copy
program, which is essential in order to install an operating system on a
tapeless diskful client. I have not found a way to successfully copy the
miniroot across without actually configuring the tape server to make the
tapeless client a boot client, booting single user, and using dd(1) to
copy over the miniroot. What normally happens is: by following the manual
procedures, you can load the bootstrap program, boot stand/copy, but when
you go to try and copy the miniroot across, the standalone copy program
hangs forever, sometimes printing messages about looking for Ethernet
addresses for some corrupted Internet address. Even using the above trick,
I have never been able to get the stand/copy program to copy over the
miniroot on our class B net.
--Greg
------------------------------
Date: Tue, 8 Nov 88 16:27:21 EST
From: gfr%wolfgang at gateway.mitre.org (Glenn Roberts)
Subject: Re: "filter to magnify bitmaps 2X"
Reference: v7n5
> "Anyone with source for a screendump magnifier?"
The rastrepl filter (part of standard Sun OS) will multiply raster images
2X.
The 1987 Sun Users Group Tape also contains a magnifier that allows
magnification by a user-specified amount. Source is included. It is on
the tape in directory ./sunview/glass. The tape is $100 (well worth it!)
from the Sun Users Group.
- Glenn Roberts, MITRE
gfr%wolfgang at gateway.mitre.org
------------------------------
Date: Wed, 9 Nov 88 11:41:28 EST
From: bob at cheops.cis.ohio-state.edu (Bob Sutterfield)
Subject: Re: Opportunity for SEX at the SUG
Reference: v7n7
Chuck Musciano <chuck at trantor.harris-atd.com> writes:
>If everyone brought a tape, with anything they had that was
>interesting, you could contribute your stuff, and leave with everyone
>else's.
I'll be there, with a tapeful of GNU and X.V11R[23] and other stuff -
basically the anonymous FTP areas of tut.cis.ohio-state.edu and
giza.cis.ohio-state.edu. It will easily fill a tape at 6250, and I don't
feel like carrying two tapes, so a drive that will handle such densities
would be an advantage.
I may even be persuadable to help straighten out the stuff that
arrives ("Which of these is really the most recent foo?"). --Bob
------------------------------
Date: 9 Nov 88 04:04:43 GMT
From: megatest!djones at decwrl.dec.com (Dave Jones)
Subject: Re: Bug in Gammontool
Reference: v7n7
> Can I be backgammoned even if I have born pieces off?
Nope. You cannot be gammoned or backgammoned once you have born a man
off. [[ Not according to the official rules, anyway. --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list