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.