From owner-freebsd-security Mon Jul 6 19:22:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27273 for freebsd-security-outgoing; Mon, 6 Jul 1998 19:22:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-62.waterford.indigo.ie [194.125.139.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27251 for ; Mon, 6 Jul 1998 19:22:22 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id DAA02400; Tue, 7 Jul 1998 03:17:56 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199807070217.DAA02400@indigo.ie> Date: Tue, 7 Jul 1998 03:17:54 +0000 In-Reply-To: David Greenman "Re: bsd securelevel patch question" (Jul 6, 4:45pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: dg@root.com, rotel@indigo.ie Subject: Re: bsd securelevel patch question Cc: "Allen Smith" , security@FreeBSD.ORG, njs3@doc.ic.ac.uk, dima@best.net, abc@ralph.ml.org, tqbf@secnet.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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