The 'Security Digest' Archives (TM)

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

ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #8 1990-12-21 (1 file, 5010 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Fri Dec 21 15:34:42 PST 1990
Subject: Core Security Digest V1 #8

Core Security Digest Volume 1 Issue 8


            HP-UX binmail problem
            Sharied library paths under SunOS 4.1
            X security (fwd)
            Re: Suns 4.1 problems with X (fwd)

The unix core 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 at the very least.

PLEASE POST TO:                              [email protected]
PLEASE SEND REQUESTS TO:             [email protected]


Date: Tue, 18 Dec 90 22:23:39 MET
From: Edwin Kremer <[email protected]>
Subject: HP-UX binmail problem

  We're experiencing a security problem with "/bin/mail" on the HP9000
series 300 systems running HP-UX 7.0. I won't call it a security hole
in a sense that we all have to get paranoid right now, but at least
it's a nasty privacy hole (that might become a security hole, depending
on how sensitive the stuff is that you're mailing).
  After some thoughts I thought this should appear on Neil's inner security
list for new, unfixed holes. Maybe you consider this an overkill, in that
case: sorry. Please correct me if I'm wrong.

To start with the background information you need, this is what
"/bin/mail" looks like:

	-r-xr-sr-x   2 bin      mail      106496 Oct 12  1989 /bin/mail

The mail spool directory "/usr/mail" is of course:

	drwxrwxr-x   2 bin      mail       13312 Dec 18 21:11 /usr/mail

Any mailbox in "/usr/mail" looks like:

	-rw-rw----   1 root     mail        1444 Dec 18 17:43 /usr/mail/root

  Ok, the scheme for local mail delivery is easy: some mail user
agent (mailx, Elm, GNU Emacs's RMAIL, ...) calls "/usr/lib/sendmail"
which in turn calls "/bin/mail" (from now on referred to as "binmail")
for local mail delivery.

  Binmail appends to the mailbox in "/usr/mail" if it exists. No problem.
If the mailbox DOESN'T EXISTS, binmail creates it. Looks good, but...

  Imagine the following scenario: user "badguy" sends a message to another
user "victim". User "victim" doesn't seem to have a mailbox in "/usr/mail".
"badguy" uses mailx (any other MUA will do [calling binmail directly also
does the trick]) to compose his message; mailx calls sendmail, which in
turn calls binmail. As soon as binmail runs, it runs with euid=badguy,
  Binmail creates "/usr/mail/victim": this file is now owned by "badguy". Now
binmail does a 'chown("/usr/mail/victim", victim, mail)'. However, in the
meantime (the small amount of time that he owned the mailbox) "badguy"
could have done anything he wanted with it. Various options surely spring
to mind...
  Experiments showed that in appr. 80% of all cases you're quick enough
to do something nasty with the mailbox. Running binmail "nicely" increases
this percentage of course.

  Note that this problem _only_ occurs if the mailbox doesn't exist. Well,
why doesn't it exist then?? Because some MUA's can be configured to unlink
the mailbox if it is empty (GNU's RMAIL does, mailx might, Elm might).

I got around this problem temporarily by doing the following:

	1) trying hard to configure all MUA's __not to__ remove the mailbox
	   if it is empty. That is really hard, because users can easily
	   change that back in there own init files (~/.elm/elmrc, ~/.mailrc)
	   but in that case they just have to blame themselves.
	2) making the creation of an empty mailbox with the right permission
	   part of my "installing a new user" script.

Unfortunately, I don't have the HP-UX source code, so I can't dig any
further trying to get around this problem. I hope you can help, if
there's anything I can do, feel free to ask...


Date: Wed, 19 Dec 90 04:48:12 -0800
From: [email protected]
Subject: Sharied library paths under SunOS 4.1

There is a problem with the way sharied libraries are handled in SunOS
4.1 and the config files for x11r4 and mh-6.7.  One of the changes
between 4.0 and 4.1 is in the way the sharied libraries paths are
handled.  This difference unfortuately presents itself as a security

NOTE: this is not a bug or a hole in SunOS!!!

>From the SunOS 4.1 manual page for ld(1):

          Add dir to the list of directories in which  to  search
          for  libraries.


	  When building a program in which one or more objects are
	  loaded when  -Bdynamic is in effect, those directories
	  specified by -L options will be "remembered" for use at
	  execution  time.


	  Note  that such directories are retained in exactly the form
	  specified in  the  option, which  means  that  relative
	  directory  specifications (i.e., not beginning with "/") will
	  be evaluated  relative  to the current directory when the
	  program is run, not just during the operation of ld.

Unfortunately there are many program that use relative paths in there
library path specifications.  This normally would not present a problem
except in the case of programs that are setuid to root (or any other
userid).  This if a program was compiled with the line:

		cc prog.c -o prog -L../lib

The program will search the directory ../lib before searching the
directories /lib /usr/lib or /usr/local/lib.  This situation presents
itself as a serious security problem since any user can create a file
"../lib/" (where "libname" is a name of a library that
prog loads at runtime) thus permitting the user defined code to be
loaded in the executable and run.

Two software packages that fall into thus situation are the X11
windowing system (release 4) and the rand mail handler (version 6.7).

The best way to detect this is to trace the programs and watch for the
accessing relative directory paths.

for example:
   % mkdir lib test
   % ln -s /lib/ lib
   % cd test
   % trace prog
    open ("/usr/lib/", 0, 021044) = 3

    [... deleted text ...]

    open ("../lib", 0, 01567340000) = 3
    fstat (3, 0xdfff7b8) = 0
    mmap (0xde02000, 8192, 0x3, 0x80000012, 4, 0) = 0xde02000
    getdents (3, 0xde00100, 8192) = 60
    getdents (3, 0xde00100, 8192) = 0
    close (3) = 0
    open ("../lib/", 0, 01567347240) = 3
    read (3, "".., 32) = 32
    mmap (0, 409600, 0x5, 0x80000002, 3, 0) = 0xdd76000
    mmap (0xddd6000, 16384, 0x7, 0x80000012, 3, 385024) = 0xddd6000

    [... deleted text ...]

    exit (0) = ?

The X11 Windowing system has several setuid root programs (xterm and
sometimes the X server).  The best way to remedy this is to either
install the X libraries first then recompile with the -L option deleted
from the Makefile (as opposed to compiling the binaries staticly as
suggested in other postings).

Another system that has this problem is the Rand Mail Handler version
6.7.  When compiled for the Pop mail system option inc, msgchk, popwrd,
and pops are installed setuid to root.

The reason inc(1) msgchk(1) are setuid to root is so that it can use a
privileged port for the RPOP protocol.  Thus it is safe to remove the
setuid bit from the mh binaries if you are not running pop mail system.
Or, of course, you can recompile without POP defined in the config file
(unfortunatly POP is defined in the default config file).  This problem
will be fixed in the next release.

If you have to run with POP I suggest or fix uip/Makefile yourself.

If anyone else knows of any software packages that have this problem I
will be interested in hearing about it.

It is my recomindation to Sun that the "-Lload_path" be discontinued as
a compiled in sharied library load path and that they add an new option
for explicately defining a compiled in sharied library load path.


Date: Fri, 21 Dec 90 13:00:41 CDT
From: [email protected] (Bryan Koch)
Subject: X security (fwd)

I received the following message today from the person responsible for
installing X-windows software in our field organization.

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

MIT has finally publically acknowledged that dynamically linked setuid root
programs, like xterm, have a potential security hole that will allow a user
to gain superuser access.  Basically, a user can impose their own X library
in front of the default distributed lib via an environment variable. By
trapping any well-known library call in their own, they can theoretically
run  as root.

	Our xterm is vulnerable.

	You may wish to remove setuid from xterm.

Also vulnerable are xload and xcpustate. These programs require access to
/dev/kmem; they should be altered to be setgid, owned by group kmem. There
may still be risk in these programs.


Date: Fri, 21 Dec 90 15:28:04 PST
From: neil (Neil Gorsuch)
Subject: Re: Suns 4.1 problems with X (fwd)

[ This was posted in and re-posted in - neil ]

There is a security problem with certain X clients running under SunOS
4.1.  The problem only affects setuid programs that have been linked
with relative -L shared library paths.  xterm and xload are possible
candidates, from the core MIT X distribution.  IF you are using shared
X libraries, AND you have installed xterm and/or xload as setuid
programs, then please do one of the following:

Option 1. Relink the program statically (using -Bstatic).  For example, in
	  the R4 xterm Imakefile, change the line

NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB))


NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),-Bstatic XawClientLibs -Bdynamic,$(TERMCAPLIB) $(PTYLIB))

	  and in the R4 xload Imakefile, change the line



LOCAL_LIBRARIES = -Bstatic XawClientLibs -Bdynamic

Option 2. Make the program non-setuid.  You should consult your system
	  administrator concerning protection of resources (e.g. ptys and
	  /dev/kmem) used by these programs, to make sure that you do not
	  create additional security problems at your site.

There is a third option, which is to link the programs only with absolute
library paths.  This only works if reasonable versions of the libraries are
already installed at the time that you link the program.  Since this option
introduces possibilities of link errors (depending on your environment), and
it is poor build practice to forcibly install libraries except during an
install phase, I am not providing Imakefiles details for this option, but
you may want to consider this option (given that Option 1 has a performance
penalty) if you do not feel comfortable with the consequences of Option 2.

If you have questions about how to correct this problem at your site, please
feel free to send me mail about it, and I will try to answer as best I can.
We will try to correct this problem in the R5 build procedures (although
personally, I think Sun made a big mistake in creating this hole, and the
correct fix is to patch SunOS 4.1).

				Bob Scheifler
				Director, MIT X Consortium
				[email protected]


        End of Core Security Digest Volume 1 Issue 8