Mailing List Archive

> A further thought on scoreboard file security --- one way to fix this
> would be to put the scoreboard file in $(SERVERROOT)/logs by default, or
> at least to allow people to put it there if they wanted. Permissions on
> that directory could then prevent mischief from the hoi polloi...

Sounds better. It's be useful to have it use the same name *every* time,
so that the files don't pile up (one of our servers has a collection of
old scoreboards in /tmp, and on our HP /tmp doesn't get cleaned up
after a reboot).


> Is this a show-stopper, or can it wait for TNR?

It can certainly wait. It was only by accident that I noticed it.
It's safe from outside attack which is the important thing.


rob

Hmmm... setting the mode to 0644 on creation would reduce the prospects
for mischief, but not eliminate them (renaming the file would still be
possible, and a potential problem --- at least on SunOS, I can't find a
dup() variant that gives you an independant seek pointer, and the man
page for dup() claims none exists, so children need to reopen the score
file by name).

rst

A further thought on scoreboard file security --- one way to fix this
would be to put the scoreboard file in $(SERVERROOT)/logs by default, or
at least to allow people to put it there if they wanted. Permissions on
that directory could then prevent mischief from the hoi polloi...

Is this a show-stopper, or can it wait for TNR?

rst

Messing with the scoreboard file can result in a very confused server,
but I can't see how it would result in a security breach (it doesn't
affect anything about how the actual server processes do I/O)...

rst

Hmmm... the only way I can think of to provoke a full-scale fork bomb
is to keep zeroing out the file, which will cause the root process to
think that there aren't enough free servers running and fork off more...
NB that you have to write on the *same* scoreboard file which the root
server opened, since it is not continually reopening it. So, if the
attacker has write permission on the scoreboard, this is a problem; if
not, not --- and if the scoreboard isn't publically writable, then an
attacker who could write it could probably run the fork bomb themselves
anyway. (Come to think of it, that covers a lot of these scenarios).

rst

> Hmmm... the only way I can think of to provoke a full-scale fork bomb
> is to keep zeroing out the file, which will cause the root process to
> think that there aren't enough free servers running and fork off more...
> NB that you have to write on the *same* scoreboard file which the root
> server opened, since it is not continually reopening it. So, if the
> attacker has write permission on the scoreboard, this is a problem; if
> not, not --- and if the scoreboard isn't publically writable, then an
> attacker who could write it could probably run the fork bomb themselves
> anyway. (Come to think of it, that covers a lot of these scenarios).
>
> rst

Most NIXen I am familiar with have the sticky bit set on /tmp to
prevent anyone but the owner from moving/removing files. I've just
verified that both the SunOS system (4.1.3) and my NetBSD box have
been creating the files 600, and are not removeable by anyone but the
owner.

> A further thought on scoreboard file security --- one way to fix this
> would be to put the scoreboard file in $(SERVERROOT)/logs by default, or
> at least to allow people to put it there if they wanted. Permissions on
> that directory could then prevent mischief from the hoi polloi...
>
> Is this a show-stopper, or can it wait for TNR?

Question is can people's messing with the scoreboard file compromise the
server. If people can damage the file and kill the server then we'll end
up on bugraq by the end of the week ;) That would not be a good thing.

> rst

Ay.

> Messing with the scoreboard file can result in a very confused server,
> but I can't see how it would result in a security breach (it doesn't
> affect anything about how the actual server processes do I/O)...

Is it possible to convince the parent process that it should fork more
servers and hence promote a fork bomb attack? I guess not if there's
no way for anyone to write to the scoreboard.

> rst
>

Cheers,
Ay.

Andrew Wilson URL: http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Elsevier Science, Oxford Office: +44 01865 843155 Mobile: +44 0589 616144