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]

Message-ID: <Pine.LNX.4.44.0708152118010.5229-100000@D00M.lightwave.net.ru>
Date: Wed, 15 Aug 2007 21:54:35 +0400 (MSD)
From: Dan Yefimov <dan@...5.lightwave.net.ru>
To: Glynn Clements <glynn@...ements.plus.com>
Cc: bugtraq@...urityfocus.com
Subject: 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.