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

On Wed, 15 Aug 2007, Glynn Clements wrote:

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

The signal in question in the given situation is issued by PRIVILEGED process, no matter how. Well written program must not depend on anything that is out of it's control.

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

Sure.

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

Yes, and well written program must operate in a fail safe way, that is if it is killed, for example, by sadly known OOM killer, all data it operated on must remain in a consistent state.

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

In fact, PDEATHSIG should be reset for every binary, not just suid/sgid, since it emits signal that exec()ed program may not expect. But in any case, every program shouldn't trust any signal in the system. That is a good tone rule. I still don't see why this bug should be considered as a security issue but not as an ordinary bug.

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

Specified with what? Do open files fall into this category? Does blocked signal bitmap fall into it? What exactly are you going to reset?

-- 

    Sincerely Your, Dan.