Date: Fri, 10 Nov 2000 17:42:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cjclark@alum.mit.edu Cc: dg@root.com (David Greenman), des@ofug.org (Dag-Erling Smorgrav), tlambert@primenet.com (Terry Lambert), chat@FreeBSD.ORG Subject: Re: ftp.freebsd.org b0rked? Message-ID: <200011101742.KAA22146@usr08.primenet.com> In-Reply-To: <20001109213842.U75251@149.211.6.64.reflexcom.com> from "Crist J . Clark" at Nov 09, 2000 09:38:42 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't see how dg-ftpd is doing anything wrong. It always replies with > > CRLF terminated lines on the command channel as RFC-959 requires. ...so I > > don't think this is the cause. > > 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. Technically, this would be a trojan attack; I haven't seen it bandied about much, but it's certainly feasible. As to the line terminator issue, there is a long standing FTP bug that still exists in many clients, where if the client is placed in binary mode, not only the data channels get data that does not have line-terminator twiddling, but also the command channel has this. In other words, the flag is applied to both, when it should only be applied to one. Passive mode makes this harder to get right, but depending on the client and the way it was implemented, it may mean that the EOL that gets sent over the channel is '\n', '\r', or '\r\r\n'. Yes, this is ugly. The most common culprit is some visual FTP schnauser, which the other thought he could do better than the original "ugly" (but correct) FTP code did. 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?200011101742.KAA22146>