COMMAND

    IIS

SYSTEMS AFFECTED

    IIS

PROBLEM

    Marc  from  EEYE  found  following.   By  default the registry key
    MaxClientRequestBuffer is  not created.   It is  essential to  IIS
    security to set a limit to MaxClientRequestBuffer.  This key  sets
    the allowed amount of input to IIS (basically).  So for example if
    you set MaxClientRequestBuffer to 256 (bytes) and you telnet  into
    the server and hit it with GET /[bigbuffer] HTTP/1.0 you will only
    be allowed to send aprox. 256  bytes.  By default though there  is
    no restriction on this  so its easy to  create a program to  cause
    IIS to waste memory  and use up 100%  of the CPU. We  were able to
    use cnghack.c  to waste  70megs of  memory in  a matter  of a  few
    minutes.

    EEYE created a  demonstration program as  a reminder to  make sure
    you have MaxClientRequestBuffer set to something reasonable:

        http://www.eeye.com/database/advisories/cnghack.c

    example  code...  very  broken.   cnghack.c  works  by  doing  the
    following:

        Connects to example.com
        Sends: GET / HTTP/[return][buffer]

        [return] is just an \r\n
        [buffer] is a never ending stream of A's

    IIS will keep buffering the input therefore wasting memory and  in
    the mean time the processor will sit at 100%.

    Some  of  you  might  be  asking  why does IIS accept invalid http
    syntax  in  the  first  place?   A  normal  HTTP request should be
    something  like  "GET  /  HTTP/1.0\r\n\r\n"  but  this  request is
    "GET / HTTP/\r\n[buffer]" so it should have dropped the connection
    because  we  never  sent  a  HTTP  version.   However,  IIS  keeps
    buffering input until it receives \r\n\r\n.

SOLUTION

    Microsoft  was  nice  enough  to  write  up  a  KB  article  about
    MaxClientRequestBuffer. Be sure to check it out:

        http://support.microsoft.com/support/kb/articles/q260/6/94.ASP