Bugtraq mailing list archives
Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability
From: Dan Yefimov <dan () ns15 lightwave net ru>
Date: Wed, 15 Aug 2007 21:54:35 +0400 (MSD)
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.
Current thread:
- COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Wojciech Purczynski (Aug 14)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 14)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Wojciech Purczynski (Aug 14)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Glynn Clements (Aug 15)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 15)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Glynn Clements (Aug 16)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 16)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Glynn Clements (Aug 16)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 17)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Glynn Clements (Aug 17)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 17)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Glynn Clements (Aug 20)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 20)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 14)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Nicolas Rachinsky (Aug 17)
- Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability Dan Yefimov (Aug 17)