pid file security

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

pid file security

Joey Hess
Take a look in /var/run. Find a pid file that is owned by a non-root
user. Now, look at the corresponding init script. What does it stop if
that non-root user edited the pid file to contain '1'?

I surveyed 20-odd daemons, and found 5 with this problem. This is
a pity, because start-stop-daemon has been able to guard against this
problem since its inception, by using the --exec or --name switches to
ensure that the process it stops is actually the daemon in question.

Of the scripts surveyed, one used start-stop-daemon without either
switch; others used things like pidofproc from the LSB init functions,
which does not do such checks, or asked the daemon to kill itself, and
it didn't check.

As security problems go, being able to DOS a system by killing targeted
processes, slowly, is not very bad. After all, it could be fork bombed
or OOMed just as effectively. Security aside, there's an overall correctness
issue: There's the chance that a daemon will unexpectly die, and its PID
be reused by an unrelated process, which is later incorrectly stopped.

There is room for improvement here; perhaps the developer's reference
should document best practices of using start-stop-daemon --stop --exec
or --name.

--
see shy jo, who has the feeling he wrote something similar a decade ago, *sigh*

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Yves-Alexis Perez-2
On mar., 2010-05-04 at 02:25 -0400, Joey Hess wrote:
> As security problems go, being able to DOS a system by killing targeted
> processes, slowly, is not very bad. After all, it could be fork bombed
> or OOMed just as effectively. Security aside, there's an overall correctness
> issue: There's the chance that a daemon will unexpectly die, and its PID
> be reused by an unrelated process, which is later incorrectly stopped.

And you usually need root access for invoke-rc.d or /etc/init.d scripts
(unless you have some kind of specific sudo permissions for that). So
you might be able to kill other process as well.

(it's still safer to test though)

Cheers,
--
Yves-Alexis

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Stéphane Glondu-3
Yves-Alexis Perez a écrit :
> And you usually need root access for invoke-rc.d or /etc/init.d scripts
> (unless you have some kind of specific sudo permissions for that). So
> you might be able to kill other process as well.

I guess one (be it a human operator or a monit-like daemon) can be
easily fooled into restarting a service without checking.


Cheers,

--
Stéphane


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4BDFC2FF.5080609@...

Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Salvo Tomaselli-3
In reply to this post by Joey Hess
On Tuesday 04 May 2010 08:25:25 Joey Hess wrote:
> Take a look in /var/run. Find a pid file that is owned by a non-root
> user. Now, look at the corresponding init script. What does it stop if
> that non-root user edited the pid file to contain '1'?

The fact that they are not owned by root doesn't mean you can edit them, they
would probably be owned by a specific user for that daemon and will not have
write access for others.
Have you found some with write permissions set to all?

Bye
--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/201005041000.13181.tiposchi@...

Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Philipp Kern-4
On 2010-05-04, Salvo Tomaselli <[hidden email]> wrote:
> On Tuesday 04 May 2010 08:25:25 Joey Hess wrote:
>> Take a look in /var/run. Find a pid file that is owned by a non-root
>> user. Now, look at the corresponding init script. What does it stop if
>> that non-root user edited the pid file to contain '1'?
> The fact that they are not owned by root doesn't mean you can edit them, they
> would probably be owned by a specific user for that daemon and will not have
> write access for others.

So if I trick the daemon to write 1 to that file it's ok?

Sure, tricking a program into doing something the admin didn't
intend is a bug in itself, still we shouldn't leave that hole
open.  (Putting the PID file a-w might help with that, though,
no?)

Kind regards,
Philipp Kern


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/slrnhtvr9r.m67.trash@...

Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Brian M. Carlson
In reply to this post by Joey Hess
On Tue, May 04, 2010 at 02:25:25AM -0400, Joey Hess wrote:
> Take a look in /var/run. Find a pid file that is owned by a non-root
> user. Now, look at the corresponding init script. What does it stop if
> that non-root user edited the pid file to contain '1'?

On Linux, nothing.  From kill(2):

  The only signals that can be sent to process ID 1, the init process,
  are those for which init has explicitly installed signal handlers.
  This is done to assure the system is not brought down accidentally.

Nevertheless, this could be a problem with other pids or on kfreebsd,
where the kernel will happily kill init and cause a panic.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Salvo Tomaselli-3
On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote:
> Nevertheless, this could be a problem with other pids or on kfreebsd,
> where the kernel will happily kill init and cause a panic.
And the pid could still be set to something else than 1 and bring down
something important.

--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/201005041902.23653.tiposchi@...

Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Brian M. Carlson
On Tue, May 04, 2010 at 07:02:23PM +0200, Salvo Tomaselli wrote:
> On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote:
> > Nevertheless, this could be a problem with other pids or on kfreebsd,
> > where the kernel will happily kill init and cause a panic.
> And the pid could still be set to something else than 1 and bring down
> something important.

Which is exactly what I said: "this could be a problem with other pids".
I understand the implications that Joey was talking about, but I was
just pointing out that the particular example he gave was not the best
for his argument.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pid file security

Goswin von Brederlow-2
In reply to this post by Stéphane Glondu-3
Stéphane Glondu <[hidden email]> writes:

> Yves-Alexis Perez a écrit :
>> And you usually need root access for invoke-rc.d or /etc/init.d scripts
>> (unless you have some kind of specific sudo permissions for that). So
>> you might be able to kill other process as well.
>
> I guess one (be it a human operator or a monit-like daemon) can be
> easily fooled into restarting a service without checking.
>
>
> Cheers,

If monit, runit, upstart, heartbeat or whatever is used to monitor
daemons does call stop+start then it is trivial. You are already the
user the daemon runs under (or you wouldn't have write permissions to
the pidfile) so just kill it. The next monitor run will then stop the
pid you wrote and restart the normal daemon wiping any trace of what you
did.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87vdb2bw4w.fsf@...