COMMAND

    IIS

SYSTEMS AFFECTED

    IIS 4

PROBLEM

    Jason Levine found following.  It  appears that IIS4 has a bug  in
    logging the FTP data port in the W3C extended log format (the only
    log format that contains  the FTP data port).   The short form  of
    this is that IIS does not _ever_ log passive FTP ports correctly.

    In passive  FTP, the  server passes  the client  a port  number to
    which the client  should connect to  establish a data  connection.
    It  does  this  by  breaking  a  16-bit integer into two eight-bit
    integers, the high eight bits and the low eight bits, and  passing
    them to the client as part of the "PASV" return.  The client  then
    reconstitutes the two, and knows what to do.

    When IIS writes the log, however, it reconstitutes the two numbers
    back  together  BACKWARDS,  flipping  the  high  and low eight-bit
    components and  ending up  with the  entirely wrong  number.  (one
    would find this  funny, seeing as  since the server's  the machine
    GENERATING the original port number.   Thus, it shouldn't have  to
    do the reconstitution to figure it  out and put it in the  log; it
    ALREADY KNOWS  the port  number, and  only breaks  it up  into two
    eight-bit integers because that's the  FTP spec way of sending  it
    to the client.)

    So, for example,  if the server  uses port 1094,  it breaks it  up
    into "4,70" to send to the client:

           4 = 00000100
          70 = 01000110

    (Put them together, and 0000010001000110  = 1094.)  The log  file,
    though, shows that  the transfer took  place on port  17924, which
    (after  much  head-scratching)  turns  out to be 0100011000000100,
    which is  "70,4".   NOTE that  the log  file is  wrong here;  much
    testing with packet traces and the like show this.

SOLUTION

    Nothing yet.