COMMAND

    kernel

SYSTEMS AFFECTED

    Win NT, 2000

PROBLEM

    Daniel Siffredi found following.  This  is a new bug found in  W2K
    in all  flavors, works  with all  levels of  users.   Here is  the
    proof of concept:

        - Open a Cmd Window
        - Ping to any host (for example ping 127.0.0.1 or preferred  a
          host in your LAN), no switch needed. Just ping
        - Now press F7 and Enter (try a couple of times quickly...less
          than ten , and you can see what a meaning)
        - The machine reboots, from nothing a warm reboot.

    This  is  not  network  related.  You  can  make  it happen with a
    "dir *.ini /s".   Type this in  press Enter and  immediately press
    F7 and  Enter several  times quickly  then press  Cntl-C, the  dir
    will stop  due to  the break  combo, display  another 2 "dir *.ini
    /s" on the console then freeze for a moment and reboot.

    On a  Terminal Services  enabled server  it will  crash the system
    through a RDP or ICA connection.  This can be a real problem  with
    people running large Terminal Server environments.

    Windows XP (Whistler)  Professional build 2462  (beta 2) does  NOT
    have this  problem.   Terminal Services  on Adv.  Server +  Citrix
    Metaframe is also affected.

    Funny, a large multiuser system  can be brought to its  knees from
    userland.

    Bronek Kozicki used kernel debugger running on serial port to  get
    more details  from both.   Apparently there's  unhandled exception
    in csrss.exe process space (it's Win32 SubSystem - wise book  says
    that a lot of Win32 job  is actually done by Executive).   You may
    find more details in attached Windbg log files:   csrss_halt-1.txt
    was  recorded  when  smaller  system  crashed (one with 128MB RAM)
    csrss_halt-2.txt  was  recorded  when  bigger  system crashed (one
    with 512MB RAM).  In  this file Bronek allowed system  to continue
    running after  exception was  handled by  system dubugger (command
    tcb), so at the end of file  you will find BSOD itself.  It  looks
    like:

        *** Fatal System Error: 0xc000021a
                               (0xE2682B68,0xC0000005,0x5FFB4484,0x00B5FA38)
        STOP: c000021a {Fatal System Error}
        The Windows SubSystem system process terminated unexpectedly
        with a status of 0xc0000005 (0x5ffb4484 0x00b5fa38).
        The system has been shut down.

    The  reason  of  the  system  rebooting  or  halting  is   because
    csrss.exe (the process implementing the win32 subsystem)  produces
    and unhandled exception  and dies.   The OS is  unable to continue
    its  normal  operation  without  this  fundamental  process and it
    KeBugChecks and dies.

    In csrss.exe, CSRSRV.DLL!CsrUnhandledExceptionFilter gets  called.
    This function calls NTDLL!NtRaiseHardError  with an error code  of
    0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED,  that is,  csrss.exe
    is  death),  and  all  ends  up  in  KeBugCheckEx  when the system
    reboots/halts.

    Who implements  the history  window that  it shows  when you press
    F7?  Well,  it  isn't  implemented   by  cmd.exe  itself,  it   is
    implemented inside csrss.exe,  specifically, in winsrv.dll.   Here
    lays the implementation for all the F-X functions (F1,F2,F3,  etc)
    that cmd.exe provides to the user.  The window itself is drawn  by
    code  inside  winsrv.dll,  what  makes  us  think that any console
    application can make  use of this  functionality, but we  couldn't
    find the win32 api to do it.

    Because  of  this,  this  might  not  be  a cmd.exe bug alone, but
    something that could affect other applications as well.

SOLUTION

    Hernan Ochoa  developed a  temporary patch  to solve  the problem.
    The  patch  directly  eliminates  the  functionality of all F-Keys
    inside cmd.exe (and all  applications that use the  history window
    functionality, etc.).   So, you can  continue to use  cmd.exe, but
    pressing F7  inside it  will have  no effect  at all,  pressing F2
    will have no  effect at all  either, it's possible  to easily make
    a patch that only eliminates F7, but, oh well...

    At WINSRV.DLL!5FFBD881 there's a  function that contains inside  a
    big switch()  statement and  implements the  functionality of  the
    F-Keys.  Near the beggining of the function you have the following
    code:

        .text:5FFBD891                 cmp     di, 76h
        .text:5FFBD895                 mov     [ebp+var_4], esi
        .text:5FFBD898                 mov     [ebp+var_8], esi
        .text:5FFBD89B                 jz      loc_5FFCFEDF

    Here the code is making  some comparison against a parameter  that
    gets passed to it (the value 76h).  You can change the

        .text:5FFBD89B                 jz      loc_5FFCFEDF

    for a

        jmp 5FFBDC42

    that  actually  jumps  to  the  end  of  the function, and returns
    without performing any action.

    This  is  the  function  that  actually  decides  which  window to
    display (history window, copy window, etc) based on the F-Key  you
    pressed, so following  the code a  little, very little  more, will
    allow to make a  patch that only prevents  the use of F7,  instead
    of eliminating the functionality of all the F-keys.

    Another solution  is to  add the  following registry  key to every
    user (go to HKEY_USERS and add it for every SID):

        Software\Policies\Microsoft\Windows\System

    there, create a  DWORD value named  DisableCMD, and set  the value
    to 1.  This will prevent your users to execute cmd.exe.

    The correct patch would  be the winsrv.dll patch  described above.
    Remember this is a quick  hack while waiting for the  proper patch
    by Microsoft.