BugTraq
COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 14 2007 03:17PM
Wojciech Purczynski (cliph isec pl) (2 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 14 2007 09:03PM
Wojciech Purczynski (cliph isec pl) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 12:46PM
Dan Yefimov (dan ns15 lightwave net ru) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 07:09PM
Wojciech Purczynski (cliph isec pl) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 08:50PM
Dan Yefimov (dan ns15 lightwave net ru) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 09:05PM
Wojciech Purczynski (cliph isec pl) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 09:19PM
Dan Yefimov (dan ns15 lightwave net ru) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 09:37PM
Wojciech Purczynski (cliph isec pl)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 14 2007 06:20PM
Dan Yefimov (dan ns15 lightwave net ru) (2 replies)
On Tue, 14 Aug 2007, Wojciech Purczynski wrote:

>
> ===[ ABSTRACT ]=========================================================
>
> An unprivileged local user may send arbitrary signal to a child process
> despite security restrictions.
>
>
> ===[ AFFECTED SOFTWARE ]================================================
>
> Linux 2.6
> Linux 2.4
>
> For the exact kernel version please refer to an information provided by
> your vendor.
>
>
> ===[ DESCRIPTION ]======================================================
>
> Typically unprivileged user can not send signal to processes running
> with different UID. Due to vulnerability found in the Linux kernel any
> local user may bypass security restrictions and send arbitrary signal to
> any child process executed by the user.
>
> When a parent process dies or exits its child processes may receive a
> signal. Each child process may choose and set its own "parent process
> death signal" using PR_SET_PDEATHSIG function of the prctl() system
> call.
>
> PARENT CHILD
> ----------------------------------------------------------------
> fork()
> prctl(PR_SET_PDEATHSIG)
> exit()'ed or killed
> child receives the signal
>
> The parent process death signal is not reset over execve() system call
> and is inherited by spawned process:
>
> PARENT CHILD
> ----------------------------------------------------------------
> fork()
> prctl(PR_SET_PDEATHSIG)
> execve("./a.out")
> exit()'ed or killed
> child receives the signal
>
> The signal gets delivered only if parent process has sufficient
> privileges to send signals to child processes. Typically any child
> process running with higher privilege than its parent will receive no
> signal.
>
> PARENT CHILD
> ----------------------------------------------------------------
> fork()
> prctl(PR_SET_PDEATHSIG)
> execve("/bin/setuid-binary")
> exit()'ed or killed
> child receives NO signal this time
>
> However, above restriction may be bypassed if parent process execute
> setuid-root binary which dies afterwards.
>
> PARENT CHILD
> ----------------------------------------------------------------
> fork()
> prctl(PR_SET_PDEATHSIG)
> execve("/bin/setuid-binary")
> execve("/bin/setuid-binary")
> exit()'ed or killed
> privileged process receives the signal
>
>
I'm not sure this is a real security issue. If some process has the same
effective UID as the given one, the former can always send any signal to the
latter. Thus the behaviour you described is IMHO normal. If setuid program just
trusts the environment in that it doesn't properly handle or block signals
whose default action is terminating the process and doesn't perform it's
actions in a fail-safe manner, it is certainly broken. Setuid program must
always be careful in signal handling and data processing. From another hand,
PDEATHSIG should be always reset on exec() like signal handlers are (I'm not
sure though if that is directly specified by any standard). Please correct me
if I'm wrong.
--

Sincerely Your, Dan.

[ reply ]
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 03:23PM
Glynn Clements (glynn gclements plus com) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 15 2007 05:54PM
Dan Yefimov (dan ns15 lightwave net ru) (1 replies)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 16 2007 01:18AM
Glynn Clements (glynn gclements plus com)
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Aug 14 2007 08:18PM
Wojciech Purczynski (cliph isec pl)


 

Privacy Statement
Copyright 2010, SecurityFocus