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)
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)

Dan Yefimov wrote:

> > An unprivileged local user may send arbitrary signal to a child process
> > despite security restrictions.

> 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.

AIUI, the issue is that the unprivileged process gets to choose the
signal.

> 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.

Ordinarily, a process can assume that certain signals (those which can
only be generated by kill()) can only be received as a result of an
action by a sufficiently privileged process.

Also, other signals which could be triggered by the predecessor (e.g.
SIGALRM triggered due to alarm() followed by exec()) can normally be
prevented by specific means (e.g. resetting any outstanding timers).
This bug means that such steps are insufficient.

A consequence of this bug is that no signal can be trusted.

Also, if it's possible to set the signal to one which cannot be
blocked (SIGKILL, SIGSTOP), there's not much that the callee can do
about it.

> 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.

prctl() isn't specified by any standard; it's Linux-specific.

That's a significant part of the problem: code which isn't
specifically written for Linux isn't going to take steps to mitigate
this issue (e.g. reset the parent death signal).

But the suggestion that this should be reset on exec() (at least for a
suid/sgid binary) is sound, IMHO.

Moreover, I would suggest that exec()ing a suid/sgid binary should
reset *everything* which is not explicitly specified as being
preserved.

--
Glynn Clements <glynn (at) gclements.plus (dot) com [email concealed]>

[ reply ]
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