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 #32 1989-09-05 (1 file, 6472 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/132.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Security Digest Volume 1 Issue 32

subject(s):

            Workstation security
            Ultrix, r-commands, and the DNS
            rlogind/rshd broken by nameserver spoofing in in-addr.arpa domains &fix
            giving-away files
            Re: giving-away files
            Re: Ultrix 3.0 mount
            Re: Two security problems with Ultrix 3.0
            Two security problems with Ultrix 3.0
            Two security problems with Ultrix 3.0
            Re: nameserver security hole
            hosts.equiv stupidity
            list ramblings
            password shadowing

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

Date: 05 Sep 89 21:39:33+0200
From: uunet!iis!prl
Subject: Workstation security

to the moderator,
        Neil, I'm not sure whether this should be published.

[ Every time I put out this digest, I wonder if particularly nasty
bugs should be sent out.  But I always conclude that it's better to
try to inform a select group of system administrators of a problem and
risk letting a few bad apples see it, than to try to hide things which
doesn't work in the long term anyway. - neil ]

        The hack involves copying /vmunix to /tmp/vmunix, patching
        suser() in the copy of the OS so it always returns true,
        and rebooting /tmp/vmunix. This is much simpler than
        other boot-monitor style hacks (eg. patching the credentials
        in the U-area and continuing). Most machines can't stop you doing
        this; the new boot proms on Suns are a happy exception.

        The conditions which make this a problem are:
        1) Access to the machine console - easy for most workstations
        2) /tmp is a directory on the root file system - true for
                most workstations, there is probably some chance
                that on a quiet workstation it would be possible to
                umount /tmp anyway.
        3) /vmunix is readable, or I can import my own copy of /vmunix
        4) There is some boot monitor command which allows me to boot
           a named kernel, in a directory other than /
]

A message which I mailed in response to a question about `How can
I secure a DECSTATION against single-user boot-up' has been posted
to comp.unix-wizards.

In it I state that it is possible to break into Sun workstations as root
even if they have the console set as not secure (which means they
run `/bin/login root' rather than `sh' in single user mode).

It wasn't my intention that the person I gave this advice published it.
(I didn't explicitly tell him, either, so I guess that's my fault).

It is, unfortunately, true. It is also true for most other workstations.

Since most manufacturers do not have a fix for this problem I do
not wish to publish details of the bug.

I have sent in bug reports about this problem to Sun (who have a fix)
and DEC (who said that it will be fixed in new models only, no ECO).

I also reported it to CERT, but never heard anything back.

On Sun workstations, you can prevent this (and some other potential breakins)
by:
        1) Installing boot prom version >= 2.7.1; on 3/80's you
                will need prom version >= 3.0
        2) Putting a password in the boot prom as described in
                the SunOS 4.0.3 documentation
        3) Making /dev/eeprom non-readable, and making sure
                there aren't sneak paths to read it (eg. fingerd running
                as root :-)

On other workstations you will have to ask your manufacturer if there
is a way of preventing all operations from the console apart from the
standard power-up bootstrap.

I'm afraid that in most cases, the answer will be no.

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

Date: Wed, 06 Sep 89 07:45:35 EDT
From: uunet!umiacs.UMD.EDU!steve
Subject: Ultrix, r-commands, and the DNS

   The r-command security problem suggested by unclejack.crd.ge.com!barnett
is indeed a problem, though I don't think it's specific to Ultrix.  If
someone abuses some in-addr.arpa domain somewhere, it seems to me that they
can get in.  The idea is that domains get delegated by the folks at the NIC
to supposedly responsible people.  Those people then delegate authority
further, again to supposedly responsible people.  With luck, there are no
bad apples in the bunch.  I'm a pessimist:  I'm sure that someone will use
this attack someday.

   One possible defense would be to do a gethostbyaddr on the incoming IP
address, then do a gethostbyname on that name to get a list of IP addresses.
Check the incoming IP address against the ones the nameserver (or YP or
/etc/hosts, if you're unfortunate) hands back to you, and if the incoming IP
address isn't listed, say no.

   For example, let's say that I hack the 120.8.128.in-addr.arpa domain so
that 3.120.8.128.in-addr.arpa (the address of my workstation) corresponds to
decwrl.dec.com.  If someone has a .rhosts file somewhere with decwrl.dec.com
(possibly with some user name) in it, I'm in:

        I rlogin later.dude.org -l bogon.
        rlogind on later.dude.org gets my IP address (128.8.120.3) in
                accept(), and uses gethostbyaddr to turn that back into a
                host name (in this case, decwrl.dec.com).
        rlogind on later.dude.org checks bogon's .rhosts file, and sees
                that decwrl is in there.
        rlogind on later lets me in.

   In my modified scheme, we'd have:

        I rlogin later.dude.org -l bogon.
        rlogind on later.dude.org gets my IP address (128.8.120.3) in
                accept(), and uses gethostbyaddr to turn that back into a
                host name (in this case, decwrl.dec.com).
        rlogind does a gethostbyname on decwrl.dec.com, and gets back
                16.1.0.1 as the one and only IP address for decwrl.
        rlogind compares 128.8.120.3 to each element in the list of
                decwrl's IP addresses, and fails to find a match.
        rlogind replies, ``intruder alert'', closes the connection, and
                syslogs the details at high priority.

   Does this seem reasonable?  Is it worth hacking this into existence?
The code would be trivial...

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

Date: Wed, 6 Sep 89 14:32:13 -0400
From: uunet!MIT.EDU!jon
Subject: rlogind/rshd broken by nameserver spoofing in in-addr.arpa domains &fix

[ This was was mailed to security-request, rather than security, and has
been languishing in my security mailbox for a while - neil ]

This brings up a very important point.  DNS names and IP addresses
should *never* be used for authentication.  They are easily forged or
faked in a variety of circumstances.  The only real solution is to
never trust DNS names/addresses and use something like Kerberos.

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

Date: Wed, 6 Sep 89 09:23:27 PDT
From: Russell Brand <uunet!lll-crg.llnl.gov!wuthel!brand>
Subject: giving-away files

>I intend to write a setuid-root C program, which makes the following
>checks:
>       1) The user invoking must own the file that is being given away
>       2) The user invoking must own the directory containing the file
>       3) Files may only be given to user IDs greater than 100
>       4) Any setuid/setgid bits will be stripped.


Your should realize that #2 doesn't do as much as one might think.

        ln directory-I-do-not-own/file-I-wish-was-not-mean ~/
        give-away ~/file-I-wish-was-not-mean

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

Date: Wed, 06 Sep 89 14:21:36 -0400
From: uunet!cs.brown.edu!jb
Subject: Re: giving-away files

>I intend to write a setuid-root C program, which makes the following
>checks:
>       1) The user invoking must own the file that is being given away
>       2) The user invoking must own the directory containing the file
>       3) Files may only be given to user IDs greater than 100
>       4) Any setuid/setgid bits will be stripped.

Number 3 above is not valid on all systems.  I have been on enough
systems where my user ID was less than 100.

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

Date: Wed, 6 Sep 89 10:18:16 -0700
From: uunet!pernod.enet.dec.com!francus (Yoseff Francus)
Subject: Re: Ultrix 3.0 mount

A mount by a normal user will only work via NFS. I believe that NFS
is supposed to work that way. The exporting machine can control how
much access to allow to an exported file system via options in the
/etc/exports file. By default root priveleges do not extend onto
NFS links (either using suid or setting it or putting stuff in as root).

Granted if the exporting machine allows root priveleges on files it
is exporting it could have a serious problem. The standard trick
of creating a suid shell on a machine one has root access on and
putting it onto an NFS mounted file system will work. However,
with proper control of /etc/exports it would seem to me that
this is not that big of a problem.

Don't other UN*X allow non superusers to mount via NFS??

Incidentally I held this opinion long before I started working for
DEC.

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

Date: Wed, 6 Sep 89 14:51:43 EDT
From: uunet!utzoo!henry
Subject: Re: Two security problems with Ultrix 3.0

> 1) Anyone can execute a /etc/mount command...
> We fixed this problem by typing
>     chmod 700 /bin/*mount

Unless /bin/*mount was originally set up to run setuid, this is not a
solution.  Anyone with half a brain can read the relevant manual pages
and figure out how to write his own "mount" command.  The shutoff has
to be at the system-call level, somehow.  If the system calls work for
anyone, chmoding the commands is just security-through-obscurity, which
does not work well.

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

Date: Wed, 6 Sep 89 14:46:14 -0400
From: uunet!MIT.EDU!jon
Subject: Two security problems with Ultrix 3.0

re: mount

I just tried (on a 3.0 system around here) mounting an NFS file system
this was and running a setuid program off it.  It lost with the
message "Restricted operation on file system".  What's the big deal?

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

Date: Wed, 6 Sep 89 14:40:31 -0400
From: uunet!MIT.EDU!jon
Subject: Two security problems with Ultrix 3.0

[ This and the previous message were sent to sec-rqst, instead of to security,
  I forwarded them - neil ]

re: mount

What's the problem with making the mount program world-executable?
Isn't it the system call that's the problem?  If you just get rid of
the executable what's to prevent me from copying the mount program from a
different system?  Or writing my own?  (It's not setuid.)

Allowing anybody to mount another file system isn't a problem (as long
as you are required to own the mount point so you can mount things
over /etc, /bin or whatever).  But they should be mounted -o nosuid!

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

Date: Wed, 06 Sep 89 12:00:14 PDT
From: uunet!unclejack.crd.ge.com!barnett
Subject: Re: nameserver security hole

[ This was sent to sec-rqst instead of to security, I forwarded it - neil ]

In Security Digest V1 #31, <barnett> writes:
> Subject: Two security problems with Ultrix 3.0

> 2) name service and remote login

>     When rlogin/telnet checks to see if someone have permission to log in
>     without a password, it uses the x.x.x.x.in-addr.arpa name server.
>     What that means, if I am the Name Server administrator for the
>     my-network.in-addr.arpa d> omain,  I can add an entry saying my name is
>     decwrl.dec.com or any other name.

>     If I were to rlogin onto decwrl.dec.com, it asks me what my name is
>     and I can lie about it It would then believe me.

The security hole described is correct, and is present on Sun (as well
as any BSD system, I'm pretty sure).  The Evil Wizard (W) on site A
determines some use for logging in to site B as user X.  W creates an
account under the name X on site A.  Then he sends a rlogin, rsh or
rcp request to site B.  B ascertains that A2 is authoritative for the
number-to-hostname map for the domain containing A, and asks A2 what
name goes with the number it saw.  A2 lies, specifying the name of B on
the likely assumption that it's in /etc/hosts.equiv.  Or /.rhosts, if
that's what you're into.  The rlogin is validated.

The solution (in Sun context) is for ypserv to do gethostbyname after
it does gethostbyaddr, backmapping the returned name to one or more
addresses.  It must then compare the incoming address to the addresses
from the gethostbyname.  If they don't match, it barfs.

In the general BSD context, gethostbyaddr can do the gethostbyname.

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

Date: Mon, 11 Sep 89 15:52:39 PDT
From: neil (Neil Gorsuch)
Subject: hosts.equiv stupidity

In Sunos and probably a few other operating systems that use the
yellow pages, when the operating system is updated or installed, a
line containing only "+" is left in /etc/hosts.equiv.  The intention
is to let yellow pages information be included at that point.  The
reality is that Sun forgot that there is no yellow pages information
for that particular file (hosts.equiv) and that the "+" line lets any
hosts ANYWHERE be trusted.  So, all you have to do is get a bin login
shell on any machine on the network (get root priveleges on a diskless
client through any means and then su to bin), and use rcp or rlogin to
change any bin owned images.  Vendors should really be a little more
thorough in in checking what they send out.

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

Date: Wed, 13 Sep 89 19:22:26 PDT
From: neil (Neil Gorsuch)
Subject: list ramblings

[ I have sent off requests to all the old isis list members to join.
I am now wading through 409 replies (that's AFTER mush seperated out
the non-security letters into other folders 8-), so don't expect a
speedy response to any security administrative request.  I now have
all of the old isis list archives.  The zardoz list archives, isis
list archives, and the many security programs I have recieved are now
being put into an automated archive that will only send things to the
addresses that recieve the security list.  When it is all done, I will
send a seperate letter to each list address specifying the exact
format of your address that the archive server expects, as well as
directions on how to use the archive server. - neil ]

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

Date: Thu, 14 Sep 89 19:46:23 PDT
From: neil (Neil Gorsuch)
Subject: password shadowing

This is adapted from a security seminar given by Russell Brand.  The
main idea is that there is a simple way to have shadow passwords on
any unix system supplied by any vendor.  While many people disparage
the use of shadow passwords, consider the fact that an IBM PC type 386
box can do over 3500 password encryption tries a second.  I have seen
estimates that it takes anywhere from weeks to months to crack a
password this way, but are you comfortable with the idea of someone
reading your encrypted passwords, and then having them crack your root
password at their leisure?  When you use shadow passwords, they can
still try this, but then they have to use the system login, which is
much slower and will hopefully be noticed.

root> mkdir /ETC
root> cd /ETC
root> chmod 700 .
root> cp /etc/passwd PASSWD
root> qsubst /etc/passwd /ETC/PASSWD /usr/bin/login /usr/bin/su \
/etc/vipw /usr/bin/passwd /usr/bin/chfn /usr/bin/chsh

Or use sed or vi or whatever to change the file name string
"/etc/passwd" to "/ETC/PASSWD" in the executable images of the
programs that have to modify the /etc/passwd file or read the
encrypted password field of the /etc/passwd file.  Then put in a
crontab entry to run every 5 minutes (or however fast you want changes
made to the /ETC/PASSWD file to be propogated to the /etc/passwd file)
that executes a shell script that copies /ETC/PASSWD to /etc/passwd
but sets the encrypted password field to garbage, maybe something like
this:

awk </etc/PASSWD >/etc/passwd -F: \
'{printf("%s:%s:XXXXXXXXXXXXX:%s:%s:%s:%s\n",$1,$2,$4,$5,$6,$7)}'

Or, if you really want to be nasty, put in some kink of hashing
function so that the encrypted password field in the produced
/etc/passwd file is a function of the user name, so that the cracker
wastes weeks or months using bogus data, and then finds that it didn't
work 8-).

WHEN YOU DO THIS, BE CAREFUL.  LEAVE A BUNCH OF WINDOWS OR TERMINALS
LOGGED INTO ROOT SO THAT YOU CAN RECOVER FROM A MISTAKE.

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

        End of Security Digest Volume 1 Issue 32
        **********************

END OF DOCUMENT