Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
Dan Yefimov wrote:
> > > Really? An what if we fork right after startup and perform operations as
> > > a
> > > child?
> >
> > That would work, but might have undesirable consequences of its own.
> >
> > In particular, it prevents a non-malicious caller from using PDEATHSIG
> > to send e.g. SIGINT, which the setuid program may reasonably handle.
In retrospect, I realise that this is self-contradictory. Well, sort
of; more accurately, I'm arguing both sides. Even if delivery of
PDEATHSIG is inhibited, there might be other reasons to avoid an extra
fork.
> So I don't understand you, whether is the bug in question a DoS issue or not
> in
> your opinion? IOW, do we need to reset pdeath_signal on exec()ing the
> setuid/setgid binary or not?
There definitely appears to be potential for DoS against system-wide
resources.
There could be other consequences, depending upon the extent to which
any given setuid binary relies upon the OS to restrict signals.
Personally, I would lean towards PDEATHSIG being reset upon exec() of
setuid/setgid binary. Mainly because this feature is a Linux
extension; even if it's possible to protect against this feature,
binaries which aren't specifically written for Linux won't be allowing
for it.
> > > And this IS generally impossible. Once spawned setuid root binary that
> > > will
> > > send a signal while dying, you have no control over the moment the signal
> > > is
> > > being sent at. The exploitation scenario for this bug is a bit artificial.
> >
> > IMO, privilege elevation is a security issue regardless of whether or
> > not one can provide a "useful" scenario immediately upon the issue
> > becoming known.
>
> I talked about the severity of this bug here.
I would agree that this isn't a particularly high-severity bug. On one
hand, it can be triggered reliably; on the other hand, it requires
local access and probably can't achieve more than DoS.
Even so, the restrictions on the sending of signals are considered a
security mechanism, so I don't think that it's unreasonable to
consider this a security issue regardless of the extent to which
existing setuid binaries are affected by it.
AFAICT, the intent was that PDEATHSIG would be subject to the same
kind of restrictions as kill() or F_SETOWN etc. But in this case, the
"sender" is incorrectly determined as the EUID at the point that the
process dies rather than the point that prctl() was called. Recording
the actual "initiator" probably isn't feasible, so clearing PDEATHSIG
on setuid exec() is probably the only viable solution.
--
Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>