From owner-freebsd-chat Fri Nov 10 9:42:37 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 9050937B4C5 for ; Fri, 10 Nov 2000 09:42:35 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA26768; Fri, 10 Nov 2000 10:38:36 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAoJa4b0; Fri Nov 10 10:38:13 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA22146; Fri, 10 Nov 2000 10:42:06 -0700 (MST) From: Terry Lambert Message-Id: <200011101742.KAA22146@usr08.primenet.com> Subject: Re: ftp.freebsd.org b0rked? To: cjclark@alum.mit.edu Date: Fri, 10 Nov 2000 17:42:06 +0000 (GMT) Cc: dg@root.com (David Greenman), des@ofug.org (Dag-Erling Smorgrav), tlambert@primenet.com (Terry Lambert), chat@FreeBSD.ORG In-Reply-To: <20001109213842.U75251@149.211.6.64.reflexcom.com> from "Crist J . Clark" at Nov 09, 2000 09:38:42 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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