OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: ProvenSecurity News List (securitynewsPROVENSECURITY.COM)
Date: Tue Mar 13 2001 - 08:35:10 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Greetings,

    I tested this in a Windows 2000 environment with IIS 5.0 and every known Hot
    Fix there is and it still gave me the 500 that Wojciech described. I'll
    look into to further and let everyone know what I find.

    Jason Buckley
    jbuckleyprovensecurity.com

    ----- Original Message -----
    From: "Woch, Wojciech" <Woch_WADMIRAL.FR>
    To: <VULN-DEVSECURITYFOCUS.COM>
    Sent: Monday, March 12, 2001 12:43 PM
    Subject: Unusal response from IIS with some file names

    > Hello,
    >
    > IIS v4.0 seems to give an usual response when non-existing files ending
    with
    > one of the following sequences of characters are requested:
    >
    > :~n
    > |~n
    > ~n:
    > ~n|
    >
    > where "n" stands for a number between 0-9 (ex: GET /file:~1). Instead of
    the
    > regular 404, we get
    >
    > HTTP/1.1 500 Server Error
    > Server: Microsoft-IIS/4.0
    > Date: Mon, 12 Mar 2001 17:08:27 GMT
    > Content-Type: text/html
    > Content-Length: 126
    >
    > <html><head><title>Error</title></head><body>The filename,
    > directory name, or volume label syntax is incorrect.
    > </body></html>
    >
    > The text corresponds to the WIN32 status code #123, that can be seen under
    > sc-win32-status in the log files, as if the message was received directly
    > from the OS. Normally, special characters that induce a WIN32 status of
    123
    > are show in the log, but a 404 is still returned instead of the effective
    > error message from the OS (ex: GET /file||1). This behaviour seems to be
    > introduced by MS00-30 (at least it shows up after installing IIS with
    > defaults + MS00-30 on NT 4.0).
    >
    > Trying to pipe commands directly following the file name with regular
    shell
    > escapes (&|) or overflowing (returns to a 404 after about 278 characters)
    > doesn't give up much, maybe someone can push it a little further/has an
    idea
    > about the issue?
    >