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 #8 1990-03-03 (1 file, 10521 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Sat, 3 Mar 90 18:49:27 PST
Subject: Security Digest V2 #8

Security Digest Volume 2 Issue 8


            Catch 22
            Sun-3/80 Secure Boot PROM Rev. 3.0
            Re: Hacker signs
            Re: Hacker signs
            Re: Hacker signs (v2 n7)
            Re: Security Digest V2 #7 [ hacker signs, pty problem ]
            Re: Security Digest V2 #7 [ pty problem ]
            SunOS pty permissions problem
            pc-nfs and becoming nobody
            Re: PC-NFS (was: Re: SunOS pty permissions)
            Re: PC-NFS
            Seth Robertson's "hacker trap"
            Re:  Security Digest V2 #6 [ hacker trap ]
            Re: Hacker Trap
            FYI: DPMA Virus Clinic in NYC
            CFP: UNIX Security Workshop, August 1990

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.


Date: Mon, 26 Feb 90 17:18:49 EST
From: Gene Spafford <uunet!!spaf>
Subject: Catch 22

Federal law enforcement personnel, once interested in a break-in to
your computer system, will ask that you maintain the holes being used
so they can trace the crackers and obtain evidence.

This puts you in the uncomfortable ethical position of supporting the
continued computer abuse of the vandals involved.  Worse, it leaves
you open to criminal and civil prosecution.  I spoke with someone in
the U.S. Attorney's office Friday about an on-going situation I know
about, and was told that simply because you have been asked to
cooperate by law enforcement or intelligence agencies does NOT protect
you from criminal or civil charges.  Keeping a link open for a hacker
could result in state or federal charges (although the investigating
agency is unlikely to charge you).  It also leaves you wide open to
civil suits by any damaged parties.

No suits have currently been brought under these circumstances, but
the possibility exists.  Won;t that give you a warm fuzzy feeling
the next time you spot someone trying to break into your system?

Best advice so far is to get the request from the agent-in-charge
*in writing* and have him/her specify a specific date for the cut-off
of the hole/link.  Also, have your corporate legal counsel check your
business liability insurance to see if it covers losses as a result of
cooperating with law enforcement activities.  You might also write a
note to your Congress-critter about the situation.


Date: 14 Feb 90 11:57:28+0100
From: uunet!cgch!wwtz
Subject: Sun-3/80 Secure Boot PROM Rev. 3.0

When adding a password to the Rev. 3.0 Boot PROM on a Sun-3/80 to
achieve "comand secure" mode, i.e. only "b" for boot and "c" for
continue can be entered in monitor mode without supplying a pass-
word, I found the following problem:

when power cycling the 3/80 there is a small timeframe where one
can bypass the password protection simply by L1-A interrupt during
the selftest.

Sun Microsystems has been notified and they are considering this
beeing a bug. However, I don't know by when it's beeing fixed.

The problem does not occur on Rev. 3.0.1 PROMs on 3/60s.


Date: Mon, 26 Feb 90 10:56:16 EST
From: Gene Spafford <uunet!!spaf>
Subject: Re: Hacker signs

Shadow password files would be a major improvement and go a long way
towards protecting passwords.  If the hackers can't get your password
file, they certainly can't run the fast password code to break
accounts.  (Well, they can run it, but it won't help!)


Date: Mon, 26 Feb 90 09:29:02 CST
From: uunet!!phil (William LeFebvre)
Subject: Re: Hacker signs

> 3) Crackers have copies of *very* fast password code.

Would using shadow password files help in this regard?  How much harder
would that make it for them?

I've been seriously considering going to that.  It'll be a hassle to
do, but I'm beginning to think that it would be very worthwile.


Date: Mon, 26 Feb 90 10:25:55 -0500
From: uunet!!schwartz (Scott E. Schwartz)
Subject: Re: Hacker signs (v2 n7)

| From: Gene Spafford <uunet!!spaf>
| 1) Hackers know about this list and have placed a "premium" on getting
| copies of the list mailings.  If you have old copies on disk, encrypt
| them so that if someone does break in, they can't get them.
|       [ Please, please, please - neil ]

Unfortunately, they also know about the "Code Breakers Workbench",
available by ftp from uunet.  The unix crypt command is very very very
easy to break, especially given lengthy traffic with standard headers
like this list has.   It really is time for a DES based crypt(1).
(Ironically, we recently caught some intruders and had occasion to
use cbw to decrypt files that _they_ thought were safely encoded.  It
cuts both ways, I guess.)


Date: Mon, 26 Feb 90 10:21:53 EST
From: Paul Graham <uunet!!pjg>
Subject: Re: Security Digest V2 #7 [ hacker signs, pty problem ]

re: hackers trying to get copies of this list; i don't buy this, i've never
seen anything discussed here that didn't wind up being discussed somewhere else
and the serious problems i've been lucky enough to hear about i've not seen
discussed in this forum.  but it's no big deal to encrypt the stuff (and
apparently no big deal to decrypt using codebreakers workbench).

[ It was probably discussed here in detail, first 8-). There has
  previously been very detailed eplanations of how to use specific
  holes to crack systems on this list.  There are many systems that
  have not closed all of these holes.  Access to past issues of this
  list would pretty much guarantee baing able to crack a surprisingly
  large number of systems.  The "hole" business has just been very
  slow lately 8-) - neil ]

re: sun pty problem. on my 4.0.3 systems if you snoop on a pty you see the
login name but the user never sees the password prompt so it would only
be force of habit that would cause a user to reveal their password.  using
programs that do pty manipulation (e.g. xterm or screen) but not running them
suid strikes me as more of a risk.


Date: Mon, 26 Feb 90 14:00:45 -0500
From: Jeffrey A Law <uunet!!law>
Subject: Re: Security Digest V2 #7 [ pty problem ]

In article <[email protected]> you write:
>cat </dev/ttyp? &
>this will work if the ? is an inactive terminal.  All tty's are apparently set
>at ugo+rw prior to someone logging in.  You can add a simple routine to the
>logout program that will leave the privs on these tty's as ug+rw and that will
>keep most folks out.

just after 4.0 came out we had similar problems with users sending out
codes to open/close windows on remote machines in a  'random' order.  I
wrote code that would  lock out terminals in the following manner:
whomever owned the console would own the first 32 ptys (except any one
listed in utmp with someone active on it)  anyone in utmp and active
would own their own terminal.  the last 16 were left as 'unsecure' ttys
(for things like remote user wants to run script, whatever)   anyways, the
fad eventually passed and the code stopped being used at 4.0.3...
if anyone wants to bring this kluge back buzz me [email protected]


Date: Tue, 27 Feb 90 13:02:12 MST
From: uunet!cadnetix.COM!rusty (Rusty Carruth)
Subject: SunOS pty permissions problem

In Security Digest V2 #7,  Bill Wisner <uunet!!wisner> says:

>cat </dev/ttyp? &
>this will work if the ? is an inactive terminal.  All tty's are apparently set
>at ugo+rw prior to someone logging in.  You can add a simple routine to the
>logout program that will leave the privs on these tty's as ug+rw and that will
>keep most folks out.

Hmmm.  Thats pretty interesting.  I tried it here (sun3/50 running
"SunOS Release 4.0.3 (GENERIC) #1: Mon Apr 24 14:51:08 PDT 1989"), and
all that happened was to hang the tty I tried it on.  (Tried on ttyp6)

All I got on the window which had the 'cat' going was:
 'rustyrustysun/9600' in one case (and the cat got killed when the connection timed out)
 'rustyusersun/9600' in another (same remark about cat dying).
And the  attempt to log in on that port died after 60 seconds ('Login timed
out after 60 seconds \n Connection closed')

On a totally different subject:

[ Please put different subjects in seperate postings, so that I can group
  postings by subject in the digest. - neil ]

Subject: pc-nfs and becoming nobody

A while back there was some discussion about becoming nobody via pc-nfs.

While attempting to verify that problem here, I noticed that pc-nfs will allow
you to 'use' through a directory in which you do not have permissions.

For example:

On 'broken' is the following file:


/home        is rwx all (not that it matters)
 protected   is rwx ONLY for the owner, not read or write or exec for anyone else
 junk        is rwx all (or r-x all)
 data        is readable by all (or rw or rwx)

The owner is, for example, root.

Now, as 'user' on the pc, do 'net use s: \\broken\home\protected\junk'
Now you would expect that to fail.  Nope, it does not, and your permisisons
on 'data' are as if 'protected' were rwx all (i.e. normal restrictions from
directory junk).  I think you can even use to 'protected' and cd to junk
and continue on your merry way.


[ No, the moral of the story is: DON'T put any protected directories
  under a directory specified in /etc/exports.  Through PC-NFS or
  through Unix NFS, non-readable sub-directories can be traversed for
  other mount points. - neil ]

If someone would like more info on release levels, etc, email me.
I have not reported this anywhere else because I'm not too sure where
else to report it!

[ Reporting it here makes sure that it read by some of the security
  software people at Sun. - neil ]


Date: Wed, 28 Feb 90 15:02:54 EDT
From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
Subject: Re: PC-NFS (was: Re: SunOS pty permissions)

# Now, as 'user' on the pc, do 'net use s: \\broken\home\protected\junk'
# Now you would expect that to fail.  Nope, it does not, and your permisisons

No, you wouldn't.

# on 'data' are as if 'protected' were rwx all (i.e. normal restrictions from
# directory junk).  I think you can even use to 'protected' and cd to junk

No, you've mounted JUNK, NOT protected.  You cannot do s: and then try to
cd .. because junk IS the root directory.  If you mount protected, you cannot
see junk, and therefore cannot cd to it.

# and continue on your merry way.

Wrong.  I don't think you understand the mounting facilities of NFS.  What
is happening is this:  the PC is sending an RPC request to machine 'broken'
to see if it has access to mount the directory /home/protected.  The machine
broken checks it's exports table and says, "Sure, you can mount it."  So,
you now have a mounted directory.  Can you DO anything with that directory?
NO!  When you try to do something, the PC sends an RPC request to machine
'broken' which says:  "Hey, can I create a file?  My uid is -2, my gid is -2."
Broken then responds with:  "Nope, you don't have permissions."  Even if you
try to do a directory listing it won't let you.  If you do a dir, do you see
'junk' which is globally writable/etc?  No, you don't.  The PC asks 'broken'
if you have Search permission on the present directory, and 'broken' responds
with "Nope."  If there is a file in that directory which is writable you still
cannot write to it, because the parent isn't writable, and DOS doesn't know
about it.

On the other hand, if you DIRECTLY mount a directory which IS writable, no
matter WHAT the permissions on any of the parents, then you CAN list the
directory, create files, delete files, etc.  I believe this scheme makes sense.
It is not an error, it is exactly what you told it to do.  This will
facilitate the ability to have UNIX directories which no one can see, while
allowing certain PC's to mount them (certain -access in the exports file).
This can allow you to buy a 3-user license for certain software, put it on your
UNIX networked host, and then by using the exports file, restrict it to ONLY
three PC's which can mount it at any one time!  No one else on the UNIX side
can see the directory, no other PC's can mount the directory, and even if they
mount the parent directory it won't do them any good because they cannot get
into the restricted directory.


Date: Sat, 3 Mar 90 18:25:38 PST
From: neil (Neil Gorsuch)
Subject: Re: PC-NFS

Rusty Carruth told how a sub-directory of a non-traversible
sub-directory of an NFS mountable directory can be mounted by PC-NFS.

Gordon C. Galligher responded:
} Wrong.  I don't think you understand the mounting facilities of NFS.

Yes, it is the way that all NFS works around here, whether PC-NFS or
Sunos client NFS.  But that is a problem of NFS that should be fixed.
Imagine this not that unlikely case:

in /etc/exports:
/home   -secure,access=clients

User neil has a home directory /home/neil with 700 permissions.  User
neil has various sub-directories with mode 777 including a src directory.
User neil thinks that his sub-directories are safe!

A PC-NFS user guessing that user neil has a src directory does:

> NET USE F: \\uninet\home\neil\src

And he can now read or modify user neil's src directory!

} On the other hand, if you DIRECTLY mount a directory which IS writable, no
} matter WHAT the permissions on any of the parents, then you CAN list the
} directory, create and delete files, etc.  I believe this scheme makes sense.

I disagree, network clients should not be able to do things that users
on the server machine can't do.  File system access permissions should
be consistant.  If I, as a user of a unix system, try to access files
in a sub-directory of a protected directory, and cannot do so, the same
should be enforced by NFS.  All forms of file access should have to
have permissions to go through all parent directories, otherwise
system administrators could set up inadvertant security holes.

I knew there was a reason I put this in my .logout file 8-) :

nice find ~ \
        '(' -perm -40 -o -perm -20 -o -perm -10 -o \
            -perm -4  -o -perm -2  -o -perm -1 ')' \
                -exec chmod go-rwx '{}' ';' &


Date: Wed, 14 Feb 90 22:26:15 est
From: Brian Rice <uunet!DG-RTP.DG.COM!rice>
Subject: Seth Robertson's "hacker trap"

I have several comments about Seth's posting.

COMMENT #1 (technical):
    Seth suggests as an improvement obtaining the IP address of the
    home machine of the person logged on.  He has gotten the first-
    approximation solution right; his script executes the netstat -n
    command.  One of the tcp connections on local port #23 will
    be the present user; the Foreign Address column will give the IP
    address and port number, like so: .

    Unfortunately, finding which of those connections is the person
    in question is not so simple.  The only ways I can think of to
    it require having sources and hacking them, so instead we should just
    finger all of them.  On Unix systems, that goes a little like this:

-----------------------clip here--------------------
AWKPROG='/^tcp.*ESTABLISHED.*/ {print $5}'

netstat -n | awk "$AWKPROG" | cut -d- -f1 | cut -d. -f1,2,3,4 > /tmp/hosts$$
# Some netstats separate the port number from the IP address with a - .

cat /tmp/hosts$$ | ( while read line
                          finger $line >> /tmp/magicfingers
                     done )
-----------------------clip here--------------------

    or something like that (I haven't tested that fully, so don't treat it as

    But I'm not sure this would be of value against an actual system-cracker.
    All one has to do is to walk up to some secluded workstation on the
    Internet, reset it, and come up in single-user mode as the superuser.
    Once there, one may cause the machine to pretend to be any unassigned IP
    address on the current network one wishes while mischief is being
    done.  So if someone chose this tactic to launch a worm, say, his or her
    path would only be traceable to 'root' (or its non-Unix equivalent)
    on some machine on a certain network.

COMMENT #2 (also technical):
    Seth also asks if there is anything insecure about his program.
    I myself wouldn't use it without blocking ^\, since if a user isn't
    going to be allowed to use my system, he or she shouldn't be allowed
    to write core files on it; a simple signal(SIGQUIT,SIG_IGN) at the
    beginning of his C program should narrow the window acceptably (but
    not close it entirely), or one might have guest's home directory be
    on a read-only file system.

    I'd also be wary of that "guest: not found" business; coming as it
    would after the system banners, that would make everyone who saw it
    assume that this system had something special to hide.

COMMENT #3 (ethical):
    Seth assumes that anybody who tries to log on to his system as guest is
    someone perpetrating a "class one" (whatever that means--sounds awful)
    security violation.  I think this assumption is naive, since it will mean
    one whole hell of a lot of "class one security alerts."  Further, I think
    it's mean-spirited.  Surely everyone reading this was once a kid new
    to networking; is it really a suspicious act merely to log in to a
    remote system as guest?

    Seth's point, of course, is that guest will be the first thing any
    system-cracker will try--this is a point well-taken.  But I really
    think that, given that 95% of the people who trip this "security
    alert" will be undergraduates who have just discovered telnet and
    are taking it out for a spin, his response does not have the right

    I would suggest that instead of sounding a Maximum Red Alert, this
    program merely print a message to guest which says, "Sorry; use of
    this computer is restricted to authorized users.  If you have a
    legitimate use in mind and are connected to this institution, request
    an account by contacting <X Administrator> by phone or paper mail."
    The script should, of course, record whatever information is readily
    available about the incident, but it should not get everybody in a lather.


Date: Tue, 20 Feb 90 14:27:02 -0500
From: uunet!cs.UMD.EDU!cml (Christopher Lott)
Subject: Re:  Security Digest V2 #6 [ hacker trap ]

About the "hacker trap" : I think that using a shell script is
a very bad idea.  Now that I say that, I'm unable to come up with
solid facts why....  Anyhow, a trap is not a bad idea, but a more
suitable implementation would be written in C, with careful
attention to signal handling.

Also, the login "guest" is, IMHO, a poor choice.  Having a guest
login sounds somehow friendly to me:  it implies that the system in
question encourages guest logins.  Try perhaps "system" or "service"
or "<vendor-name>" or even "toor" on some unixes.

Lastly, regarding the request that this journal not be made available
to the public:  a Good Thing.  BUT, there hasn't been anything on this
digest of any danger that I can remember in quite a while.  We get CERT
warnings, which are so vague that you're not even certain of the nature
of the problem, never mind knowing vendor, software, and good details.

[ Again, there have been very explicit discussions of major security
  holes on this list.  The "holes" business is slow lately 8-) - neil ]

Maybe all the holes have been fixed!  :-) :-)


Date: Thu, 22 Feb 90 19:51:39 PST
From: uunet!xanadu!wjr (Bill Richard)
Subject: Re: Hacker Trap

> First: Does anyone see anything that is insecure about this?

Yes.  It means an easily-guessed i.d./password combination which
opens files over NFS for users on other (potentially insecure
machines on your network.

You might want to mention that to the mailing list moderator.


Date: Sat, 03 Mar 90 18:07:20 EST
From: Gene Spafford <uunet!!spaf>
Subject: FYI: DPMA Virus Clinic in NYC

What: 3rd Annual Computer Virus Clinic
Sponsored by: DPMA, Financial Industries Chapter

Dates: March 14 & 15, 9-5 both days
Place: New York World Trade Center

The Clinic (workshop) will have two tracks, one for managers and one
for security technicians.  All attendees receive a copy of the clinic

The second day will feature presentations on current virus protection
products including demonstrations and ratings.

Scheduled speakers:
   March 14
        Stephen Purdy, U.S. Secret Service
        Sally Meglethery, NY Stock Exchange
        Dennis Steinauer, NIST (NBS)
        Eugene Spafford, Purdue University
        Thomas Duff, Bell Labs
        Jon R. David, Systems R&D
        Ken van Wyk, Computer Emergency Response Team (CERT)
        Sanford Sherizan, Data Security Systems
   March 15
        Dick Lefkon, Citicorp
        Gail Thackeray, Arizona Asst Attorney General
        Fred Cohen, A. S. P.
        Pamela Kane, Panda Systems
        Mark Rasch, U.S. Attorney's Office
        Marc Rotenberg, CPSR
        Donn Parker, SRI International
        Harold Highland, SUNY

Cost: $275 for 1 day
      $375 for both days
      $100 discount for full time students & academic faculty from
        accredited institutions

      Fourth attendee from a group is provided with complimentary

To register, call 800 835-2246, operator 190.


Date: Tue, 13 Feb 90 12:43:34 -0500
From: Matt Bishop <uunet!!bishop>
Subject: CFP: UNIX Security Workshop, August 1990

Call for Papers:  UNIX Security Workshop

Marriott Hotel, Portland, OR, August 27-28, 1990

     The Second UNIX Security Workshop is to be held in Portland, Oregon, on
Monday and Tuesday, August 27 and 28, 1990.  Matt Bishop will again be
chairing this workshop.  It will bring together researchers in computer
security dealing with UNIX and system administrators trying to use UNIX in
environments where protection and security are of vital importance.  It is
intended to provide an environment where researchers can discuss their latest
results, where researchers and practitioners can discuss the applicability of
those results to practical problems, and where system administrators can share
their unique solutions and techniques for dealing with problems.  The topics
covered by this workshop include both theoretical topics and everyday
problems.  We expect each participant to present unique attributes of his/her
environment and/or research and contribute a short (five minute) discussion
(and paper) detailing some result or solution from their environment or work.

Some topics to be considered include:

  o modeling the UNIX operating system theoretically
  o password security (password file integrity, enforcing choice of a safe
      password, spotting and handling crackers)
  o network security (problems arising from logins over an unprotected
      Ethernet, containing a break-in to one machine in a networked
  o security in a distributed system or environment
  o file system security (auditing packages, security in an NFS environment)
  o computer worms, viruses, and other phenomena
  o new designs to obtain C-level (or better) certification
  o making existing UNIX systems more secure, and locating and fixing UNIX
      security problems
  o any other problem or contribution that participants make.

Workshop Format

     This gathering will follow a ``workshop'' format rather than a ``paper
presentation'' format.  Please submit a one or two page summary describing a
problem and, if you have one, a solution or if not, a possible approach or
approaches which looked promising but failed (or which you have not yet
tried).  Also, be sure to include with your submission a set of five (or so)
topics that you'd like to hear about.  It is possible that some participants
will not present their papers at this workshop.

     The workshop chairman will collate the papers to schedule sessions which
have appropriate audiences.  It is anticipated that some sessions will include
all participants though others may require breaking into smaller groups.  Send
your submissions to the address below by May 22, 1990.

For further information, contact:

Matt Bishop
Dept. of Mathematics and Computer Science
Bradley Hall
Dartmouth College
Hanover, NH  03755

(603) 646-3267
[email protected]


        End of Security Digest Volume 2 Issue 8