Skip site navigation (1)Skip section navigation (2)
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>