SunOS and shared libraries, security aspects

Wed Aug 29 13:39:33 AEST 1990

[ I'll also send this to security-alert at sun.com ]

In article <1990Aug27.171211.16272 at maverick.ksu.ksu.edu>, terry at eece (Terry Hull) writes:
>Hmmm.   If my memory serves me correctly, executables that are suid
>root and linked with shared libraries, must have those libraries in
>/usr/lib or /lib.  Could it be these executables are trying to find
>shared libraries in /usr/local/lib?  

The shared library path environment variable is not taken into account
if uid != euid.  This restriction exists to reduce the possiblity of
trojan horse-style shared libraries owned by the user and executed in
a privileged state.

It seems, however, that Sun has again hacked together and included in
their OS something without taking security aspects into account.  The
uid != euid check is not enough in current Unix systems; some programs
which are setuid set their euid to the uid to which they're suid under
and so the linker happily links in the user's own library (which could
have an interesting "malloc" which does system ("cp /bin/sh /tmp/sh;
chmod u+s /tmp/sh").

The problem is quite similar to the notorious IFS problem which
probably still lurks around in some systems.  I tried to think of a
few quick ways to exploit it and came up with only /bin/login -p sync
(preserver environment), if sync is an account with no password and
daemon id as a common convention is.  Works for any other non-password
account, also.  I remember somebody in alt.security earlier said that
the X programs can be used to exploit the problem.  Probably there are
programs with which you can exploit this in the standard distribution
as well, what come into mind (I haven't tested) are uucp programs and
rdist.

And on the subject of Sun-originated half-baked new security-hole
hacks, I'll bore you a bit with an old yellow pages hole which I think
I posted in September 1989 the first time to the net:

Well here's something that could cause flames beginning to burn me:
something about Yellow Pages I wrote last September (or perhaps
before, there was no date attached).  I slightly edited it to not make
it such an exact recipe it was.

[ written September 1989 by jkp at cs.hut.fi]

Something you don't want to know about the yellow pages

It appears that you can't win at all with SunOS 4.0.3c (and probably
all earlier versions, too) even if you're not running yellow pages.
Or for that matter with most Unixes using Sun's Yellow Pages.

Let's assume three machines; securemachine, evilmachine and
friendlymachine.  Also, let's assume that you have a normal account on
securemachine and root access to evilmachine.  You want to get root
access on securemachine.  You also know that there's the line
`friendlymachine root' on securemachine's /.rhosts.  Securemachine is
SunOS 4.0.3c which is not running YP.  I'll explain how you can get
the root access on securemachine if the domainname on securemachine is
set.

The relation of securemachine, evilmachine and friendlymachine is
irrelevant as long as they're on the same TCP/IP network; they don't
even need to be on the same continent.

Get SunOS 4.0.1 binaries for ypbind, ypset and ypserv or write your
own.  Modify ypserv so it used your own yp database instead of the
system's.  Make the database contain evilmachine's IP address with the
name entry as friendlymachine.

Start the modified ypserv on securemachine (doesn't need to be a
privileged process).  Start your own ypbind on securemachine.  Print
the domainname of securemachine - let's assume it's `noname' as it
often is when yp is not running.  Give the appropriate ypset command
from evilmachine as root with the 4.0.1 or your own version of ypset to set securemachine's yp server.

Give the command `rsh securemachine -l root sh -i' from evilmachine
and do your merry way.

This probably works also on other YP implementations and you don't
even need to give the ypset command from another machine.

FIX: I don't see a clean fix applicable to all cases.  Setting the
domainname to the null string seems to help, but I haven't checked it
deep enough.  I don't know if running YP helps; probably not, as the
portmapper didn't practice any access control last I looked (older
versions even allow you to remap things from a remote host !) so
anyone can just remap the ypserv to their own version.  Anyway, if you
choose to run YP, you're in another kind of mess altogether if you
don't have the latest versions (I don't know if 4.0.3c is good enough,
but I don't think it is).  Running the domain name server and using
the resolver libraries for host name lookup helps, but depending on
your flavor of unix the group, sendmail alias, services etc. files
might also be under YP.  They sure are on a Sun.

REAL FIX: Just fix the YP libraries to check that the ypbind process
is running on a privileged IP port (that is, between 513 and 1023) and
recompile all binaries.  While youre at it, fix the ypbind process to
bind only to ypserv processes which are on a privileged port on an IP
address which corresponds to a list stored in a local file.  What's
that, you don't have source ?  AARRGGGHH, time to reach for that PANIC
switch disconnecting you from the power network and CYFV (Call Your
Friendly Vendor) !!!

//Jyrki

Jyrki Kuoppala  Helsinki University of Technology, Finland.

[ Update: there are some `fixed' binaries provided by Sun; I don't
know how they change the situation.  Also, I don't know how SunOS 4.1
behaves. ]
-- 
Jyrki Kuoppala    Helsinki University of Technology, Finland.
Internet :        jkp at cs.hut.fi           [130.233.251.253]
BITNET :          jkp at fingate.bitnet      Gravity is a myth, the Earth sucks!
Newsgroups: alt.security
From: jkp at cs.HUT.FI (Jyrki Kuoppala)
Subject: Yellow pages (was: Re: SunOS uuencode / uudecode)
Message-ID: <1990May4.085957.22487 at santra.uucp>
Reply-To: jkp at cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
References: <1990May2.175128.23652 at santra.uucp> <1990May3.222439.23887 at agate.berkeley.edu>
Date: Fri, 4 May 90 08:59:57 GMT
Lines: 212

In article <1990May3.222439.23887 at agate.berkeley.edu>, shipley at soda (Peter Shipley) writes:
>In article <1990May2.175128.23652 at santra.uucp> jkp at cs.HUT.FI (Jyrki Kuoppala) writes:
>>There are serious problems with the uudecode program and the default
>>mail alias `decode' in SunOS.  The bugs aren't specific to SunOS; they
>>just occur on Suns because of stupid defaults SunOS traditionally has.

[ .. ]

>a bug!].  the setuiding of uudecode is a sun problem.  The only reasion
>for it is to stop the problems caused by the mail alias:
>
>    decode:	|/usr/bin/uudecode
>
>where you can overwrite deamon owned files. (no flames for posting
>that line please, I have seen it on the net before).

Well, you can overwrite files owned by anyone other than root as
well in most cases (networked machines).

The problem about telling holes still is how much to tell.  If you
don't tell what can be done with a hole, it's not easy for the reader
to decide whether the hole is serious enough to have a serious look
at.  If you tell what can be done, you are pointing way to abusers.

By the way, I have started keeping a list of security holes mentioned
in alt.security.  There hasn't been anything new in alt.security, but
the point is that now when the hole has got this much publicity it
finally can be considered public knowledge and can be discussed
without `being careful' who you discuss it with.  I'm planning to make
a list of alt.security-mentioned bugs with classifications and
directions for fixing the bugs.  Here's an example of the
classifications I've used:

Classification:

Is the hole external - internal to the machine:

HE - can be exploited external to the machine (external)
HI - can be exploited by first having a normal account on the
     machine

Exploiting methods (for external holes):

EN - via the TCP/IP network
ED - via decnet
EU - via uucp
EL - via normal login
EM - via sending mail

Privileges gained by exploiting the hole:

PS - by exploiting superuser status can be obtained in a few
     minutes or so (superuser)
PA - by exploiting status as any user can be obtained in a few
     minutes or so (any user); usually implies PS
PC - by exploiting status as one certain user (like uucp) can be
     obtained in a few minutes or so (certain user)
PH - no status can be acquired, but something possibly harmful can be
     done which normally couldn't be done (like reading a file or
     crashing the machine) (harmful)
PI - something possibly irritating can be done, like hiding oneself
     from programs like who, finger etc. or sending binary stuff
     to another user's tty

Reason(s) of the hole:

RG - general bad configuration manners from the vendor
RB - a bug in a program causing the hole (like overrunning a buffer)
RD - stupid design of a program or service causing the security hole
     (like the famous Sun rpc.rexd)
RA - bad configuration manners from the administrator

Fix availability:

FF - A correct version of the program is available as free source;
     depending on vendor the free version might not have all the
     same features as the vendor's version
FB - A binary fix is freely available from the net
FS - A source-level fix is available for free from the net
FV - A fix available from the vendor for the asking (not necessarily free)
FL - Fixed in the latest OS release (for OS-specific holes)
FN - No fix available short of closing the service / not running
     the program
FC - No program fix needed; changing of modes or configuration file
     is sufficient

OS environment / version:

OG - general Unix
OB - general Berkeley 4.3
OS - SunOS
OX - Xenix
OU - Ultrix
ON - Sony NEWS
O2 - System V rel. 2
O3 - System V rel. 3
O4 - System V rel. 4
OG - GNU programs
OU - programs posted on Usenet
OF - other free programs available by anon. ftp etc.
OC - other commercial programs

A list of holes of which a mention has been in alt.security:

- restore suid root security problem (sunOS 4.0 ->)
HI, PS, RD, OS

- NFS caches may put wrong data blocks in files - possibly exposing
  sensitive data
HI, PI, RB, FN, OB

- forging USENET messages and control messages (cancel, rmgroup etc.)
HE, EN, EU, PI, RD, FN, OU

- unrestricted tftpd
HE, EN, PI, RG, RD, RA, FC, OB

- sendmail < 5.61 security holes
HE, HI, EN, EM, PA, RB, FF, OB

etc., the list is not ready yet.

>Needless to say, I have received a bit of heat for posting bug
>information to this group.

Surprisingly, I haven't received much negative feedback from
publishing security holes (some time ago on the Sun-Spots mailing
list, also somewhere else I think).

Well here's something that could cause flames beginning to burn me:
something about Yellow Pages I wrote last September (or perhaps
before, there was no date attached).  I slightly edited it to not make
it such an exact recipe it was.

[ written September 1989 by jkp at cs.hut.fi]

Something you don't want to know about the yellow pages