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 (dan@bbn-unix.arpa) Davison (davison@bnl44.arpa) Eddie Fries (eddy@nmtvax) Graham Campbell (gc@bnl.arpa) Joel C. McClung (joel@prcrs) Joel Malman (malman@bbn-unix.arpa) 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 net.news.sa. 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.) Andrew ---------------------------------------------------------------------------- Date: Thu, 30 May 85 09:41:28 est From: Wombat 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).