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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44.0708160034490.4467-100000@D00M.lightwave.net.ru>
Date: Thu, 16 Aug 2007 00:50:58 +0400 (MSD)
From: Dan Yefimov <dan@...5.lightwave.net.ru>
To: Wojciech Purczynski <cliph@...c.pl>
Cc: bugtraq@...urityfocus.com
Subject: Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death
 Signal Vulnerability

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.