From owner-freebsd-security Fri May 29 17:09:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05853 for freebsd-security-outgoing; Fri, 29 May 1998 17:09:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from iq.org (proff@polysynaptic.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA05827 for ; Fri, 29 May 1998 17:08:55 -0700 (PDT) (envelope-from proff@iq.org) Received: (qmail 674 invoked by uid 110); 30 May 1998 00:08:42 -0000 To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: Kill(2) Vulnerability References: <199805292031.NAA18667@passer.osg.gov.bc.ca> From: Julian Assange Date: 30 May 1998 10:08:41 +1000 In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Fri, 29 May 1998 13:30:58 -0700" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cy Schubert - ITSD Open Systems Group writes: > One of my co-workers brought this to my attention from > http://www.openbsd.org/errata.html#kill. > > SECURITY FIX > The kill(2) system call previously would permit a large set > of signals to be delivered to setuid or setgid processes. If such > processes were using those signals in dubious ways, this could > have resulted in security problems of various kinds. The second > revision of a source code patch which solves the problem is > available. It's perfectly reasonable for kill(2) to deliver A Large Set Of Signals to s[gu]id programs running under the same process group. The issue here is that its possible to send signals that the code has trapped internally (like SIGALRM). This is a userland issue in my opinion. Either pull out of the process group, or deal with the signals concerned. Cheers, Julian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message