From owner-freebsd-security Sun Nov 1 21:00:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04585 for freebsd-security-outgoing; Sun, 1 Nov 1998 21:00:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04579 for ; Sun, 1 Nov 1998 21:00:46 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id AAA12214; Mon, 2 Nov 1998 00:00:23 -0500 (EST) Date: Mon, 2 Nov 1998 00:00:23 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Jan B. Koum " cc: Peter Jeremy , freebsd-security@FreeBSD.ORG, winter@jurai.net Subject: Re: SSH vsprintf patch. (You've been warned Mr. Glass) In-Reply-To: <19981101192724.A26335@best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 1 Nov 1998, Jan B. Koum wrote: > > The problem with C is that there are too many ways to shoot yourself > > in the foot... A full security audit on ssh (which it sounds like it > > might need) would be fairly time-consuming. > > Which is why when you install ssh, you can run ./configure with > "--disable-suid-ssh" argument. I imagine that the concern in the rootshell case is more that the daemon must run as root. It needs to do so for three reasons (that I can think of offhand): 1) To bind port 22 2) To read the system-wide SSH private key and most importantly: 3) To allow it to acquire the priveledges of the user who is logging in An alternative might be to have SSH run as non-root, give it a capability to have it bind 22, have the private key readable by that user, and then have it set up sockets to login (I don't know it can allocate vty's as non-root?) Then you don't get the SSH RSA-key behavior, but you'd get the rest. In a sense though, this is equivilent because: a buffer overflow allows the subversion of that SSH account, then that can be used to attach via debugging to the other sshd sessions to grab authentication information being forwarded to login. I guess you lose either way. Sensitive code (such as authentication code) must be written carefully. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message