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' #26 1987-03-21 (1 file, 11466 bytes)
SOURCE: http://securitydigest.org/exec/display?f=unix/archive/026.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Sat, 21 Mar 87 07:59:51 mst
Subject: Security Mailing List, # 26

-------
Topics:
        Admin and new people on the list
        Security posting
        Re: Unix Security Mailing List reborn
        Submission for security mailing list
        Dearth of security articles
        archive of 4.2bsd bugs. Bug in ptrace().
        Security auditing program

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

Editor's corner.

Well, this is the first "real" issue since I've taken over the list.
Since the list fell apart over a year ago I'm posting the entire membership
list rather than just the newcomers as will usually be done.  (If you
see someone on here you know doesn't belong let me know :-)

In the next two issues will be the source code to the programs in the Wood &
Kochan "Unix System Security" book (submitted by Pat Wood himself).

People have again brought up the matter of the security of the list itself.
I do not want any perceived insecurity of the list to prevent readers from
becoming submitters:  If you know of a nasty hole, submit it.  I do my
best to keep the student hackers, etc. off the list.

So you know, here's what I do.  If an applicant is known to me (and I
trust them) they get on.  If I don't know them I send back a request to
the root user of that machine for them to fill out regarding this
person (often the person himself).  This way they have to have root
privileges on that machine.  (Or (a) root's mail in the spool dir must
be readable (b) they must know how to fake mail and (c) be able to
remove the mail so the real root doesn't see it; hopefully this
combination of events doesn't happen often.)

If the site this user is on is a questionable one (not listed in the
UUCP maps or is foo.bar.bigplace.edu) then I request ok's from the
neighboring UUCP system's roots (tracing back to a trustable system).
Granted, a UUCP map entry may be faked, and if I have doubts I ask
the neighbors.

The biggest problem I've found is in validating foo.bar.bigplace.edu
and other Internet addresses.  Does anyone know of a way to find out the
name/e-mail-address of someone in charge of a domain, which might be an
arpa site, a UUCP zone site, a CSNet site...?  It has to be easy to do
-- I can't spend all my waking hours validating users (and long distance
phone calls are out).

Many people have asked why I requested mail from root in the
comp.unix.wizards/etc. posting.  I did so NOT because I was going to
allow any mail from root on the list.  Instead, I did it to prevent the
majority of the readers who couldn't send root mail from requesting to
join.  As it was I received well over 100 applications (about 95% were
valid).

Lastly, people have again brought up the idea of encrypting the list.  I think
the arguments in the first issue still hold:  It's not worth the slight
edge it gives.

Until next issue...

Newcomers to the list since last issue [really everyone on the list]:
        Nicholas Horton (horton@harvard)
        Jonathan Corbet (security@rdss)
        Bjorn Eriksen (ber@enea)
        Tom Dunigan (security@ornl-msr.arpa)
        Clifford Neuman (sec-redist@mit-eddie)
        Liudvikas Bukys (security@rochester)
        Ray Davis (bees@infoswx)
        Gene Spafford (spaf@gatech)
        Doug Tygar (tygar@harvard)
        Doug Hosking (hosking@convex)
        John Gilmore (gnu@hoptoad)
        Keith Bostic (keith@seismo)
        George Goebel (ghg@pur-ee)
        Robert Elz et al. (kre@munnari)
        David J. Sullivan (sullivan@cmcl2)
        Karl A. Nyberg (karl@grebyn)
        Mel Pleasant (sec-list@topaz)
        Al Gettier (al@infoswx)
        Mark Horton (mark@cbosgd)
        Prentiss  Riddle (security@ut-sally)
        Mark Plotnick (mp@allegra)
        Bernie Cosell (unix-security-bbn@prophet.bbn.com)
        Larry Auton (security-issues@clyde)
        Bill Stewart (wcs@ho95c)
        Peter Honeyman (honey@down)
        Andrew Draskoy (sydney.cdn!andrew@ubc-vision)
        Bill Blue (blue@crash)
        Bill Kanawer (bill@dual)
        Paul Albitz (security-local@purdue)
        Doug Orr (textset!doug@umich)
        Dennis Reed (dfr@onecom)
        Phil Ngai (phil@amdcad)
        Ted Swoyer (ted@apcieco)
        Peter N Wan (security-list@msdc)
        John McDermott (secure@unmvax)
        Bill Mitchell (whm@arizona)
        Phil Kaslo (phil@arizona)
        Nigel Horne (njh@rootcl)
        David M. Watson, Jr. (security@cfa)
        Geoff Kuenning (security@desint)
        Cheryl Bien (sec-list@trwrb)
        Lloyd Wright (security@hp-pcd)
        James A. Woods (ames-aurora!jaw@ames)
        Eric McRae (smlist@amc)
        Dave Eckhardt (dae@psuvax1)
        Jay Lepreau (holes@utah-cs)
        Dave Fiedler (dave@infopro)
        Howard Weiss (hsw@tycho.arpa)
        Fred Avolio (security@decuac)
        Joe Camaratta (jcc@siemens)
        Peter Wolfe (security@winston)
        Steve Glaser (security@tektronix)
        William L. Sebok (security@astrovax)
        Michael Peterson (mkp@scgvaxd)
        Steve Bellovin (smb@ulysses)
        Russell L. Brand (brands@lll-crg)
        Byron C. Howes (bch@ecsvax)
        Jim Ellis (security@mcnc)
        Tom Patterson (unix-security@wucs1)
        Joe M. Orost (joe@petsd)
        Fred Grampp (ftg@grigg)
        David Grossman (dpg@abstl)
        Bill Shannon (unix-security@sun)
        Richard Stevens (root@hsi)
        Andrew Shore (shore@adobe)
        Kevin Poulsen (unix-security@sri-spam.arpa)
        Henry Spencer (henry@utzoo)
        Tim Rosmus (sys-secure@tikal)
        Randy Dodge (security@munucs)
        Will Martin (wmartin@brl-smoke)
        Russell J. Yount (security-forw@cadre)
        Jim Haynes (haynes@ucscc)
        Rob Robertson (rob@nitrex)
        Jyrki Yli-Nokari (security@tut)
        Rod Hart (hart@cp1)
        Ed Gould (ed@mtxinu)
        Bill Welch (bill@zaiaz)
        Alan Silverstein (ajs@hpfcla)
        Roberta Byker (security@pyramid)
        Daniel Flickinger (security@flkvax)
        Randy Sebra (randy@amsaa.arpa)
        Dave Lennert et al. (security@hpda)
        Richard Kelly (security@flan)
        Paul Staubach (sec-dist@uokvax)
        David L. Parnas (vax-populi!security@nrl-css.arpa)
        Stephen Muir (uk-unix-security@dcl-cs)
        Larry Parmelee (security@cornell)
        Tom Christiansen (sec-issues@uwvax)
        Steve Feldman (sec-list@tymix)
        Matt Bishop (security@riacs)
        Nat Howard (security@inmet)
        Ken Lester (ken@ektools)
        Hokey (root@plus5)
        Hugh Daniel (sysop@well)
        Scott Preece (secgrp@ccvaxa)
        Marsh Gosnell (mkg@lzma)
        David Herron (uky-security@ukma)
        Ben Goldfarb (security@ucf-cs)
        Rocke Verser (security@hpmtla)
        Chris Coffin (coffin@mot)
        Cameron Carson (sec-dist@bu-cs)
        Mark Smith (security@uvacs)
        Topher Eliot (security@cyb-eng)
        Jeff Gillian (security@voder)
        Andrew Seirup (security@bunker)
        Maureen Chew (root@scirtp)
        Rob Warnock (rpw3@redwood)
        Peter Yee (yee@ucbvax)
        Jim Guyton (guyton@randvax)
        watmath admin (ML_unix-sec@watmath)
        Pierre-Alain Michel (hpbbse!pam@hpfcla)
        Steve Hubert (security@uw-beaver)
        Jeff Glass (security-mlist@security)
        James M. Galvin (dist-unix-security@louie.udel.edu)
        Jack Allen (root@sb6)
        Rich Salz (root@mirror)
        Mark Laubach (hpcera!laubach@hpcea)
        Mark Verber (unix-security@osu-eddie)
        John Blair (johnb@neoucom)
        Jennine (jennine@cithep)
        Greg Hidley (netsecurity@sdcsvax)
        John Pierce (security@sdchem)
        Sid Shapiro (security@wanginst)
        Rich Wales (wales@ucla-cs)
        David C. Cantor (dist-sec@uclamath)
        Sindi I Wisse (siw@sabre)
        Jon Eichelberger (root@nadc.arpa)
        Matt Crawford (sec-distrib@oddjob)
        Robert Bond (rgb@nsc-pdc)
        Mark Starner (security@burdvax)
        Terry Slattery (security@usna)
        John Sechrest (security@orstcs)
        Norm Seethoff (security@fluke)
        Ed Arnold (hpfcms!ed@hpfcla)
        Marc Lesure (asuvax!security@arizona)
        Greg Fowler (root@hplabs)
        Dan Ts'o (dan@rna)
        John Bossert (camco!bossert@tikal)
        Naim Abdullah (naim@nucsrl)
        Ed Greenberg (edg@micropro)
        Pat Wood (phw@phw5)
        Steve Parker (sdp@dscvax2)
        Rich Salz (root@mirror)
        Stephen J. Hartley (hartley@uvm-cs)
        William Robertson (rob@philabs)
        Jim Nesheim (secure-unix@batcomputer)
        Steve Blasingame (security@gorgo)
        Bob Devine (devine@vianet)
        Henry Mensch (henry@garp)
        Joe Carlson (carlson@lll-winken.arpa)
        David Gast (dave@secisl)
        Ken Stone (ken@hp-sdd)
        Greg Laskin (laskin@gryphon)
        Win Treese (unix-security-incoming@mit-athena)
        Dennis Michael (dennis@ucrmath)
        Bob Page (page@ulowell)
        Mel Melchner (mjm@jones)
        Bob Coggeshall (coggs@boulder)
        Gary Gere (ggere@csi)
        Rick Perry (perry@vu-vlsi)
        Jacob Gore (gore@nucsrl)
        Ron Flax (ron@vsedev)
        Carlton B. Hommel (carlton@masscomp)
        William G. Stefancik (wstef@hubcap)
        Curtis C. Generous (generous@dgis)
        William King (wrk@abic)
        Mark V. O'Riordan (mvo@cbnscs)
        Roy Smith (roy@phri)
        Bob Weissman (bob@acornrc)
        Jay Schlegel (jay@artecon)
        Garth Snyder (garth@swatsun)
        Dave Mason (mason@tmsoft)
        Tom Wadlow (taw@spar)
        Sharan Kalwani (shan@mcf)
        Mike Wescott (wescott@ncrcae)
        Harry Edmon (harry@uw-atm)
        Steven Grady (grady@ingres.berkeley.edu)
        Chuq von Rospach (plaid!chuq@sun)
        John McInerney (john@mplvax)
        Bill Huttig (wah@macs)
        J. Gregory Noel (greg@ncr-sd)
        C. Jeffrey Small (cjsa!jeff@hsi)
        Gerald J. Hopkins Jr. (jerry@idacrd)
        Warren Burstein (warren@pluto)
        Grant Kerr (kerr@oodis01.arpa)
        Nawaf K. Bitar (nawaf@elrond)
        Bob Toxen (bob@anvil)
        Mike Whitman (mike@pyrdc)
        Dan Messinger (dan@rose3)
        Josh Siegel (hi!josh@hc.dspo.gov)
        Armando Stettner (aps@decwrl)
        Jim Knutson (knutson@ut-icv1)
        Todd Ogasawara (todd@uhccux)
        Bruce E. Cantrall (brucec@astroatc)
        King Ables (ables@mcc-pp)
        Kian-Tat Lim (klim@hvrunix)
        Christopher Lott (cml@sppy00)
        Romain Kang (romain@pyrnj)
        Paul Pomes (paul@uxc.cso.uiuc.edu)
        Emery Newlon (monitor@mts-cs)
        Cyrill Lord (cyrill@scicom)
        Russ Sage (russ@oliveb)
        Paul J. Anderson (paul@brunix)
        Jerry M. Carlin (jmc@ptsfa)
        Wendy Thrash (wendyt@unisoft)
        Joseph Angelo (joe@auspyr)
        Roger Rose (rose?@stcvax)
        Tom Marazita (toad@ucsbcsl)
        Joseph Judge (joe@cbdkc1)
        Petri Launiainen (pl@intrin)
        Stephen Paddock (paddock@melpad)
        Jim McKie (jim@bellcore)
        Marty Olevitch (marty@wuphys)
        Michael Lichter (michael@csvax.caltech.edu)
        David Robinson (david@elroy)
        Stephen Campbell (root@dartvax)
        Stephen E. Hansen (oasis!hansen@shasta)
        William M. Kules (wmk@baskin)
        Arthur David Olson (ado@elsie)
        Al Clark (gewest!clark@calma)
        Ron Stanonik (stanonik@nprdc.arpa)
        Donald Joslyn (don@novavax)
        Tony Cratz (catsim!tony@intelca)
        Darryl J. Pahl (darryl@thunder)
        Coyne A. Gibson (coyne@tifsie)
        J Scott Goldberg (j@telesoft)
        Wilson Bent (whb@hoh-1)
        Craig Peterson (craig@ccsi)
        Joe Brame, Jr. (jbb@sp7040)
        John A. Gordos, III (gordos@crta)
        Jordan Hayes (jordan@ames)
        Curtis Jackson (rcj@burl)
        Jerry Sublett (jcs@burl)
        Tapani Lindgren (nispa@hut)
        Mark H. Colburn (mark@ems)
        Chris Paris (cap@verdix)
        Jeffrey Greenberg (jmg@dolphy)
        Jim Lowe (james@uwmcsd1)
        Craig Ruff (craig@ssds)
        Stuart Freedman (stuart@dgloki)
        Andrew Partan (cos!asp@sundc)
        Landon Curt Noll (chongo@amdahl)
        Bruce Barnett (steinmetz!barnett@calma)
        Joe Kane (steinmetz!kane@calma)
        Tim Pointing (tim@dciem)
        George Moore (gm@trsvax)
        Brad Lowman (bhl@uclachem)
        Will Edgington (wedgingt@udenva)
        Al Gaspar (gaspar@almsa-1.arpa)
        David Barto (barto@megatek)
        Mike Parker (mouse@mcgill-vision)
        Bob Tomlinson (tomlin@hc.dspo.gov)
        George Pajari (pajari@cdl)
        Alan P. Sexton (alan@ecrcvax)
        Tadd Ottman (root@csuh)
        Carsten Bormann (tub!cabo@pyramid)
        Craig E. Ward (cew@isi.edu)
        Mark A. Brown (root@usc-oberon)
        Lloyd W. Taylor (lwt1@aplcen)
        Mark Brukhartz (mdb@laidbak)

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

Date: Mon, 18 Jun 84 09:51:52 edt
From: rs@mirror.TMC.COM (Rich Salz)
Subject: Security posting

Here's one for you.

Okay, like I'm bored opening a telnet connection to my SMTP
port as a way of faking mail.  How about this?  Anyone ever
put dummy qfAAxxxxxx and dfAAxxxxxx files in /usr/spool/mqueue
on a sendmail machine?  I suppose the way to fix this is to
make /usr/lib/sendmail be set[ug]id *something* -- but what?
Anyone run sendmail setgid other than root?
        /rich $alz


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

Date: Mon, 2 Mar 87 21:11:29 EST
From: Skip Montanaro <rochester!steinmetz!montnaro>
Subject: Re: Unix Security Mailing List reborn


Good thing (rebirth of the mailing list). I'm not the appropriate person at
our site to join the list, so I won't send you any of that information,
however, I think a good starting topic for the new list would be Brian
Reid's Viewpoint editorial in the most recent CACM (Feb 87?). I checked
/usr/spool/at on my Sun (Sun OS 3.2) and found that it was not set up as
permissively at Brian stated in his editorial, although not as securely as
it should have been. Also, the "unbounded expansion" of .rhosts files is
really dangerous. We have about 120 Suns on our local ethernet. The tendency
for cruft to grow on /.rhosts is virtually impossible to check. Perhaps only
automatic regeneration from crontab will effectively curb this problem,
although I'm sure solutions of this nature will have holes as well.



-- 
Skip
-
ARPA: montanaro%desdemona.tcpip@ge-crd.arpa
UUCP: seismo!rochester!steinmetz!desdemona!montanaro
GE DECnet: csbvax::mrgate!montanaro@desdemona@smtp@tcpgateway


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

Date: Sat, 28 Feb 87 19:11:06 EST
From: cmcl2!phri!roy (Roy Smith)
Subject: Submission for security mailing list

        To get things rolling, I guess it might be instructive to describe
a breakin we had a while ago (August 1986); how I happened to find out
about it, and what had gone wrong to allow it to happen.  I'll try and
present this more or less in chronological order, or at least as close as I
can remember it.

        The first thing that alerted me that something was amis was when I
noticed somebody (who I knew was on vacation) logged in over a phone
connection.  Since this person doesn't use the system much even when he's
around, I figured something was up.  Curious to see what was going on, I
ran "lastcomm harvey" to see what he had been doing.  Not much exciting; he
had just logged in, run who, finger, and mail.  I happened to know harvey
pretty well and didn't think he even knew about finger.  This wouldn't
normally make me curious, but since I was already suspicious, it made me
even more so.

        Next thing I did was check the mail logs to see who had been
sending him mail (or who he had been sending it to; you can't tell from the
lastcomm).  Some excerpts from our /usr/spool/mqueue/syslog for that day:

Aug 24 14:34:26 localhost: 27395 sendmail: AA27395: message-id=<8608241834.AA27395@phri.uucp>
Aug 24 14:34:28 localhost: 27395 sendmail: AA27395: from=wjelny!wjel, size=5, class=0
Aug 24 14:34:31 localhost: 27397 sendmail: AA27395: to=harvey, delay=00:00:06, stat=Sent
Aug 24 14:50:05 localhost: 27439 sendmail: AA27439: message-id=<8608241850.AA27439@phri.uucp>
Aug 24 14:50:06 localhost: 27439 sendmail: AA27439: from=roy, size=110, class=0
Aug 24 14:50:09 localhost: 27444 sendmail: AA27439: to=harvey, delay=00:00:05, stat=Sent
[...]
Aug 24 17:07:47 localhost: 27934 sendmail: AA27934: message-id=<8608242107.AA27934@phri.uucp>
Aug 24 17:07:49 localhost: 27934 sendmail: AA27934: from=wjelny!wjel, size=27, class=0
Aug 24 17:07:52 localhost: 27936 sendmail: AA27934: to=harvey, delay=00:00:06, stat=Sent

        Now I'm running in full detective mode.  We don't talk to anyplace
called "wjelny", nor have I ever heard of it.  I'm not happy.  So, I look
to see if wjelny or wjel has ever logged in to our system and come up
empty.  Then I look through our uucp logs and find these little gems:

cubsvax wjelny (8/24-12:53-26970) OK (startup)
cubsvax wjelny (8/24-12:53-26970) REQUESTED (R /etc/passwd /u/wjel/uucpin wjel -dc)
wjel wjelny (8/24-12:55-26970) REQUESTED (R /etc/passwd /u/wjel/uucpin wjel -dc)
wjel wjelny (8/24-12:56-26970) OK (conversation complete)
cubsvax wjelny (8/24-13:08-27027) OK (startup)
cubsvax wjelny (8/24-13:08-27027) REQUESTED (R ~root/usr/lib/uucp/L.sys /u/wjel/uucpin wjel -dc)
wjel wjelny (8/24-13:08-27027) PERMISSION (DENIED)
wjel wjelny (8/24-13:08-27027) OK (conversation complete)
wjel wjelny (8/24-13:09-27027) TIMEOUT (wjelny)
[...]
cubsvax wjelny (8/24-14:33-27324) OK (startup)
cubsvax wjelny (8/24-14:33-27324) REQUESTED (S D.phriBC0299 D.phriBC0299 wjel)
wjel wjelny (8/24-14:33-27324) REQUESTED (S D.wjelnyXA0299 X.wjelnyXA0299 wjel)
wjel wjelny (8/24-14:33-27324) OK (conversation complete)
wjel wjelny (8/24-14:34-27324) TIMEOUT (wjelny)
uucp wjelny (8/24-14:34-27390) wjel XQT (PATH=/bin:/usr/bin:/usr/ucb;export PATH;rmail harvey )
[...]
cubsvax wjelny (8/24-17:07-27809) OK (startup)
cubsvax wjelny (8/24-17:07-27809) REQUESTED (S D.phriBC0307 D.phriBC0307 wjel)
wjel wjelny (8/24-17:07-27809) REQUESTED (S D.wjelnyXA0307 X.wjelnyXA0307 wjel)
wjel wjelny (8/24-17:07-27809) OK (conversation complete)
uucp wjelny (8/24-17:07-27929) wjel XQT (PATH=/bin:/usr/bin:/usr/ucb;export PATH;rmail harvey )

        Omigod; this is for real!  Somebody managed to get ahold of a uucp
login and password for our system and requested our password and L.sys
files!  The reason I never saw wjelny log in is because he never did; he
logged in as cubsvax and gave wjelny as his system name.  Of course,
/etc/passwd is world readable, and why shouldn't it be?  There isn't much
in there that will do anybody any good.  They certainly won't be able to
decrypt the passwords, unless... they are hoping to find a normal account
without a password.  Bingo!  A quick "egrep :: /etc/passwd" shows that
harvey is the only account without a password and sure enough:

harvey    ttyd3                     Sun Aug 24 17:08 - 17:09  (00:00)
harvey    ttyd3                     Sun Aug 24 14:36 - 14:37  (00:01)
harvey    ttyd3                     Sun Aug 24 13:10 - 13:12  (00:01)
harvey    tty15                     Mon Jul 28 14:29 - 14:34  (00:05)
harvey    tty15                     Mon Jul 21 16:27 - 17:09  (00:41)

        The bad guy got our password file at 12:55 and by 13:10 he had
found the unprotected account and logged in.  Then he sent himself some
uucp mail and logged in again to read it, just to make sure it all works.
Soon after that I got wise to him and zapped the account.  It's only pure
blind luck that he hit upon an account which belonged to somebody who I
knew 1) didn't use dialup lines, 2) was on vacation, and 3) didn't use the
system much at all.  Had that account been somebody else, it might have
gone days before anybody noticed anything strange.

        Since my L.sys file is not readable by anybody except uucp, the bad
guy didn't get that.  From what I could tell, the bad guy was system
hopping, collecting passwd and L.sys files from each system he broke into
and using that to get to the next system.  Once I had this all figured out,
I called up the SA at cubsvax and told him what was going on.  He had never
heard of wjelny either, but it turns out that his L.sys was world-readable,
and that he also had an regular account without a password, which is how
the bad guy broke into *his* system.

        The epilogue to all this is that some time later, I just happened
to run uuname on another system I have an account on and saw wjelny pop
out.  A few phone calls later I had a real person's name to go with the
uucp login.  It turns out that the bad guy was somebody known to us.  I
called him up and after a bit of hemming and hawing on my part (not wanting
to unjustly accuse somebody of doing an evil thing) he freely admitted what
he did.  He claims that all he was doing was trying to test his uucp
software which had been giving him trouble and he really didn't thing there
was anything wrong with what he did!

        The take home lessons are several.  The first lesson is both the
simplest to describe and the hardest for people to accept: It CAN happen to
you!  Don't get fooled (like we were) into thinking that you don't have to
worry about security because you don't have anything on your system that
other people would want.  We've got scientific data on our system which
have not yet been published and which could, if given to the wrong people,
cause our scientists to be put at a disadvantage.  We've got patent
applications.  We've got salary information and labor negotiations.  We've
even got the usual collection of gossip and love notes.  It's easy to
imagine scenarios where any of the above could be wanted by a bad guy and
where the bad guy getting access to the information would be in some way
bad for us.  If you're a semiconductor manufacturer and you keep the design
notes for next year's new chip on line, you better believe there are some
people out there that want to get in to your system, but I don't have to
convince you; you already know that.  The people I have to convince are
those who think they are safe.  You're not.

        Second is that as much as you beg and plead with people to put
passwords on their accounts, there are still going to be people who don't
want them and won't use them.  They claim it's too much trouble, and
besides, they don't have anything in their accounts they have to protect
from other people.  Periodic scans of your passwd file for password-less
accounts is a must if you care about security.  Sending nasty mail-grams
when you find violators is a nice gesture, but essentially a waste of time.
If you care about security (and you should) be ruthless.  Zap those
accounts and make the people come crawling back to find out what their new
passwords are.  While you've got them in your office, give them a good
talking to.

        Third is that when you give out a uucp login to somebody, you have
to assume that the whole world will know it.  This is not to say that any
particular SA you give an account to is going to be careless or malicious,
but it does happen.  It may happen without his knowing about it.  It may
happen despite his best efforts to prevent it.  The way to minimize the
damage is to be careful about what files and directories are accessible by
uucp, and what commands are executable.  The way to give yourself a chance
of tracking down the bad guy when disaster does strike is to make sure that
each of your uucp partners uses a different login.  Maybe it's a pain to
administer and maybe it makes your /etc/passwd longer than it has to be,
but it's worth it.

        If you do suspect you have been broken in to, make copies of all
the accounting logs you can think of.  Even if you can't think of a reason
why you might need the information in a particular log file, save it
anyway.  Sometime later it may turn out to be important to be able to go
back and take another look.  In our case, it was only the correlations
between the uucp, mail, login, and process accounting logs that let us
piece together the whole story.

        Next week (after I dig out the copies of the logs I saved so I can
reconstruct the events coherently), I'll tell you all the story of how I
discovered that somebody was stealing Unix source code from us.

Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

"you can't spell deoxyribonucleic without unix!"


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

Path: isis!nbires!seismo!mcvax!inria!axis!matra!nd530!ma
From: ma@nd530.UUCP
Newsgroups: comp.bugs.4bsd
Subject: archive of 4.2bsd bugs. Bug in ptrace().
Message-ID: <281@nd530.UUCP>
Date: 25 Feb 87 14:11:59 GMT

[I found this one in comp.bugs.4bsd.  The author isn't on the list itself
but this seemed relevent and not everyone reads every newsgroup.]


1) Looking for an archive of bugs :
   ==============================

We will be glad to get a archive of all yet-reported bugs in 4.2,
in this newsgroup or anywhere else.
So, if anyone is able to tell me how we can get such a list
(or best, send it to me at:
                Matra Datasysteme
                R & D
                Parc d'activite de Bois d'arcy
                1 avenue Niepce
                78180 MONTIGNY LE BRETONNEUX
                FRANCE
                                )

thanks to her or him in advance.

2) Bug in ptrace() :
   ===============

Calling ptrace(2) with a pid < 0 is an easy way to crash
a 4.2 system (like a Sun 3 ).
Ptrace() does not check in the pid is beetween bound before
calling pfind() . Of course, we can say also that pfind()
does not check the pid before hashing it.



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

Date: Thu, 5 Mar 87 15:49:09 mst
From: pyramid!ptsfa!jmc
Subject: Security auditing program

As a new member to the list, I've got a few questions:

How good is the security auditing scripts in the UNIX System Security
book? Does anyone out there have enhancements or improvements?

One vendor at the recent UniForum claimed that some UNIX holes cannot
be tested for because testing for them will, in itself, open the system
up. Is this true? How does one deal with this situation?

What are people's experience with crackers? Are there a 10 most common
ways people can use to break into systems? Does this differ by version
(V.2 vs 4.3BSD)? Does anyone have a "cracker detector" that keeps all but
the top 1% from leaving no tracks around?




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

                        The UNIX Security Mailing List

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

END OF DOCUMENT