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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 17 Aug 2007 22:33:35 +0100
From: Glynn Clements <glynn@...ements.plus.com>
To: Dan Yefimov <dan@...5.lightwave.net.ru>
Cc: bugtraq@...urityfocus.com
Subject: 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@...ements.plus.com>