[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    [NTSEC] CPU 100% Update (fwd)
From:       Aleph One <aleph1 () DFW ! NET>
Date:       1997-01-28 16:31:42
[Download RAW message or body]

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01

---------- Forwarded message ----------
Date: Tue, 28 Jan 1997 09:11:09 -0500
From: Russ <Russ.Cooper@RC.on.ca>
To: 'ISS NT Security Mailing List' <ntsecurity@iss.net>
Subject: [NTSEC] CPU 100% Update

First of all, let me say up front that thanks should go to Paul Leach of
Microsoft for his efforts here. Its rare to find someone who will do
work on something that's not part of their mandate with the fervor that
Paul has. For those of you who have followed the CIFS efforts, you'll
recognize that Paul hasn't had the easiest of times dealing with mailing
list queries, but he worked real hard last night to get me this
information. Thanks Paul.

Short Form:
No, we don't have a fix yet for all the services that can be affected by
the Telnet bug. The list continues to increase as to which services can
be made to drive the CPU to 100%, but interestingly enough CRS is not
one of them, so however its doing what it does, it is unaffected by
these problems.

We do, however, have a way to get some information and put some
restrictions on things, see below.

Long Form:
I have received from Microsoft a program which can query the RPC
endpoint mapper and return what is currently available through it. This
is a great step forward in determining where your risks are. In the case
of IP listens, it shows what IP address and port number the service is
listening to. The output is not real pretty, but it works. It also shows
named pipes and SPX bindings as well. There's a text file in the archive
that gives the brief description of how to use it. I am making it
available as a ZIP file. Rather than inundating everyone on this list
with this program, send me private email WITH EPDUMP.EXE IN THE SUBJECT
LINE and I will send it to you. If you don't put EPDUMP.EXE in the
subject line you'll get nothing, and don't bother with any comments,
there going into the trashbin after they've been processed...;-]

Paul is going to make it available on the MS FTP site under
/bussys/winnt/winnt-unsup-ed but he's not sure how long it will take to
get it there. Please check there before sending me mail, help me
minimize the load on my bandwidth...;-]

Ok, next thing. There is an article in MSDN that pertains to the RPC
dynamic port bindings and its well worth reading. This information is
currently on-line as part of a promotion that MSDN is putting on. You
can read the full document at;

http://www.microsoft.com/msdn/sdk/platforms/doc/sdk/rpc/src/ov-cnfig_6.h
tm

Have a look there first, then read the rest of this message;

What follows is an example of how you would set up NT to allow dynamic
RPC binding to ports, but restrict those ports to port numbers that are
not within a range of numbers you have opened for other Internet
services (like FTP for example). This way you can ensure that no RPC
service will possibly be fired up into an existing range of open ports.

1. Specify a range of ports that you want to make available via the
Internet, and place that range of port numbers into the multi_sz key
Ports. You can put multiple ranges and/or individual port numbers, so
you can be as selective as you want.

2. Now put a Y in the PortsInternetAvailable key. This makes your ranges
identify ports that are available to the Internet.

3. Now put a N in the UseInternetPorts key. This means that by default,
all RPC services will use port numbers that are not in your range of
allowable Internet ports.

When an RPC application fires up it will use a port number outside of
your specified ranges, which should all be filtered by your router. If
you have to leave ranges open for other services, you can be assured
that your RPC services will not overlap and use one of those ports.

This is just one example, as you will see from the descriptions of the
keys, you can come up with a policy that suits your needs.
Unfortunately, NT itself does not permit ACLs on its own port filtering
mechanism, so you have to rely on your router to provide that
functionality, for now.

I hope this helps a little in trying to cope with the current problems.
This is only intended to be a workaround, and does not fully address the
problems themselves. Some services which can be exploited might have to
be left exposed to the Internet, so a more complete fix is still needed.

Finally, on the issue of NT DNS. There was a security advisory sent out
by Secure Computing indicating that NT DNS could be exploited by sending
it a query response for which no query had been done. I also tested DNS
via port 53 to see if the Telnet exploit would work against it, the
results were that between DNS.EXE and SERVICES.EXE the CPU utilization
was pegged at 100%. There is a DNS.EXE which appears to fix both of
these problems, but I should warn you that this is not a supported fix
(or at least I haven't received confirmation that this updated DNS.EXE
is supported). It is available via ftp from rhino.microsoft.com, log on
as DNSBeta with a password of DNSBeta. In the /service_pack3/x86
directory there is a file called DNS.EXE dated 1/26/97. I applied this
patch to my system and was no longer able to exploit it via Telnet. I
have not seen a message from Secure Computing to say whether it fixes
the query response exploit yet.

Given that DNS is one of the things that must be left open, the fact
that it resolves the CPU 100% utilization problem from Telnet
connections makes it a good fix in my book. I leave it to you to decide
if you want to apply it or not. As yet, I have not seen a version for
Alphas.


Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security Consulting
"Why does Plug-n-Play so often turn into Unplug-n-Pay?"

[prev in list] [next in list] [prev in thread] [next in thread]