Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 07 Sep 2017 12:29:50 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: Simon McVittie <smcv@...ian.org>, oss-security@...ts.openwall.com
Subject: Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation

On Thu 2017-09-07 16:27:25 +0100, Simon McVittie wrote:
> Ideally, the sequence of events would be something that ensures that
> the pid file already exists by the time readiness has been announced,
> like this pseudocode:
>
>     have the necessary privileges to write a pid file
>     fork
>     if (parent) {
>         write child pid to pid file
>         exit    /* tells supervisor we are ready */
>     }
>     else /* child */ {
>         drop privileges
>         while (1) { process request }
>     }

Is there a potential race condition here?  for example, if dropping
privileges takes some amount of time, or if there is additional setup
that ought to be done as non-root (building tables, pre-processing a
dataset from the filesystem, initializing a PRNG), then this pattern is
actually pretty hard to get right as a notification.

the options seem to be:

 0) if dropping privs is known to be fast, then move any lengthy
    initialization/setup into the root/pre-fork side.  this is a
    violation of the principle of least privilege.

 1) establish a communication channel between the child and the parent,
    and have the child explicitly signal to the parent that it is ready
    so that the parent can exit() appropriately.

but (1) is at least as much work as any of the other forms of explicit
notification to the service manager directly, so it's not clear that
forking is a great way to provide such notification.

        --dkg

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ