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 for Android: free password hash cracker in your pocket

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

Date: Thu, 16 Aug 2007 02:16:53 +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:

> Sending a signal to privileged process is a privilege itself.

Sure. But once control was transferred to some other code that we have no 
control over, we have no more control over when the signal is sent. We just 
can't send that signal at arbitrary moment. If you as an attacker can create 
arbitrary setuid root binary in the system, this game is not worth anymore, 
since you already won.

> Under some
> circumstances this may lead to other consequences. For example I was able
> to code local root exploit using some very common suid binary, although
> its usage is somewhat limited.
> 
Again, if an attacker can create arbitrary setuid root binary in the system,
the latter is already broken. And if the setuid root binary allows arbitrary 
code execution on getting some signal, it is vulnerable itself. Unexpected 
signals can be generated at any time by terminals, init, various system 
daemons, non-blocking i/o for files open before exec(), alarms, failed pageins, 
etc. If the program (not necessarily setuid/setgid) can't properly handle those 
situations, it is broken by design. Signals are not something we can trust.
-- 

    Sincerely Your, Dan.