The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #24 1989-06-18 (1 file, 5813 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/124.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Security Digest Volume 1 Issue 24

subject(s):

            client-address-restrictor for daemons
            Denial-of-service -- rmail vs. the security list
            list(s) ramblings
            Mail from root. (was Re: SECURITY HOLE IN SUNOS (possibly others also)
            Re: SECURITY HOLE IN SUNOS (possibly others also)
            Re:  SECURITY HOLE IN SUNOS (possibly others also)

------------------------------------------------------------------------

Date: Sun, 18 Jun 89 01:54:35 EDT
From: Win Treese <uunet!crl.dec.com!treese>
Subject: client-address-restrictor for daemons

> We (3com) recently connected one of our vaxes to the Internet,
> and in the process of making everything secure I wrote
> this code to restrict access from the outside. It's
> a quick hack, and there are improvements that could be made
> I'm sure, but it does an adequate job.

You might be interested in the paper "Simple and Flexible Datagram
Access Controls for Unix-Based Gateways" by Jeff Mogul, which appeared
in the Summer '89 USENIX Proceedings.

------------------------------------------------------------------------

Date: Sun, 18 Jun 89 15:01:34 PDT
From: david@dhw68k.cts.com (David H. Wolfskill)
Subject: Denial-of-service -- rmail vs. the security list

I encountered something that I thought curiously self-referential....

My machine is a UUCP neighbor of Neil's; I subscribe to the security
list, and I try to do my part as far as helping out with mail and
general uucp connectivity.

Well, a couple of things entered the queue of uucp work from zardoz...
and uuxqt promptly died, leaving only /usr/spool/uucp/XTMP/core (and a
dead LCK..XQT) file by which to remember it.

Unfortunately, each successive uuxqt that came into existence here also
attempted to process that very same item on the queue -- and met the
same fate.

Here is a (quoted) copy of one of the files that caused uuxqt to exhibit
these symptoms:

>::::::::::::::
>X.zardozX0273
>::::::::::::::
>U daemon zardoz
>F D.dhw68kB0275
>I D.dhw68kB0275

[ I deleted the the partial listings of this list's members - neil ]

Note that the last quoted line above was 764 characters (originally).

After receiving a clue from someone on a mailing list that I maintain, I
created an entry in /usr/lib/aliases on this machine (which should be
equivalent to the above), called it "zardoz-sec-list", and then edited
the above long line so it read

C rmail zardoz-sec-list

The result was that uuxqt ran just fine....

[ I have found that a large number of uuxqt's cannot handle large lists
of destinations.  That is one of the reasons that most of the security
mailing list goes out through uunet and a few other large sites.  In this
instance, a uucp maps problem routed a portion of the list's output through
dhw68k - neil ]

------------------------------------------------------------------------

Date: Wed, 28 Jun 89 03:37:49 PDT
From: neil (Neil Gorsuch)
Subject: list(s) ramblings

I promise that I will finish setting up the security list archive
service Real Soon Now, and will announce it then.  But as you can see
from the time of day (night) that this was posted, I am fairly busy
these days.

I have always been uncomfortable with a shell script being run by
news, even in a chroot'ed directory, to unpack the uucp maps.  I
kludged up uuhosts so that it checks for specific header fields, and
uses awk to unpack the map into only one directory, without "calling"
a shell to invoke cat and/or sed and/or whatever.  On a Solbourne, it
is fast enough for my purposes.  After I let it run for a few more
days, and if noone emails me telling me of an already available piece
of code that does this, I will post it here and to comp.sources.unix
and misc.security.  So please email me if you know of something like
that out there already.  I am also going to produce a more general
purpose unshar replacement that does not invoke a shell to do the
work.  Is it already available (email me please) ?

[ The rest of this digest is a discussion of the security list itself - neil ]

Before I continue with this very lengthy posting, I must warn you that
I am relaxing my usual guideline of not wanting general discussions on
this mailing list for the topic following.  I will put any discussion
generated on this topic at the end of digests.  In this case, the
topic of discussion is the list itself.  So feel free to email to me,
or post to the list, any responses you may have.  Everyone that is
satisfied with this mailing list can skip the rest of this.  I will
assume that if you don't respond to this topic, that you have implicit
faith in this list and my handling of it 8<).  With that in mind, read
on if you wish ...

The zardoz unix security mailing list is a RESTRICTED list.  It is
reasonably safe to post SCARY security holes here.  I have gone to a
lot of effort to make sure of this.  I would not recomend posting the
3000 line source program for the internet worm here (or anywhere else
for that matter), but it is reasonably safe to post the details of the
the "rwalld/utmp" here.  There are enough other ways to crack root
that haven't been fixed yet on a large number of internet hosts, that
I am not too worried about the "rwalld/utmp" hole leaking out and
causing a crisis, given the caliber of this list's members.  I spoke
to Seth Robertson, and he is going to post the details to this list.
A few list members expressed concern about the security of this list
after seeing his directions to send a request from root to receive the
details.  Please do not be concerned, none of the other root
"cracking" methods revealed here have come back to haunt anyone, and
there have been a number of them.  There is no absolutely safe mailing
list, but this one is about as safe as I can make it without hiring
private investigators to research every applicant.

One member raised the possibility of a smaller, more restricted list.
I would be happy to create a sub-list, but who wants to volunteer to
NOT be on it 8<) ?  The isis list, when it was active years ago, was
smaller, and Andrew Burt imagined that it was SECURE because he only
allowed large institutions on it that were OK'ed by other large
institutions that were OK'ed by other ...  You get the idea, I'm sure.
But what does one system administrator know about another system's
administrator, that he might have never even met?  As Andrew Burt told
me himself, he found out that one of his members (a vice president of
engineering at a large electronics company) was a well known "cracker"
in his spare time.  But he only found out by accident, after admitting
him to the list.  There already is a fairly small internet mailing
list that is somewhat security oriented.  It was created for the
internet worm crisis, but is pretty much inactive now.  At least I
haven't received anything from it lately.  If someone wants to create
a REALLY secure list comprised only of personal friends and other
acquaintances that they have known for a long time, feel free, but it
might be a fairly small and slowly growing list 8<).

One of the main purposes of this list is to notify appropriate people
of security holes BEFORE they become common knowledge (which they
almost invariably will after a certain amount of time).  There is no
reason to have a security mailing list if it no more than a forum for
duscussing theoretical security issues, there are already appropriate
usenet news groups for that kind of thing.  And you can't describe how
to guard against most major security holes without revealing clues to
exactly what the problem is.  So I can't really see having both an
intermediate and a high level list.  What use is the intermediate
level list?

On another vein, Andrew Burt has come back to haunt me again 8<).
After letting the former list lapse for a few years, then trying to
start it back up again at the same time that I started this list, and
then failing at his second try, he posted a message to usenet asking
for volunteers to take over "the list".  When I contacted him recently
about merging his list into mine, he said that someone else was taking
it over.  I contacted the person he has designated as his successor
(who was already a member of this list), and we agreed to merge the
about-to-be-recreated isis list into this one.  If I sound a little
annoyed at Mr. Burt, it's because I have put a lot of time into this
list, and don't appreciate his attitude towards it.

On another subject still, mail from root is not a guarantee of
identity.  When I first started this list, I didn't notice the
"trusted users" ability of sendmail, and I set the list up to use an
SMTP mail faker program so that all output would appear to come from
"security-request".  There is no entry for security-request in
/etc/passwd here 8<).  Not to mention the ease of bringing up most
workstations in single user mode.  Can you say "dataless
configuration" ?

I apologize for the length of this posting, and I will be amazed if
many of you read it through the whole way 8<).

Neil Gorsuch
(aka security-request)

------------------------------------------------------------------------

Date: 18 Jun 89 23:24:03 CDT (Sun)
From: letni!doug  (Doug Davis)
Subject: Mail from root. (was Re: SECURITY HOLE IN SUNOS (possibly others also)

>I will most likely *mail* people more detailed explanations *if*
>the request comes from root.

I really hate to point this out, *HOWEVER* it needs to be said,
mail messages from anyone are easily formed. consider;

cat constructed_bogus_message | uux - -r fuzzysite!rmail (path)

Besides, "root" is not a valid user on our machines and I hate
having to forge messages from "root" just to get the information
I would like very much to know.

[ I talked to him, he will post the details here. - neil ]

------------------------------------------------------------------------

Date: Tue, 20 Jun 89 16:57:06 CST
From: David Newall  <uunet!munnari!PISA.sait.oz.au!david>
Subject: Re: SECURITY HOLE IN SUNOS (possibly others also)

This isn't a flame; it just sounds like one.

> I will most likely *mail* people more detailed explanations *if*
> the request comes from root.

I thought that this list is supposed to be restricted.  So there is no
need to be afraid of posting security nasties.  Let's not waste time
here.

[ I agree.  Again, it will be posted in the next digest - neil ]

------------------------------------------------------------------------

Date: Sat, 24 Jun 89 10:06:50 EDT
From: Bernie Cosell <uunet!cs.utexas.edu!wasatch!mailrus!wilma.bbn.com!cosell>
Subject:  Re:  SECURITY HOLE IN SUNOS (possibly others also)

[ This was email to me, I posted it as part of the discussion - neil ]

Dunno if you want to reforward this to the whole list or not, but I think it is
a matter worthy of discussion.  So I know it is a little impolite, but I'll write
it speaking of you in the third person so that it makes sense to the list-folk
if they get to see it.  /b\

} Gigantic Sun Security Hole  (possibly all BSD Unix)
}
}  ...
i}
} I will most likely *mail* people more detailed explanations *if*
} the request comes from root.

At last a chance to ask this: now we see clearly the difference between this and
Andy Burt's now-defunct version of the security list.  For the old security
list, two things woudl be different:
  a) we wouldn't get "do this to fix this nasty thing but I won't tell you what
     it is really fixign or if this is the ONLY method to fix it or anything
     else", and
  b) I'm making up some authentication procedure for telling you the REAL scoop.

[ I don't control the security-emergency route in any way, and can't prevent
people from doing this.  In every digest that has gone out that included a
warning of a serious security hole, I have included the details, as far as I
can remeber.  The only difference between the lists are in Andrew Burt's mind.
That and the fact that this list is successful, and his failed, twice.
I talked to Seth Robertson and have convinced him of this. - neil ]

Perhaps this is the time to figure out some better way do deal with REAL
security info.  I know that this is beyond what Neil wanted to do with this
list, but that still leaves a hole.   Could Neil, for example, maintain a
*sublist* of the main list for which he uses more stringent registration
procedures, and allow that one to carry the no-holds-barred type of REAL
security info that is _crucial_ to correctly handle things like this?  Is Andy
still about (I never got clear how that list eventually died, if it really did
finally, nor what happend to the 'approved' list of sys admins he maintained)?

[ Again, my intention from the start has been to run the SCARY SECURITY HOLES
mailing list, including the dangerous details.  The only person that thought
that I was running a less stringent list was Andrew Burt, because he couldn't
admit that I was taking "the list" over.  See my earlier posting. - neil ]

For example, if we are going to go to the bother of "convincing" Seth that it
is OK to tell us what he is REALLY talking about (in this case, I happen to
already know, so I can 'feign' umbrage without really compromising the security
of our systems :-)), why not figure out a suitable procedure ONCE and have us
do it ONCE *with*Neil*... Then let "sensitive" stuff only go out onto a 'short
list' of pre-approved sysadmins.

----------------------------------------------------------------------------

        End of Security Digest Volume 1 Issue 24
        **********************

END OF DOCUMENT