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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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