From owner-freebsd-security Wed Feb 7 03:13:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA20250 for security-outgoing; Wed, 7 Feb 1996 03:13:11 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA20242 for ; Wed, 7 Feb 1996 03:13:04 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id VAA10492 for security@freebsd.org; Wed, 7 Feb 1996 21:40:25 +1030 From: Michael Smith Message-Id: <199602071110.VAA10492@genesis.atrad.adelaide.edu.au> Subject: SS_PRIV, SIOCSIFADDR and rshd To: security@freebsd.org Date: Wed, 7 Feb 1996 21:40:25 +1030 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Something that's come out of a recent edification : Alan Cox stands accused of saying: > > > You may need to be a little more specific here; I see > > > > kern/uipc_socket.c so_create(): > > if (p->p_ucred->cr_uid == 0) > > so->so_state = SS_PRIV; > > If root a socket has SS_PRIV set allowing you to do SIOCSIFADDR etc. > > Now follow say in.rshd when its told to run not over a tty/pty pair. This > socket (created by root SS_PRIV) gets passed to a user process as fd 0. > Now what do you think happens when you do SIOCSIFADDR ioctls on fd 0 of > a program run that way via rsh. Processes created by inetd should also > be able to exploit this. Anyone in a position to comment on this? I can't see anything obvious that resets SS_PRIV (or any of the socket state attributes) on either exec or set*id... -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "wherever you go, there you are" - Buckaroo Banzai [[