Re: FireWall-1 FTP Server Vulnerability

From: der Mouse (mouseat_private)
Date: Thu Feb 17 2000 - 00:49:15 PST

  • Next message: Guy Cohen: "1st International Hackers Conference in Israel - and a fight agai"

    > A in my opinion better approach would be to
    > * require that the 227 (PASV) reply is the one and only line present in
    > the packet
    > * that this packet properly ends with a newline
    > * that this packet is not oversized for being a 227 reply
    
    Anything that depends for correct operation on where segment boundaries
    fall in a TCP data stream is broken.  Anything.  (I haven't been able
    to think of any exceptions, at least.  I'd welcome any anyone has to
    offer.)  You cannot depend on ever seeing the entire PASV response in a
    single packet; you cannot depend on ever seeing more than one octet of
    data per segment.  Sure, it's fine to optimize for the case where the
    whole thing is in a single packet, since that will be the common case.
    But breaking if it's not is, well, broken.
    
    And quite aside from that, you can't depend on much of anything in the
    PASV response, as far as I can tell - you certainly can't depend on
    being able to parse it mechanically.  The only spec I've ever found for
    the response is the wording in RFC959, which says only "The response to
    this command includes the host and port address this server is
    listening on"; it doesn't say anything about how this information is
    formatted or whether there may be other information present that
    happens to look similar.  (At least, that's the best info I have now.
    If anyone has pointers to updates that specify otherwise, I'd love to
    hear about them.)  This is one thing EPSV helps with (see RFC2428).
    
    > It is probably not possible to making a 100% secure filter agains
    > this while having a broken FTP server, at least not without seriously
    > impairing the use of the server.
    
    It is not possible to put an FTP server behind a NAT box without
    breaking something.  (The same is true of other protocols that embed IP
    addresses in data streams; the only other example that comes to mind
    offhand is Quake.)  Attempting to kludge around this brokenness by
    rewriting data streams in the NAT box, blindly assuming anything to
    port 21 is an FTP control connection, is piling brokenness on top of
    brokenness, and it's hardly surprising if the house of cards threatens
    to come tumbling down.
    
    					der Mouse
    
    			       mouseat_private
    		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:39 PDT