COMMAND

    OpenNT

SYSTEMS AFFECTED

    Win NT

PROBLEM

    Nemo found following.  There's a possible Denial of Service attack
    to NT boxes running OpenNT 2.1 over a Telnet connection (no  tests
    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?
    This was tested  on one 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%  and  kernel  activity  rises  to  50%  forever.  Finally the
    foreground work turns horrible and the operation turns impossible.

SOLUTION

    A user with appropriate privileges (say, Administrator) should  be
    able to use TKILL.EXE or the Task Manager or any other appropriate
    utility to shoot the non-visible GUI app. PSXSS.EXE is unkillable,
    even by the Administrator. So is CSRSS.EXE, which serves the  same
    purpose for Win32 as PSXSS.EXE does for OpenNT.

    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.