Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Jul 1998 03:17:54 +0000
From:      Niall Smart <rotel@indigo.ie>
To:        dg@root.com, rotel@indigo.ie
Cc:        "Allen Smith" <easmith@beatrice.rutgers.edu>, security@FreeBSD.ORG, njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com
Subject:   Re: bsd securelevel patch question
Message-ID:  <199807070217.DAA02400@indigo.ie>
In-Reply-To: David Greenman <dg@root.com> "Re: bsd securelevel patch question" (Jul  6,  4:45pm)

next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 6,  4:45pm, David Greenman wrote:
} Subject: Re: bsd securelevel patch question
> 
>    I think you are missing what I'm saying. Again, I'm saying that the FTP
> client is the thing that initiates the passive mode (via the PASV command) -
> not the server and thus your suggestion to "just use passive FTP on the
> server" to get around needing privileged-port bind()s in the server is
> simply not an option.

Right, what I meant was to provide the option of disabling the PORT
command.  Yes, I know this will confuse people and break things,
but I think its a reasonable choice to offer the administrator.
What ever else do they do anyway? :)

I wonder if initiating active mode data connections from an undefault
(!) data port would break much.  I notice /usr/bin/ftp doesn't
"authenticate" this, in fact it doesn't even check the peer's IP,
maybe this is something to do with not breaking FTP proxies; I
don't know how they work.  At least a warning would be appropriate
though?

> >  As for the security, I'd
> >prefer to allow connects in to the ftp servers on ports I know it
> >will be listening on rather than having a machine inside the DMZ
> >initiating TCP connections;  having said that, FreeBSD's ftp daemon
> >currently accepts connections on ports it is listening on from any
> >IP, in accordance with the FTP RFC, but this is inconsistenct with
> >the bahaviour of the PORT command in paranoid mode which will only
> >connect to the IP of the control channel peer.  What do you think
> >of patching this?
> 
>    Are you talking about the data port listens that ftpd does when it is
> operating in passive mode? If so, then you're wrong - ftpd listens for the
> control channel IP address.

No it doesn't; check dataconn() in ftpd.c, it simply accepts the
connection after using select for timeout.  The "authentication"
for PORT occurs as part of parsing the PORT command in host_port in
ftpcmd.y

BTW, UNPv2 mentions a possible race condition between the select
returning and the call to accept on TCP implementations which wake
the process on receipt of a SYN, in which case receipt of a FIN or
RST can shutdown the 3-way handshake between select returning and
the call to accept.  Does this apply to FreeBSD?  From looking at
tcp_input it seems not, the call to sonewconn() on line 397 specifies
a second argument of 0 which seems to indicate that waiting processes
should not be woken, I'd appreciate if you could confirm this is
the case.

[ in case anyone's wondering how you get around that in OSs it does
  apply to you can set the socket non-blocking and check for
  EWOULDBLOCK from accept ]

>    As for non-passive FTP and the PORT command, the behavior of ftpd (that is,
> to do the connect to the address specified) is required in order to support
> FTP proxies and can't be changed without breaking that. Thus the "paranoid
> mode" is bogus and not only does it violate the RFC, but breaks functionality
> which many people find useful and necessary...in fact, thwarting their own
> attempts at improving security (admins don't uses FTP proxies just to make
> life more difficult for their users).

Well, breaking the RFC is necessary in most environments; I sure
don't want any of my ftp daemons making connections to hosts inside
my network under the control of someone outside, or connecting to
anyone's priviledged ports.  Again, its a site policy decision.
Still, I see what you mean about ftp proxies.  An ACL for the list
of allowable PORT destinations would solve this, but is probably
more useful as part of a dedicated anonymous ftp daemon.

Niall

-- 
Niall Smart.        PGP: finger njs3@motmot.doc.ic.ac.uk
FreeBSD: Turning PC's into Workstations: www.freebsd.org

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807070217.DAA02400>