Bugtraq mailing list archives

Re: NT configuration caution


From: dleblanc () MINDSPRING COM (David LeBlanc)
Date: Tue, 21 Apr 1998 11:57:18 -0400


At 12:45 AM 4/21/98 -0600, seifried () SEIFRIED ORG wrote:
The solution to this configuration error is to stop the rcmd service on the
server and when you need access use the netsvc command to start it. Since
only the admin has the permissions to stop and start services I think this
should pretty much cure the problem. However I'd really like to hear from
anyone who has ideas on this one.

Geo.

Several possible solutions to remote UNIX style management of NT machines:

To solve the RCMD.EXE problem (and quote the MS help files):

Security is provided in two ways:

The logged-on user must have interactive logon privileges on the target
computer in order to connect to it.

Any programs executed on the target computer are executed impersonating
the logged-on user. Any access validation (such as opening files) is
performed
as if the user were logged on to the local computer.

I'm not sure this is actually true - some versions of rcmd don't
impersonate properly.  It may be fixed by this version, but I haven't
verified that.

So simply tighten up permission on the server, remember by default the
group everyone can pretty much run amuck on the system, so simply remove
the group everyone's (and any other global/local groups or users that do
not need access to the files/etc) permissions from any file/programs you
deem sensitive (which should be most of them), this will keep the FP users
out of trouble. A better solution would be to create a FP users group and
simply give then no access to any sensitive areas.

You can cause yourself massive headaches this way.  If it is a dedicated
IIS server, and provides no other services, this will work OK.  If not,
things will go wrong.  Instead, look for places where everyone has > read
access.  Also, the FP users group (which isn't a bad idea by itself), will
need at least read control (RX) in the system areas.  What you want to
control is write and delete permissions.

This is from NT Server Reskit Suppliment #2, I didn't bother to check the
original or Suppliment #1, but I suspect the same applies. Using the
.rhosts properly would seem to me to cut the risk down considerably and
be a better alternative in many ways then RCMD.EXE.

rsh on NT is a disaster waiting to happen.  NT has no way to change user
context based solely on user name.  It has to have a user-password pair, or
a token it can impersonate.  This means that any rsh daemon running under
NT is going to be either running as LocalSystem (a VERY bad idea, and how
the reskit version runs), or you're going to have to kludge up something
where you store passwords.  I flag the rshsvc on NT as a high risk
vulnerability in the ISS scanner just from finding it installed.  Even if
there aren't any remote machines permitted, it would function as getadmin
for a local user.  I would strongly urge anyone NOT to use this.  If you
need to get a remote command line, remote console from the RK update is
nice, or there are telnet and rlogin daemons available.

Oh - I'd also point out that NT has no concept of denying non-priviledged
users access to priviledged ports.  Thus any UNIX box which trusts an NT
box for rsh, better trust ALL the users on that NT box.


David LeBlanc           |Why would you want to have your desktop user,
dleblanc () mindspring com |your mere mortals, messing around with a 32-bit
                        |minicomputer-class computing environment?
                        |Scott McNealy



Current thread: