The 'Security Digest' Archives (TM)

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

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #17 1985-06-12 (1 file, 2601 bytes)
NOTICE: recognises the rights of all third-party works.


Date: 12 Jun 85 14:21:33 MST (Wed)
Subject: Security Mailing List, # 17


Editor's corner
        Cupboard's a tad bare.

        I have been seeing a number of issues returning after being mailed
        through ihnp4 and allegra because they can't contact the systems
        in question within three days. Please do what you can to make
        sure your systems poll their list regularly.

Newcomers to the list since last issue:
        Brian Zill (brian@muddcs)
        Franklin (
        Davison (
        Eddie Fries (eddy@nmtvax)
        Graham Campbell (
        Joel C. McClung (joel@prcrs)
        Joel Malman (
        Narendra Mehta (naren@clan)
        Paul Staubach (ps@uokvax)
        Roberta Byker (security@pyramid)


Date: Fri, 17 May 85 11:08:01 edt
From: ihnp4!cbosgd!mark (Mark Horton)
Subject: to post or not to post

There are good arguments on both sides about posting.  It can probably be
claimed that the crackers are going to find out about the problems anyway,
especially if they are told to more than a few people.  (I would bet that
some cracker somewhere gets the security mailing list, for instance.)  So
if it were me, unless it were a fairly well kept secret and also had very
devestating results if revealed, I would post the fix.

If you do post to Usenet, the right place is  For some things
you might feel that the security mailing list is the right place.

        Mark Horton


>From garfield!andrew  Mon Jun  3 23:03:44 1985 remote from allegra
Date: Mon, 3 Jun 85 20:33:14 ndt
Subject: f_count bug

I haven't seen this here yet, so I'll use it to liven up our rather
slow list.  Supposedly this bug was publicly noted at the Boston
USENIX in the summer of '82.  I missed that one, so I don't know what
was said exactly.  If anyone was there and remembers this, it would
probably be a good idea for us to know what was said.

This bug affects pre-4.2bsd systems.

UNIX uses a reference counter to figure out how many file descriptors
are pointing at a given open file.  This counter is one field in each
entry of a table of open files.  When you do an open, your access to
the file is checked, and if all is ok, the counter is incremented (or
the whole entry is created if the file was not open before).  A pointer
to that entry of the table is put in your user structure, and all reads
and writes from then on just look at the entry to find out about the
file.  No further permission checking is done.

Each time a close call is done on a descriptor, the counter for that file
is decremented by one.  When the count reaches zero, that entry is
considered "free", and can be reused when another file is opened, since
there are no longer any descriptors pointing at it.  The catch is this:

If you look at /usr/include/sys/file.h on a pre-4.1bsd system, you will
see that the counter, f_count, is a char.  This seems reasonable at first
glance since a given process can have only 20 file descriptors on most
systems.  However, a given user can have 25 processes, and 20*25 is
more than enough to wrap the counter around to zero.  This can be done
by a simple programme which opens any file at all for reading and writing
20 times, and then forks and does it again.  There are at least three things
you can do with this:

1) count carefully to wrap the count to zero, and then open a  file that
you can read but not write.  If you are lucky, the new entry gets placed
on top of the one for your previous file, and all your other descriptors
have write permission on it.

2) If a file is commonly opened by system processes, you can sit around
doing fstats on your wrapped-around descriptors, waiting for something
nice to show up.  You could probably arrange for a setuid programme to
run and grab its descriptors out from under it.

3) 1 & 2 are not restricted to normal files.  You can get at directory
files this way too.  Imagine this massive damage that could be caused
if someone overwrote / or /bin, for instance.

Berkeley attempted to fix this problem in 4.1bsd by changing f_count
to a short.  This was good, but they neglected to change i_count in
inode.h.  I haven't tried anything with this, but I believe you can
do something similar.  i_count has been changed to a short in 4.2bsd.

Changing f_count and i_count to shorts is probably all you need to do
to fix this problem.  I haven't done this myself, since 4.2 was just
around the corner when I first ran into this.  (Well actually it was
really a year away, but that's not what Berkeley told us.)



Date: Thu, 30 May 85 09:41:28 est
From: Wombat <ihnp4!pur-ee!pucc-j!rsk>
Subject: A quick note for the security list

        An interesting (but somewhat theoretical) paper on Unix security is:

        "Specification and Verification of the UCLA Unix Security Kernel",
Communications of the ACM, February 1980, Volume 23, Number 2, pp. 118-131.

Rich Kulawiec, Purdue University Computing Center


                    The UNIX security issues mail list

               Ignore the headers on this list and mail to:
           ...denelcor!security            (mail for the list).
            ...denelcor!sec-request         (administrativia).