On Tue, Dec 28, 2010 at 12:24 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Dec 28, 2010 at 12:11:47PM -0500, Nico Kadel-Garcia wrote:
>> As Stefan pointes out elsewhere, svnserve will run without an
>> svnserve.conf. Perhaps it *shouldn't*, and the default svnserve.conf
>> should be published as svnserve.conf.tmpl? That would force manual
>> enabling of a service that should not be available by default.
>
> svnserve reads the repository's svnserve.conf file when it receives
> a client request concerning this repository. In other words, there is
> nothing we can do in the repository-specific svnserve.conf file to prevent
> svnserve from starting in the first place.
Right. At the point where svnserve tries to read the svnserve.conf, it
could be configured to fail if the file is inaccessible. This is
vastly safer than automatically persevering and running an
unconfigured service.
> Also, I don't understand how starting svnserve would help an attacker
> since to start svnserve the attacker would already need access to
> the system.
>
> Users with shell access to the system can of course run their own
> svnserve instance on an unprivileged port (and svnserve runs on an
> unprivileged port by default).
This is a basic security principle. Everything not explicitly needed
should be disabled.
Allow me to present a very common situation. The administrator spends
their time on the Apache access, and carefully selects a thoughtful
setup to manage it, tests it, and is satisfied that read-access is
only available to authorized users. They even carefully set the
configuration files, themselves, to be owned by an administrator user
rather then same "Apache" or other user for the web access.
They don't even realize that svnserve will work by default. They don't
bother to disable it because it's not well documented in the manual
pages or red book, or another less careful admin enables the default
"svnserve" service in xinetd.d because they don't realize the danger.
And they, or another admin who doesn't realize that the Apache service
and svnserve security models are quite orthogonal, enables svnserve.
It's also a high-numbered port. Any schmuck with shell access can
start up the service, by default, on the standard access port.
*BOOM*, all the thoughtful Apache configuration work is ignored.
> There is no way to prevent this. The user might even copy an svnserve
> binary from a remote system and run it.
Well, yes. Guard rails don't block people who insist on climbing over
the rail. But putting the guard rail in place to remind people that
it's dangerous to go there is reasonable, especially when the guard
rail is so simple.
> But the same is true for any other network daemon that can be run on
> an unprivileged port.
You're treating the "unprivileged port" exactly backwards. As software
developers and project contributors, it's our responsibility to make
the default configurations as safe as possible, not say "oh, it's in
unprivileged port so we won't even care". Why such a system service
was ever put on an unprivileged port is a separate matter for
discussion.
And Subversion has some of the most well known for configuration
issues with the multiple access methods. Multiple access methods are
useful, but leaving multiple ones enabled by default is very awkward.
Received on 2010-12-29 16:43:51 CET