Re: another fatal bug in NT/2000 "Command Prompt" I/O [more info]

From: F.Vigo - L.Girardi (gianluca.girardiat_private)
Date: Fri Nov 02 2001 - 21:03:48 PST

  • Next message: Lincoln Yeoh: "Re: (pointless?) overflow in tftp.exe (Was: Re: twlc advisory: possible overflow in ms ftp client)"

    We've analyzed the bug previously posted about the Windows Command Prompt
    crash.
    
    
    OVERVIEW:
    
    This bug affects the Microsoft Windows NT/2K/XP command prompt. CMD.EXE and
    COMMAND.COM crash if a string containing one or more tabulation characters
    (ASCII/HEX 09), followed by some backspaces (ASCII/HEX 08) and a random
    character is printed to standard output or standard error. Under Windows NT
    the system just hangs with a blue death screen; under 2000/XP the system
    reboots immediately.
    We've tested also with Windows 98 , which had no problems even in real DOS
    mode (safe mode with command prompt).
    
    
    TESTED SYSTEMS:
    
    Microsoft Windows 98 (NOT VULNERABLE)
    Microsoft Windows 98 in DOS mode (NOT VULNERABLE)
    Microsoft Windows ME (NOT VULNERABLE)
    Microsoft Windows NT4 Workstation (crash)
    Microsoft Windows NT4 server (crash)
    Microsoft Windows 2000 Professional (reboot)
    Microsoft Windows 2000 Server (reboot)
    Microsoft Windows 2000 Advanced Server (someone posted that it did not work.
    We tested it with no service pack and it worked)
    Microsoft Windows XP Professional (reboot)
    
    
    DETAILS:
    
    The number of backspaces to print depends on how many characters are written
    in the command prompt's buffer. To crash it the user must print at least one
    backspace more. In this case the cursor should point at the beginning of the
    buffer but, if the buffer contains a tab, the cursor seems to go pointing
    somewhere else in the memory before the buffer, so the next character
    printed crashes the prompt. That's why the "\t\b\b " ASCII string posted in
    the C program example works : when the console application starts, the
    CMD.EXE's output buffer is empty and 2 backspaces are enough.
    The problem seems to be happening because of the [Tab]: We've tested even
    with other escape characters, like \a, \v, \r and nothing happened.
    
    This is not compilers' matter: we've rebooted the system with a perl script
    and even with a simple .BAT file, which we also sent and received
    successfully via email, with no Norton or McAfee antivirus warnings.
    The .bat file contained just one line (hex):
    65 63 68 6F 20 09 08 08 08 08 [MANY 08s] 61 61
    In ascii it's:
    echo [tab][bs][bs][bs]...[bs]aa
    
    NOTE: Compiling the malicious program under CYGWIN and running it doesn't
    crash the machine, but redirecting its output to a file and typing it does:
    this is probably because CYGWIN applications run in some protected
    environment.
    
    
    ADDITIONAL (malicious) TESTS:
    
    We've made several tests to determine if this problem could seriously
    compromise security. At first we checked if the malicious program (the .bat
    or the .exe) works even without a foreground command prompt's window. With
    the AT command we've scheduled the execution and the system rebooted, even
    if no user was logged in.
    
    Then we checked out if the problem is exploitable via network. We put netcat
    listening on a port and connected to it from another machine, sending the
    [Tab] character followed by MANY backspaces and a white space. The system
    rebooted.
    
    We also set up a Windows 2000 Advanced Server machine, running IIS 5 with no
    patches (--> with the unicode vunlerability). After uploading the malicious
    program via FTP (can be done easily via tftp or netbios exploiting the IIS
    bug) we sent to the web server this string:
    GET /scripts/..%c0%af../winnt/system32/cmd.exe?+/C+c:\crash.exe
    The system rebooted.
    
    
    We think that it's possible for someone who knows better the windows kernel
    to find out more uses of this bug.
    
    
    Regards,
    
    -----
    
    Luca Girardi  - l.girardi@anti-idle.com
    Francesco Vigo  - f.vigo@anti-idle.com
    



    This archive was generated by hypermail 2b30 : Sat Nov 03 2001 - 16:49:44 PST