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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.44.0708171740570.25626-200000@D00M.lightwave.net.ru>
Date: Fri, 17 Aug 2007 18:07:18 +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 Fri, 17 Aug 2007, Glynn Clements 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.
> 
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?

> > > SIGKILL and SIGSTOP cannot be blocked, handled or ignored.
> > 
> > As for SIGKILL, I again repeat that the program must operate in a fail safe way 
> > when that makes sense.
> 
> It's really a question of whether it's possible rather than "making
> sense". Eliminating critical sections is desirable, but it isn't
> always possible.
> 
Of course, critical sections are unavoidable, but there can be measures 
undertaken to minimize their impact. That is what I talk about.

> > BTW, SIGKILL and SIGSTOP can be issued by an O_ASYNC file I/O also (look in 
> > fcntl(2) at F_SETSIG section). If you use F_SETSIG for sending SIGKILL or 
> > SIGSTOP, there's nothing to be done with that - that behaviour is well 
> > documented and setuid root program must know which file descriptor should be 
> > closed to prevent that, which is of course not possible. The only cure here is 
> > closing every file descriptor above 2, but that is still insufficient, since 
> > fcntl() might be issued on file descriptors from 0 to 2.
> 
> The fcntl(2) manpage says:
> 
>     Sending  a  signal  to  the  owner  process (group) specified by
>     F_SETOWN is subject  to  the  same  permissions  checks  as  are
>     described for kill(2), where the sending process is the one that
>     employs F_SETOWN (but see BUGS below).
> 
> Also, note the use of the term "permissions checks"; this is
> considered a security mechanism.
> 
Yes, I just learned that from the kernel source, so my apologies for the false 
alarm :-)

> > 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 see it's much simpler to post 
the patch fixing it rather than endlessly discussing it here. Anyway, I'm not 
inclined to consider signals a reliable and secure information source. They are 
rather a subsidiary facility. Attached a patch that is meant to fix a bug in 
question.
-- 

    Sincerely Your, Dan.

View attachment "linux-2.6.22-pdeathsig.patch" of type "TEXT/PLAIN" (789 bytes)