This is my first post to the list... I'll try to do my best, ... ;-D
There's a possible Denial of Service attack to NT boxes running OpenNT 2.1
over a Telnet conecction (I could not test if any earlier version is
affected). Any NT machine running the telnet daemon included in OpenNT is
vulnerable to this attack.
This vulnerability is related with the fact that OpenNT Unix consoles allow
to run win32 applications (both GUI and text based) through the command
line. The same happens when a client connects to an OpenNT telnetd: the
client is allowed to launch and run win32 applications...
Not only the text based win32 applications could be run over the telnet
connection, but also GUI ones can be executed from any telnet client. And,
here is the clue. Lets see an example:
First, we log into the NT machine:
(APOLO) login: Nemo
Password:
Copyright (c) 1995, 1996, 1997
Softway Systems, Inc. All rights reserved.
Welcome to the OpenNT Commands and Utilities
DISPLAY=APOLO:0.0
$
Once we are inside we are considered by the system a local user, so ... Why
don't we run, for example, Microsoft Access 97? Here we go!
$pwd
//D/
$ cd /Program\ files/Office97/Office/
$ pwd
/Program files/Office97/Office
$./MSACCESS.EXE
At this point, the application is launched on the server: his memory is
allocated and blocked and then... the CPU rises to 100% and the telnet
connection halts... Since a few seconds later the CPU returns to its normal
status, its not relevant (at the moment X-D)... But, ... if you look at the
process list on the task manager you will see:
Name ID CPU% CPU TIME MEMORY USAGE
------------ -- ---- -------- ------------
MSACCESS.EXE xx xxxx xxxxxxxx 4924 KB
PSXRUM.EXE xx xxxx xxxxxxxx 580 KB
PSXSS.EXE xx xxxx xxxxxxxx 3028 KB
If we try to kill the process we will get the tipical warning message asking
if we want to go on or not. After answering 'yes', the task manager returns
a surprising 'Access denied', and the process keeps alive and unkillable. If
we try with the related POSIX subsystems we'll get the same behaviour...
So here we have an unkillable process on the server, generated remotely and
which is taking 5 MBs of memory that we could not recover unless we reboot
the machine...
After that, the telnet server keeps alive and ready to log on again an
repeat the 'game'... And what if we repeat the process untill filling the
memory? I tryed it on my server (Pentium 166, 64MB RAM) and found that when
you have run it four times, not only the memory usage has increased on an
important way, but also the CPU use rises till 100% forever... At this point
I must say that I could operate with the machine, more or less... but I'm
sure it would break down with several tries on...
As you can see, writing a script to exploit this vulnerability its really
obvious.
Possible solutions? There's an easy way to avoid this annoying behaviour.
Create a new local group called 'TelnetUsers' (for example). It's also
necessary to create new accounts for each remote user so the remote accounts
doesn't belong to any group rather than 'TelnetUsers'. As the name suggest,
the group gathers the users allowed to log in over a telnet connection.
Give this new group the NTFS rights you want but don't forget to deny the
access to GUI win32 apps for this group. Remember to give read rights to
'TelnetUsers' on the OpenNT subtree so they can log on and operate without
problems.
Note that a logged on remote user is consider a LOCAL user. So it belongs to
the following groups: LOCAL, INTERACTIVE and EVERYONE (among others). These
are generic groups so be aware if you use them in directories with GUI win32
applications. Remember to deny the access to TelnetUsers in this case.
Well. That's all folks! ;-D. I wish I have helped.
{Nemo}
---------------------------------------
Nemo - n3m0at_private
BlackBrains Security Team member
http://www.thepentagon.com/blackbrains/
http://blackbrains.onlinet.com
---------------------------------------
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:13 PDT