monti writes ("Re: FireWall-1 FTP Server Vulnerability"): > STAT -1 > 213-status of -1: > . > .. > 227 Entering Passive Mode (xxx,xxx,xxx,xxx,0,139) > [snip] > 213 End of Status Strictly speaking, the ftp server is breaking the FTP protocol. The server is required to pad the beginning of '227 ' to prevent it from being interpreted as a reply code (rfc959, section 4.2). This is the case even if the digits don't match the first line ('213-'). Since the firewall depends on having an accurate model of the internal state of the FTP server, it is difficult to construct a firewall to protect a server that doesn't follow the standard. In the above text, the firewall potentially could detect the bogus response by comparing the numbers, but it's likely that a '213 ' could be inserted in the response before the '227 ' without much difficulty. > I dont really think the issue is with 'how' the PASV response and packet > appears on the wire, but with the Firewall's logic in creating a hole for > PASV ftp data connections. I think the firewall should probably be a bit > more strict about how it makes the decision to open the PASV hole and > follow rules like the following: > > First watch for: > client -> ftp-server "PASV" > > which triggers the firewall to look for this immediately afterwards: > client <- ftp-server "227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt) > > If any other statement is seen from client or server, before the presence > of the 227 port declaration, the attempt is ignored. That might not work. Using the technique you describe above for getting the server to send the '227 ' response, and by adjusting the length of the directory listing, you can arrange for '227 ' to be at the start of a packet. By arranging for a PASV request to the sent to the server at the right time, the firewall will see 'PASV' in one direction followed by a '227 ' in the other direction. Unless the firewall is keeping careful track of when a response is complete, it will be fooled by this. A small problem with this is that the ftp server will eventually process the PASV request itself, which will change which port is opened in the firewall. There are a couple of workarounds. You could make the directory list after the '227 ' response very long indeed, or you could sobotage the CRLF sequence that precedes the PASV by doing invalid telnet option negotiation (the ftp server and firewall probably interpret these differently, though the firewall may well filter out such negotiation). Even with the best firewall in the world, I'm pretty convinced that you need an ftp server that implements the FTP protocol correctly before you have a hope of handling PASV correctly. Peter
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:22 PDT