From owner-freebsd-chat  Fri Nov 10 10:21:37 2000
Delivered-To: freebsd-chat@freebsd.org
Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82])
	by hub.freebsd.org (Postfix) with ESMTP id 8F38937B479
	for <chat@freebsd.org>; Fri, 10 Nov 2000 10:21:31 -0800 (PST)
Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net  with Microsoft SMTPSVC(5.5.1877.197.19);
	 Fri, 10 Nov 2000 10:20:05 -0800
Received: (from cjc@localhost)
	by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id eAAILMh99539;
	Fri, 10 Nov 2000 10:21:22 -0800 (PST)
	(envelope-from cjc)
Date: Fri, 10 Nov 2000 10:21:22 -0800
From: "Crist J . Clark" <cjclark@reflexnet.net>
To: Terry Lambert <tlambert@primenet.com>
Cc: David Greenman <dg@root.com>, Dag-Erling Smorgrav <des@ofug.org>,
	chat@FreeBSD.ORG
Subject: Re: ftp.freebsd.org b0rked?
Message-ID: <20001110102122.A99378@149.211.6.64.reflexcom.com>
Reply-To: cjclark@alum.mit.edu
References: <20001109213842.U75251@149.211.6.64.reflexcom.com> <200011101742.KAA22146@usr08.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200011101742.KAA22146@usr08.primenet.com>; from tlambert@primenet.com on Fri, Nov 10, 2000 at 05:42:06PM +0000
Sender: owner-freebsd-chat@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Fri, Nov 10, 2000 at 05:42:06PM +0000, Terry Lambert wrote:
> > >    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.

How does ensuring each packet has application data ending with a CRLF
protect against that?
-- 
Crist J. Clark                           cjclark@alum.mit.edu


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message