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' V2 #13 1990-05-06 (1 file, 7968 bytes)
NOTICE: recognises the rights of all third-party works.


Security Digest Volume 2 Issue 13


            security lists active
            crypt and compress
            Suggested change to crypt
            Distribution Policy
            * Re: Uutry in HDB (works fine)
            * Re: YP passwd bugs - SunOS 4.0.3
            umask 000 for FTP 'get' under SunOS 4.0.3 ?
            automatic reply to security-request
            * URGENT: security botch (fwd)
            Guide to Writing Set UID programs safely
            * /usr/etc/in.comsat under SunOS 4.0.3

The unix security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                    

Postings that describe security holes/fixes have a * in their subject.


Date: Sun, 6 May 90 01:46:41 PDT
From: neil (Neil Gorsuch)
Subject: security lists active

[ To avoid confusion in the following, your are reading this on the
larger security list known as the zardoz security list.  The inner
security list is a new subset of that list that is much harder to get
on, and much smaller in size.

The security list is now active again, and digests should appear at
their former somewhat regular intervals.

I have set up the inner security list mechanisms.  I have already
picked some of the iner list members and notified them, and will be
spending the next week or two adding some of the larger list's members
to it.  If you haven't received notification within a week or so, and
feel that you belong on the inner list, send a thorough justification
to security-request.  I'm sure that I will miss some very deserving
larger list members, please don't be annoyed if I don't pick you, just
tell me how I messed up in not immediately seeing your obvious
sterling qualifications 8-).  Please send any email regarding the
inner list to

The inner security list is for the discussion of newly found and
unfixed security holes, including thorough "cookbook" directions on
exploiting them, as well as being a somewhat more select group that
will hopefully have a higher S/N ratio.  Members are one or MORE of
the following:

1. Finders of new security holes.
2. Fixers of new security holes.
3. System administrators of large internet systems.
4. Vendors of unix systems that write/port a lot of the unix system code.

Directions for plugging security holes will be posted to the larger
security list after a delay from the time that they appear in the
inner list.  There will be a staggered posting delay for fixit
postings from the inner list to the larger list, with the larger
internet sites getting the delayed postings before smaller uucp sites.
Unless there is a GOOD reason, you don't need to be on the inner list.
Just being curious or wanting to be on is NOT GOOD ENOUGH.  Nor is
wanting more complete information, very few sites NEED cookbook
directions or unfixed security holes information.  Inner list members
will be expected to make meaningful contributions to it, or will have
a pressing need for the information.  I will not let the inner
security list leak.  If the inner list leaks, I will continue to drop
members until it stops leaking.

If you find new security holes, please post them to,
they will reach the inner list and CERT and other appropriate
locations, and you will also have a good chance of being asked to join
the inner list 8-). - neil ]


Date: Mon, 23 Apr 90 11:52:56 -0400
From: der Mouse  <uunet!Larry.McRCIM.McGill.EDU!mouse>
Subject: crypt(compress())

> Not just any bit patterns constitute a valid compressed file.

If this is really true (except for the header, of course) then the
compress program needs tightening.  I certainly have never seen
anything which wouldn't uncompress with the prepending of a valid
header.  (I just now prepended \037\235\220 to the output of "crypt foo
</vmunix" (not random, but close enough for my purposes) and the result
uncompressed just fine.)

> Someone can probably show that, with the proper precautions,
> crypt(compress()) makes life harder for crackers.

Certainly it makes life hard*er*.  Just not enough harder.  (And it
saves a little disk space, which is always nice.)


Date: Tue, 24 Apr 90 19:44:28 -0400
From: uunet!!wrf (Wm. Randolph Franklin)
Subject: crypt and compress

Here is  one solution to  the problem  of the start of every  compressed
message being  common.   Generate a  16  bit random number  (I know it's
harder  that it sounds.)   Rotate the compressed  message that number of
bytes.  If the message will fit in  memory, which is probable, that will
take 2 block copies.  Then store that random number, with the crypt key,
as part of a new, longer key.

By 'rotate' by K, I don't mean a Caesar substitution.  If A[i] and B[i]
are the i-th input and output chars, then I mean B[i]=A[(i+K) mod N].

Are crypt methods taking advantage  of  the amounts of memory  available
today?  Any method that  processes a message  sequentially 8 bytes at  a
time would seem to be obsolete.  For example, if the  message is N bytes
long, could you generate a random permutation of 1..N and then apply it?
The key would   be   the permutation.  Since  there  are   N!  >>   2**N
permutations, to keep the  key shorter  than the message, you would want
to  select randomly  from a subset  of 2**128  permutations.  Of course,
this might be impossible.


Date: Fri, 27 Apr 90 19:36:29 BST
From: William Roberts <uunet!!liam>
Subject: Suggested change to crypt

My twopennyworth on improving passwords is to use as many bytes
as the user cares to give you, not truncate to eight characters
maximum. Simply fold in successive groups until you run out of
what was typed, during the "repeat 20 times or so" in the crypt

That way you can tell users to choose "pass phrases" which gets
them out of thinking about single words, and makes dictionary
attacks very hard.

PS. When you are suffering from hackers and want to play "let
them in and trace what they do", make sure that you don't do
clever things in stupid ways! We put in a neat little thing
between init and the real login process, but our hacker found
and removed it in very short order, just by using

        cd obviousplace; ls -al | grep Nov (or Jan or Feb or ...)

and bingo, there is the list of changed files. Bury those
programs several levels deep in directories with silly names
belonging to harmless users not listed in important groups.


Date: Mon, 23 Apr 90 10:53:54 EST
From: John Limpert <uunet!gronk!johnl>
Subject: Distribution Policy

> I do not believe in "security through obscurity" but prefer widely
> available security discussions regarding methods, tips, procedures,
> and other matters, as long as they don't touch on security holes that
> REASONABLE AMOUNT OF TIME.  The vendors ARE contacted by CERT and ARE
> probably on the security list.

If this were an ideal world, I would agree with this policy.  However,
many vendors do not fix bugs, whether security or other types, until hit
over the head with a two by four.  After some reasonable period of
time I would like to see the security holes posted to a public forum.
It just might prod some vendors into fixing the security holes in
their systems to avoid public embarrassment.  Many vendors do not care
about security issues or 'obsolete' versions of their operating systems.
As a user/manager of government owned computer systems, most of the
systems I deal with are 'obsolete' in the commercial marketplace.
I may be using that 'obsolete' computer for 10-15 years after the vendor
has decided to stop active software maintenance.

[ I pretty much agree, and will probably post details of security
holes after all affected vendors have had a resonable time to fix
them.  That means after an official release, not just after a couple
of weeks.  - neil ]


Date: Mon, 23 Apr 90 23:24:36 -0400
From: uunet!attcan!attcan!vpk1!bob
Subject: * Re: Uutry in HDB (works fine)

In Digest 2.12, wcs@erebus writes:
> In Digest 2.11,  Bud Hovell <uunet!whizz!bbh> writes
>       > [HDB replaces passwd with ???]
>       It may be worth noting that this is only true if the originator
>       is *not* 'root' (if our local system is typical).  We altered
>       our Uutry script to create an output /tmp file readable *only*
>       by the login user who runs it.
> Be careful doing this - you may break Uutry for users!  What happens
> is that one user runs "Uutry foovax", leaving the file /tmp/foovax mode 600.
> Another user also wants to run "Uutry foovax", but can't because
> /tmp/foovax is unreadable/unwriteable.  Before we got System V R3.*
> sticky directories, the second user could at least rm /tmp/foovax, but
> now that's impossible because it's owned by the first user.
> So if you do a modification like this, make sure you use a
> uniquely-named tmpfile, such as /tmp/foovax.$$

Bud's suggestion above should work fine EVEN with System VR3.* sticky
directories as long as by "readable", he meant that the permissions would
be 622 (ie allowing read by owner only and write by all). In that way, when the
second user runs Uutry, it can still successfully remove the old file from
the /tmp directory. Hence, uniquely-named tmpfiles are not required.

In fact, the Basic Networking Utilities (ie HDB) on SVR3.2.1 and SVR3.2.1
do this (ie. set the tmpfile that is created in a Uutry to be mode 622)
as distributed and require no further modification.


Date: Tue, 24 Apr 90 15:20:45 PDT
From: elroy!judy.Jpl.Nasa.Gov!stevo (Steve Groom)
Subject: callback

In a previous posting, Karl Bunch (tts@ttank) mentioned that it is
possible once logged in, to trick a modem into calling someone and
giving them a shell.  This was done by telling the shell to ignore
hangups, then having the shell send stuff at the modem telling it to
dial somewhere.

This is made more difficult in recent versions of SunOS (4.0.3?) by making
the tty driver declare a line as closed when it sees the modem's
carrier detect drop.  At that point, all I/O on open file descriptors
referencing that modem returns an error, even if CD comes back.
This effectively prevents the kind of hole that Karl was talking about.

It is possible to write a program that does that kind of callback, but
not quite as simple as what Karl wrote.  What happens is that a user
starts process that disassociates itself from all ttys (including the
modem), sleeps waiting for the user to get off the line, then opens the
modem, tells it to dial, and as soon as a connection is made it exits.
This leaves the modem connected, and so when /dev/cua? gets closed the
getty sleeping on that line wakes up and provides a login prompt to the
already connected modem.  I have a program that does this and I use it
all the time.  Pretty spiffy when you're working from home and would
rather have the company pay the phone bill.

For it to work, though, the sleeper process needs to be able to open
/dev/cua?, which can be chown'ed to uucp or somesuch and chmod'ed 600,
which effectively prevents this kind of dialback from working (unless
the sleeper runs as uucp or root).  Fortunately, this is easy to
control, making it work when you want it to and not when you don't.


Date: Fri, 27 Apr 90 10:35:06 +0100
From: Rob McMahon <uunet!NSFNET-RELAY.AC.UK!>
Subject: * Re: YP passwd bugs - SunOS 4.0.3

.. and the problem with two updates running at the same time can be fixed by
adding a `mkdir /etc/ptmp' to the Makefile.  Unfortunately, this can (or used
to be able to) make the rpc.yppasswdd daemon crash if another request comes in
while the update is in progress, so I check to see it's still running, and
restart it it not.  Here's the diffs I've been using for quite a while (your
line numbers will vary slightly):

*** Makefile    Tue Sep 19 18:27:56 1989
--- Standard Input      Thu Jan  1 00:00:00 1970
*** 9,11 ****
! YPPUSH=$(YPDIR)/yppush
--- 9,11 ----
! YPPUSH=$(YPDIR)/yppush -d $(DOM)
*** 22,23 ****
--- 23,26 ----
        -@if [ -f $(DIR)/passwd ]; then \
+       umask 022; \
+       if mkdir /etc/ptmp; then : ok ; else exit 1 ; fi ; \
        awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ { print $$1, $$0 }' \
*** 27,29 ****
--- 30,40 ----
        touch passwd.time; \
+       rmdir /etc/ptmp; \
        echo "updated passwd"; \
+       if /usr/etc/rpcinfo -u `hostname` 100009 1; then \
+       : ok ; \
+       else \
+       /usr/etc/rpc.yppasswdd $(DIR)/passwd \
+       -m passwd DIR=$(DIR); \
+       echo 'restarted yppasswdd'; \
+       fi ; \
        if [ ! $(NOPUSH) ]; then \




Date: Fri, 4 May 90 16:48:37 EST
From: uunet!!ivan (Ivan Dean)
Subject: umask 000 for FTP 'get' under SunOS 4.0.3 ?

This seems so obvious that I feel a little embarassed in posting it.
I've read the last year and a half or so of security list postings,
though, (Don 't worry, my boss receives them quite legitimately), and
don't remember seeing this mentioned before.

When I perform a 'get' command in ftp, the file appears to be created
with my local umask. However, doing it from 'the other end' and using
the 'send ' command results in a file with permissions rw-rw-rw.  I
first noticed this when I ftp'ed my local .login across to another
site on campus only to notice several weeks later that it had these
wide-open permissions.  A lecturer here was quite embarassed when he
used ftp to transfer a file into his c ourse group area, and soon
found that the students were modifying the file. Is this a known bug
in SunOS 4.0.3 ? Are there versions of the ftpd on uunet that
overcome this problem ? We are running the ftpd from Sun, dated 7 Dec.
1988. I was under the impression that this version was considered "se
cure" (for the moment) even for anonymous ftp. Am I mistaken ?


Date: Sun, 6 May 90 00:42:44 PDT
From: neil (Neil Gorsuch)
Subject: automatic reply to security-request

[ I have changed security-request to automatically send a reply so that
  people don't think I'm ignoring them 8-). - neil ]


Date: Sat, 12 May 90 9:10:43 PDT
From: Jeff Beadles <uunet!RELAY.CS.NET!>
Subject: * URGENT: security botch (fwd)

I just received this message from the author/maintainer of "netlib" the email
netlib server.  I'm going to try and reach him to see if he minds this being
posted to the security mailing list, but wanted to let you know.

Forwarded message:
>From  Fri May 11 22:04:31 1990
>From: ehg@inet.att.COM
>Original-From: pyxis!ehg
>Date: Sat, 12 May 90 00:53 EDT
>To: "everyone who ever requested the netlib processor"@inet.att.COM
>If you're running netlib, go to the netlib/admin/bin directory;
>edit reply.c; find the line containing "unsafe(zitem)" and
>insert "|| strchr(zitem,'/')"; then type "make reply".
>Drop everything and do this!  A student in the UK just probed the
>netlib there.  We've seen no attempts in the US---yet.  Please don't
>advertise the hole;  give your fellow administrators a chance to
>plug it first.
>If you have redistributed netlib, please pass this message on
>(and fix the source you distribute).


Date: Mon, 28 May 90 16:31:41 MDT
From: <uunet!ctycal!ingoldsb>
Subject: Guide to Writing Set UID programs safely

A while back I saw a set of guidelines for writing Set UID applications that
don't have unexpected consequences.  Trouble is, I can't remember where I saw
the guide.  Does anyone know?

We are getting ready to RFP some major application software, and are looking
for ways of ensuring the vendors haven't done anything silly via Set UID in
their applications (I've seen numerous examples where this has occurred).  Does
anyone have any suggestions for ways of screening poorly written applications?


Date: Wed, 06 Jun 90 19:20:27 EDT
From: Ed Anselmo <uunet!CS.YALE.EDU!anselmo-ed>
Subject: * /usr/etc/in.comsat under SunOS 4.0.3

/usr/etc/in.comsat under SunOS 4.0.3 seems to be vulnerable to the
same sort of mischief that rwall/wall was [see security digests from
last summer, I believe] -- given a world-writable /etc/utmp, you can
get in.comsat and biff to write files as root.  There seems to be some
restrictions as to which files you can write, since the utmp->ut_line
array is limited to 8 characters.

Sun reports that this problem is "fixed in 4.1" -- quick testing on
one of our 4.1 machines shows that this seems to be the case.

In the meantime we've editied /etc/inetd.conf to have comsat run as
"nobody", and made the executable setgid "tty".  It can't open your
mail file anymore to get headers, but at least you can get some
notification of new mail.


        End of Security Digest Volume 2 Issue 13