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' V1 #29 1989-08-16 (1 file, 5527 bytes)
NOTICE: recognises the rights of all third-party works.


Security Digest Volume 1 Issue 29


            CERT Internet Security Advisory
            Re:  programs owned by bin
            Re: Security tools
            Re: Security tools
            Re: Security programs
            holes via terminal emulators


Date: Wed, 16 Aug 89 11:45:34 EDT
From: Kenneth R. van Wyk <uunet!SEI.CMU.EDU!krvw>
Subject: CERT Internet Security Advisory

[ I put this digest out early because of this message - neil ]

Many computers connected to the Internet have recently experienced
unauthorized system activity.  Investigation shows that the activity
has occurred for several months and is spreading.  Several UNIX
computers have had their "telnet" programs illicitly replaced with
versions of "telnet" which log outgoing login sessions (including
usernames and passwords to remote systems).  It appears that access
has been gained to many of the machines which have appeared in some of
these session logs.  (As a first step, frequent telnet users should
change their passwords immediately.)  While there is no cause for
panic, there are a number of things that system administrators can do
to detect whether the security on their machines has been compromised
using this approach and to tighten security on their systems where
necessary.  At a minimum, all UNIX site administrators should do the

o Test telnet for unauthorized changes by using the UNIX "strings"
  command to search for path/filenames of possible log files.  Affected
  sites have noticed that their telnet programs were logging information
  in user accounts under directory names such as "..." and ".mail".

In general, we suggest that site administrators be attentive to
configuration management issues.  These include the following:

o Test authenticity of critical programs - Any program with access to
  the network (e.g., the TCP/IP suite) or with access to usernames and
  passwords should be periodically tested for unauthorized changes.
  Such a test can be done by comparing checksums of on-line copies of
  these programs to checksums of original copies.  (Checksums can be
  calculated with the UNIX "sum" command.)  Alternatively, these
  programs can be periodically reloaded from original tapes.

o Privileged programs - Programs that grant privileges to users (e.g.,
  setuid root programs/shells in UNIX) can be exploited to gain
  unrestricted access to systems.  System administrators should watch
  for such programs being placed in places such as /tmp and /usr/tmp (on
  UNIX systems).  A common malicious practice is to place a setuid shell
  (sh or csh) in the /tmp directory, thus creating a "back door" whereby
  any user can gain privileged system access.

o Monitor system logs - System access logs should be periodically
  scanned (e.g., via UNIX "last" command) for suspicious or unlikely
  system activity.

o Terminal servers - Terminal servers with unrestricted network access
  (that is, terminal servers which allow users to connect to and from
  any system on the Internet) are frequently used to camouflage network
  connections, making it difficult to track unauthorized activity.
  Most popular terminal servers can be configured to restrict network
  access to and from local hosts.

o Passwords - Guest accounts and accounts with trivial passwords
  (e.g., username=password, password=none) are common targets.  System
  administrators should make sure that all accounts are password
  protected and encourage users to use acceptable passwords as well as
  to change their passwords periodically, as a general practice.  For
  more information on passwords, see Federal Information Processing
  Standard Publication (FIPS PUB) 112, available from the National
  Technical Information Service, U.S. Department of Commerce,
  Springfield, VA 22161.

o Anonymous file transfer - Unrestricted file transfer access to a
  system can be exploited to obtain sensitive files such as the UNIX
  /etc/passwd file.  If used, TFTP (Trivial File Transfer Protocol -
  which requires no username/password authentication) should always be
  configured to run as a non-privileged user and "chroot" to a file
  structure where the remote user cannot transfer the system /etc/passwd
  file.  Anonymous FTP, too, should not allow the remote user to access
  this file, or any other critical system file.  Configuring these
  facilities to "chroot" limits file access to a localized directory

o Apply fixes - Many of the old "holes" in UNIX have been closed.
  Check with your vendor and install all of the latest fixes.

If system administrators do discover any unauthorized system activity,
they are urged to contact the Computer Emergency Response Team (CERT).


Date: Tue, 15 Aug 89 10:21:40 EDT
From: uunet!!chip (Chip Salzenberg)
Subject: Re:  programs owned by bin

Seth Robertson:
> The file is *not* truncated and the contents of the wall message put at
> the contents of the file.  Instead, the file remains as it is, except that
> the file is overwritten with some wall stuff and the mangled contents of
> your message.
> [...]
> You can imagine what would happen to a executable.  I would really
> have my doubts that the program would run, no matter how tricky you
> got...

Denial of service is still a real problem here.  But perhaps you forget that
shell scripts are executable as well.  Here's a way to use the hole:

Pick a program executed by root from a crontab; extra credit if the command
line includes "2>/dev/null".  Make a copy of that program.  Use wall to
overwrite it with a standard "cp /bin/sh /usr/hacker/sushi; chmod u+s
/usr/hacker/sushi; exit" Trojan Horse.  Wait until cron executes the Trojan
Horse.  A few "No such command" messages later, J.  Random Hacker is root.


Date: Tue, 15 Aug 89 10:32:39 EDT
From: uunet!!paul (Paul Sutcliffe Jr.)
Subject: Re: Security tools

In Security Digest Volume 1 Issue 28, [email protected] wrote:
| I am looking for a few programs that will help me tighten up security
| a little bit. I have heard about some of these programs, but I have not
| been able to find them in any of the anonymous FTP sites that I have
| looked at. If you have any of the following programs or know where I can
| get them, Please let me know.
| Here is a list of programs that I would like to find:
| [...]
| A getty that restricts logins only to those that are on an access list
| [...]

Personally, I think that checking usernames against an `access list'
should be login's job, not getty's.  A `freely redistributable' login
clone authored by John F. Haugh II <[email protected]> could be
modified to include this feature.  John's package also includes
passwd(1) and su(1), among others.  I've Cc'd John in case he wants
to comment.

Now, if someone (including John) could convince me that this feature
belongs in getty, I've written (and am currently beta-testing) a SYSV
getty clone that I will release (via UseNet's comp.sources.misc) when
it's complete.  Discussion?


Date: Tue Aug 15 20:18:48 1989
From: uunet!!rpp386.Cactus.ORG!jfh (John F. Haugh II)
Subject: Re: Security tools

> In Security Digest Volume 1 Issue 28, [email protected] wrote:
> +---------
> | [...]
> | A getty that restricts logins only to those that are on an access list
> | [...]
> +---------
> Personally, I think that checking usernames against an `access list'
> should be login's job, not getty's.

Quite correct.  getty hasn't authenticated the user yet, so getty
is incapable of determining if the user is authorized to perform
any operation.

A possible scenario is

login: okay_user
Password: <random password>
login incorrect
login: not_okay_user
Password: <correct password>
Welcome to okay_user's private port!

So much for that idea ...

Port restrictions are in the present version of my shadow login,
as are time-of-day restrictions as well [ I think. ]


Date: Wed, 16 Aug 89 09:53:21 EDT
From: uunet!teleng!gorpong (Gordon C. Galligher)
Subject: Re: Security programs

        In Volume 1 # 28 you ask for submissions of certain security
programs which exist out there to include in the automatic archives.
I don't have a program which checks security, but I do have a program
which enforces certain levels of security and monitoring facilities
It is written entirely in C, it has a README, Makefile, manual page,
etc.  There is a catch, it needs to be setuid in order to work.
It only stays setuid while it checks the restricted log files
and then immediately does a setgid/setuid to the specified user.

A quick synopsis is, you create an "allow" file with a list of the
monitored/restricted programs and who is allowed to access them.  In
that file is the directory to go to, and the command to execute as a
special user.  The applications are then linked (via ln(1)) to the main
program and that name becomes the monitored application in the allow
file and in the password file.  For example, I want to allow the use of
the mount/umount commands for non-root users, so I use the builtin
program to create/modify the "allow" file for mount.  I then have to
modify the password file to add the mount user and umount user.  I give
them unbreakable passwords (ie:  *) with the user-id of root.  I then
link in the 'mount' program with the main program and everytime I run
mount (which appears earlier in my path than /usr/etc) I am actually
running the monitored/restricted mount and not the /usr/etc/mount.

A better example is how we are using it at Telxon.  We have a number of
groups working on our products, and each of these groups is actually a
user on the system.  Prior to my employment the users just cd'd to the
special user and started modifying information.  The special user had
write priviledges for its group.  This is a potential security problem
so they decided to use the 'su' command to handle things.  Well, this
was just about as bad because the passwords were written down by
terminals and such so they could remember.  Now all they do is type
'opsys' and they are immediately logged as going into opsys, they are
placed in the opsys home directory, they become the opsys user, get
all of the groups that opsys gets (only in Berkeley, System V only has
one group at a time), and execute a /bin/csh.  It is effectively a
short-circuited 'su' program.  Granted, with this manner if their
terminals are left exposed then anyone can go into the opsys user, but
the users take better care of their own passwords than they did with the
special user passwords.

I apologize for all this verbosity, but if I only give part of the facts
then it looks more like a security HOLE than a security feature.  I have
asked quite a few people to try to break it, without success.  I can
send you the manual page and you can see if it is worth-while in the
archives, or by what you've read, you can decide that it is worthless.
Let me know if you want anything else and I'll be happy to oblige.

[ Please send the whole thing to zardoz!neil and I will put it in the
archives (which should be accessable real soon now, I promise) - neil ]


Date: Wed, 16 Aug 89 11:05:27 MDT
From: elroy!ames!ncar.UCAR.EDU!boulder!cadnetix.COM!rusty (Rusty Carruth)
Subject: holes via terminal emulators

In article <[email protected]> [email protected] writes:
>The trick of defining a command sequence to create sushi on a unix system would
>compromise root integrity... most comm software that is capable of either
>emulating programmable terminal sequences or ansi.sys and programs that implement
>those sequences are capable of accepting a command line into a buffer or window
>with the view attribute set to non-visible and then retransmitting that command
>to the host unix system all under remote control.... I could hardly call that
>harmless... furthermore most users including a surprising number of systems
>administration types are unaware that their terminal or programmable termulator/
>file transfer package can be tricked in this fashion..>
>p.s. sushi --> SuperUser SHell Interactive. the trick above is known as a
>boomerang also!!

I thought perhaps this should be something we were reminded of here on
the security-mailing list.  Sure, its not an alert or anything like that,
but given the comment above about 'a surprising number of systems admin
types' being unaware of this problem, it seemed to me like a good thing
to remind ourselves of.  (I got this article from the comp.virus newsgroup)


        End of Security Digest Volume 1 Issue 29