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  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 <>
To: Wojciech Purczynski <>
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.

Powered by blists - more mailing lists