On Wed, Oct 09, 2002 at 04:46:19PM -0400, Paul Robertson wrote: > It's not a SACK problem, it's a TCP segement issue, Yes, I didn't mean 'selective ACK' as in SACK. I don't know where I picked up that term, I think it was the advisory itself. But in context of the advisory description, it should be clear: the attacker sends an ftp command that the server quotes in its reply. When the reply arrives, the attacker doesn't ACK the full response, but only the first part of it, up to the section where the desired quote starts. Hence, the attacker selectively ACKs the reply. The intermediate packet filter sees only the remaining quote at the beginning of a retransmitted packet, and confuses it with a complete reply from the server. This triggers creation of a new state entry (for what the packet filter thinks is a data connection the ftp server expects), which the attacker uses to connect to another service, which should not be allowed. And, yes, based solely on code inspection, I'm very confident that IPFilter is vulnerable to this attack. If anyone fancies a little competition, set up an ftp server behind an IPFilter firewall. Allow me to connect to the ftp server (using passive mode, so the in-kernel ftp proxy allows incoming ftp data connections). Setup a fake target, like an echo "secret" inetd.conf entry, and absolutely filter any access to that port on the firewall. If I can connect to that port and get the secret, I win. How much are you betting? Of course, the ftp server runs on a stack that actually does partial retransmissions. I don't think these are unrealistic boundary conditions. Daniel _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Wed Oct 09 2002 - 15:01:21 PDT