Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

[Dan Yefimov <dan () ns15 lightwave net ru>]

On Wed, 15 Aug 2007, Wojciech Purczynski wrote:

> > This doesn't change anything in what I said previously. If the sender's
> > EUID or RUID equals to any of SUID or RUID of the victim or the sender
> > process is root, the sender can send any signal to the victim; if none
> > of those conditions are met, it obviously can't, no matter how and what
> > signal it sends. For details look at check_kill_permission() and
> > group_send_sig_info() in kernel/signal.c and reparent_thread() in
> > kernel/exit.c in the kernel source tree (version 2.6.22).
>
> Dan, could you take a closer look at what setuid(0) does? In the beggining
> of setuid manual page you can read that:
>
>        setuid  sets the effective user ID of the current process.
>        If the effective userid of the caller is  root,  the  real
>        and saved user ID's are also set.
Yes, I knew that before.

> In this case check_kill_permission() returns -EPERM for unprivileged
> parent.
You always talked about setuid root process sending PDEATH_SIG to the root 
child, didn't you? check_kill_permission() checks current->euid and
current->uid against t->uid and t->suid, where 'current' is the pointer to the 
task_struct of the sender, or, in our case, of the dying setuid root process, 
and 't' is the pointer to the task_struct of the root child. If one of those 
checks succeeds then the entire check_kill_permission() succeeds. current->euid 
is in our case 0, t->uid and t->suid are 0 too. So where is the problem? 
-- 

    Sincerely Your, Dan.