Date: Fri, 10 Nov 2000 21:37:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cjclark@alum.mit.edu Cc: chat@freebsd.org Subject: Re: ftp.freebsd.org b0rked? Message-ID: <200011102137.OAA00624@usr08.primenet.com> In-Reply-To: <20001110102122.A99378@149.211.6.64.reflexcom.com> from "Crist J . Clark" at Nov 10, 2000 10:21:22 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > The problem appears to be a real bug in the checkpoint firewall code. > > > > > > When I was watching FW-1 reset connections, I was thinking the same > > > thing. From the best I could tell, FW-1 would reset the connection if > > > the FTP data portion _of any single packet_ did not end in a CRLF. I > > > would get most of the "230" lines until one line was broken between > > > packets... then FW-1 would send TCP RSTs each way. To me, that's gotta > > > be broken behavior. Why should the application layer, FTP, care how > > > the data is broken up at the transport layer, TCP? > > > > To prevent command channel hijack, resultingin a data channel > > to an unintended destination. This would, in effect, allow a > > man in the middle to procure the equivalent of "proxy" services, > > if it weren't prevented. > > > > So say someone sets up an FTP site, and you FTP to it, and ask > > to download; all of the sudden, an attacker can use your > > command channel to commandeer proxy services from your ftp > > client, and FTP around inside your firewall. > > How does ensuring each packet has application data ending with a CRLF > protect against that? It's resetting based on the address data length change in the packet, not on the CRLF. My comment was on the question: > > > Why should the application layer, FTP, care how > > > the data is broken up at the transport layer, TCP? I guess I included too much context in the reply. The point was that there are legitimate reasons to care. I think the precise reason it cares about the line termination is that it wants to maintain its own state for passive connections. Without knowing exactly what software is running on a side receiving a strictly non-compliant line terminator, which might nevertheless be recognized as a line terminator, the firewall can't predict the state of the end receiving the data. When that happens, it loses the ability to discern the "legitimate" vs. "illegitimate" traffic through it, since it can not really tell whether a passive connection is now sending commands, or data, through the command channel (as one example). What it basically boils down to is that a firewall has to act as an application level transparent proxy for some protocols, such as FTP, which absolutely _hate_ application level transparent proxies (the FTP protocol design is anathema to it, as is the HTTP protocol design). You could argue that it is violating the maxim "be generous in what you accept, conservative in what you generate", but as a firewall, it has made a promise to keep you "safe", so breaking any protocol that needs this level of proxy when the data used to implement it is not strictly RFC conforming is viewed by most firewall users as a feature, and most people using nonconforming applications as a pain (Microsoft gets bent out of shape if you suggest that OutLook be forced into RFC compliance, too -- go figure). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011102137.OAA00624>