From owner-freebsd-security Thu Jul 2 09:23:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21998 for freebsd-security-outgoing; Thu, 2 Jul 1998 09:23:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA21982 for ; Thu, 2 Jul 1998 09:23:06 -0700 (PDT) (envelope-from andrew@squiz.co.nz) Received: from [192.168.1.2] (mac.sky [192.168.1.2]) by aniwa.sky (8.8.7/8.8.7) with SMTP id EAA07119 for ; Fri, 3 Jul 1998 04:22:46 +1200 (NZST) (envelope-from andrew@squiz.co.nz) X-Sender: andrew@192.168.1.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Jul 1998 04:26:00 +1200 To: security@FreeBSD.ORG From: andrew@squiz.co.nz (Andrew McNaughton) Subject: Re: bsd securelevel patch question Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Eh? If ssh/smtp/inetd bind to the port you won't be able to, no >matter how often you try. Unless the server is restarted for some reason. hence the rapid cron job which will eventually succeed if not detected first. >And you won't be able to steal keys >by hijacking sshd. If the trojan gets to tell the other end what public key to use, then of course it can get at the data stream. This is equally true with routing/man-in-the-middle attacks. Without access to master.passwd though it can't do a very good job of masquerading as an authentication agent. It will fail to emulate any authentication unless that can be done by accepting any connection regardless. I don't know enough about the authentication systems ssh uses to know which if any are vulnerable here. >I still agree with you for other reasons though, if an attacker >creates a new service people might use it even though it isn't a >legitimate service setup my the sysadmin. > >Whats wrong with a /dev/socket/tcp/XYZ acl type scheme? If the >process has permission to read /dev/socket/tcp/83 then they can >bind to port 83, you could make it a procfs type filesystem so all >the ACL information was in memory for speed. Then you've got to >save/restore state though. > >Niall I don't know enough about TCP/IP details to know if this makes sense, but perhaps you could use these as more than just flags and allow programmers to bind to the socket by just opening the appropriate device file. ie #!/usr/local/bin/perl open (SMTP, "