UNIX-WIZARDS Digest V6#017
postmaster at nssdca.gsfc.nasa.gov
postmaster at nssdca.gsfc.nasa.gov
Mon Nov 14 08:34:56 AEST 1988
*** 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 at BRL.MIL
Subject: UNIX-WIZARDS Digest V6#017
Return-path: <unix-wizards-request at 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 at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Message-ID: <8811130245.aa09309 at 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 at auspex.uucp>
Subject: Re: Makefile
Date: 11 Nov 88 22:14:09 GMT
To: unix-wizards at 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 at 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 at 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 at seismo.css.gov>
Subject: Re: Crackers and Worms
Date: 11 Nov 88 20:57:16 GMT
Keywords: bug reality
To: unix-wizards at 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 at faerie.berkeley.edu>
Subject: BSD passwd() [was Re: How to stop future viruses.]
Date: 12 Nov 88 05:45:33 GMT
Sender: news at pasteur.berkeley.edu
To: unix-wizards at sem.brl.mil
In article <10436 at eddie.MIT.EDU> jbs at fenchurch.UUCP (Jeff Siegal) writes:
>In article <10835 at ulysses.homer.nj.att.com> smb at 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 at postgres.Berkeley.EDU ...!ucbvax!aoki
-----------------------------
From: Brad Templeton <brad at looking.uucp>
Subject: Readable Password File
Date: 11 Nov 88 07:21:31 GMT
To: unix-wizards at 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 at auspex.uucp>
Subject: Re: Bigger "dev_t"s
Date: 12 Nov 88 05:45:13 GMT
To: unix-wizards at 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 at auspex.uucp>
Subject: Re: Bigger "dev_t"s
Date: 12 Nov 88 05:52:30 GMT
To: unix-wizards at 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 at 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 at 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 at 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 at sem.brl.mil
In article <426 at auspex.UUCP>, guy at 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 at 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 at sem.brl.mil
In article <8857 at smoke.BRL.MIL> gwyn at 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 at elgar.CTS.COM Keith Gabryelski ...!{ucsd, jack}!elgar!ag
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: various worm questions
Date: 12 Nov 88 05:51:29 GMT
To: unix-wizards at sem.brl.mil
In article <935 at vsi.COM> friedl at 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 at smoke.brl.mil>
Subject: Re: Worm/Passwords
Date: 12 Nov 88 05:59:51 GMT
To: unix-wizards at sem.brl.mil
In article <8563 at rpp386.Dallas.TX.US> jfh at 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 at smoke.brl.mil>
Subject: Re: /etc/shadow
Date: 12 Nov 88 06:27:07 GMT
To: unix-wizards at sem.brl.mil
In article <2189 at cuuxb.ATT.COM> dlm at 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 at fenchurch.mit.edu>
Subject: Re: BSD passwd() [was Re: How to stop future viruses.]
Date: 12 Nov 88 16:35:40 GMT
Sender: uucp at eddie.mit.edu
To: unix-wizards at sem.brl.mil
In article <7311 at pasteur.Berkeley.EDU> aoki at faerie.Berkeley.EDU (Paul M. Aoki) writes:
>In article <10436 at eddie.MIT.EDU> jbs at 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 at ho4cad.att.com
Subject: Re: Internet Virus: SunOS patches
Date: 11 Nov 88 12:27:24 GMT
Sender: nuucp at ho7cad.att.com
To: unix-wizards at sem.brl.mil
In article <754 at m10ux.UUCP>, rgr at 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 at encore.com>
Subject: Re: Worm/Passwords
Date: 12 Nov 88 19:02:23 GMT
Sender: news at husc6.harvard.edu
Followup-To: comp.unix.wizards
To: unix-wizards at 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 at encore.com>
Subject: Re: The Internet Virus--A Commentary
Date: 12 Nov 88 19:36:30 GMT
Sender: news at husc6.harvard.edu
Followup-To: comp.unix.wizards
To: unix-wizards at 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 at suadb.uucp>
Subject: Re: How to stop future viruses.
Date: 11 Nov 88 12:15:36 GMT
To: unix-wizards at 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 at sisu.se OR anders%sisu.se at uunet.uu.net
UUCP:{uunet,mcvax,cernvax}!enea!sics!sisus!anders.
-----------------------------
From: Gert Illemann <gerti at 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 at sem.brl.mil
In article <130 at tree.UUCP>, stever at 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 at 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 at 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 at 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 at stolaf.uucp>
Subject: Re: Implications of recent virus (Trojan Horse) attack
Date: 12 Nov 88 20:37:31 GMT
To: unix-wizards at sem.brl.mil
In article <8562 at rpp386.Dallas.TX.US> jfh at 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 at stolaf.UUCP, but I read mail at mike at wheaties.ai.mit.edu.
-----------------------------
From: Rahul Dhesi <dhesi at bsu-cs.uucp>
Subject: Re: Crackers and Worms
Date: 12 Nov 88 20:46:57 GMT
Keywords: bug reality
To: unix-wizards at sem.brl.mil
In article <14505 at mimsy.UUCP> chris at 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 at embossed.uucp>
Subject: Re: Worm/Passwords
Date: 12 Nov 88 15:15:07 GMT
To: unix-wizards at sem.brl.mil
In article <8563 at rpp386.Dallas.TX.US>, jfh at rpp386.Dallas.TX.US (John F. Haugh II) writes:
> In article <17830 at glacier.STANFORD.EDU> jbn at 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 at alice.uucp
Subject: Morris Tech Report
Date: 12 Nov 88 07:10:32 GMT
To: unix-wizards at 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 at research.att.com
-----------------------------
From: Chris Torek <chris at mimsy.uucp>
Subject: Re: Crackers and Worms
Date: 12 Nov 88 22:54:28 GMT
Keywords: bug reality
To: unix-wizards at sem.brl.mil
In article <4713 at bsu-cs.UUCP> dhesi at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: John Mashey <mash at mips.com>
Subject: Re: Crackers and Worms
Date: 12 Nov 88 21:14:01 GMT
Keywords: bug reality
To: unix-wizards at sem.brl.mil
In article <2373 at aplcomm.jhuapl.edu> jwm at aplvax.UUCP (Jim Meritt) writes:
>In article <829 at mcrware.UUCP> droid at 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 at 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 at mmlai.uucp>
Subject: Re: Worm/Passwords
Date: 11 Nov 88 15:39:04 GMT
To: unix-wizards at 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 at 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 at 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 at 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 at 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 at auspex.uucp>
Subject: Re: Internet Virus: SunOS patches
Date: 12 Nov 88 21:37:45 GMT
To: unix-wizards at 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 at 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 at sem.brl.mil
In article <18 at elgar.UUCP> ag at 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 at cs.cmu.edu Bitnet: bsy%cs.cmu.edu%smtp at interbit
CSnet: bsy%cs.cmu.edu at 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 at utoday.uucp>
Subject: Re: The Internet Virus--A Commentary
Date: 12 Nov 88 18:25:57 GMT
To: unix-wizards at 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 at decwrl.dec.com>
Subject: Re: Crackers and Worms
Date: 13 Nov 88 03:42:43 GMT
Keywords: bug reality
To: unix-wizards at sem.brl.mil
In article <3380 at emory.uucp> arnold at emory.UUCP (Arnold D. Robbins {EUCC}) writes:
# In article <44440 at beno.seismo.CSS.GOV> rick at 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 at decwrl.dec.com decwrl!vixie +1 415 853 6600
Play: paul at vixie.sf.ca.us vixie!paul +1 415 864 7013
-----------------------------
From: David Collier-Brown <daveb at 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 at sem.brl.mil
>From article <422 at auspex.UUCP>, by guy at 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
**************************
More information about the Comp.unix.wizards
mailing list