A tale about trusted_domains

ownCloud is all about protecting your data and as part of our development cycle we’re proactively auditing and assessing the security of ownCloud. In fact, most security bugs that we fix are discovered by our very own security team and not by third-party researchers (although, keep those fixes coming third-party researchers!).

Many of the bugs with potential security impact are – from a technical point of view – trivial to patch and do not require any configuration changes by the ownCloud administrator. (i.e. you)

While reading a recent article on “Synchronize Your Life with ownCloud” published on the Linux Journal I stumbled upon the following sentence:

After all of the installation is complete, you won’t able to access your new ownCloud installation. To resolve this problem, you have to edit ./config/config.php and comment out the trusted_domains line. This is a security setting that determines which domains clients are able to connect from, and by default, limits access only to localhost. I happen to think the default values are a bit strict.

First let me say, this article, for the most part, was terrific – a simple primer on getting ownCloud up and running quickly, however…

The problem with it

The trusted_domains settings was introduced as a result of one of those exceptional security bugs that could require some manual intervention to be fully addressed.

Obviously, removing a configuration switch that was introduced for security reasons it not a viable option and we highly discourage it. In fact, with our upcoming ownCloud 8.1 release this switch cannot be removed anymore.

If even experts who write for reputable online magazines sometimes misunderstand this configuration switch, it is an indicator for us to publish a blog post explaining the reasoning behind the trusted_domains option within config.php. So we’re glad to be able to use this opportunity to explain the security impact of it.

Generally speaking this configuration option addresses a bug known to the security community as “Host Header Poisoning”.

As host in this context is the domain or IP address meant that you used when setting up your very own ownCloud instance. For example the host of our demo installation at “demo.owncloud.org” is obviously “demo.owncloud.org”.

When visiting a website such as “owncloud.org” your browser is – to put it greatly simplified and some technical incorrectness for the sake of simplicity – doing the following things:

1. Resolving the IP address of owncloud.org (which is at the point of writing 50.30.33.236, you can find this out yourself by issuing nslookup owncloud.org from a terminal)
2. Connecting to said IP address via HTTP and instructing the server behind this address to give him the content of “owncloud.org”
3. The server is then returning the content of “owncloud.org” to the browser which shows it to the end-user.

In step 2 what is given to the server is done via the so called “Host Header”. ownCloud uses the header value that have been given to it here also to create URLs, one prominent and obvious example is the “Password Reset Functionality” which sends via mail a link to reset the user’s password. (for example http://demo.owncloud.org/index.php/lostpassword/reset/form/{token}/{username})

But if an attacker would in step 2 send the domain “attacker.com”, the generated URL by ownCloud – which is sent to the real user via mail – would point to http://attacker.com/index.php/lostpassword/reset/form/{token}/{username}. If a user then clicks on the link the real password reset token is leaked to the attacker. This gets even worse if you consider that some commercial antivirus software automatically checks all links embedded in mails. There are also quite some other attack vectors, that’s only the most obvious and easiest to explain one.

Technologies are often built to be forgiving, that means that even if an input does not technically make 100% sense, modern parsers are trying to make sense out of it. So even if you have different virtual hosts (that is: hosting several websites on the same server) there are some ways to trick the web server to deliver the request to the correct virtual host.

That’s why we introduced the trusted_domains setting, using this setting you can define which hosts are considered acceptable. So if only “demo.owncloud.org” is defined you cannot access the instance anymore with a forced header of “attacker.com”.

Making administrators life easier

Because we all know that fiddling manually in the config might be cool but can be quite complex we added a new wizard to ownCloud 7.0.2 allowing you to add new domains to the trust list with just a few clicks:

Also when installing ownCloud it will automatically add the domain/IP that has been used while setting it up to the trust list.

To sum it up: This is an important setting which greatly enhances the security level of your ownCloud installation and you should take the time to configure it properly.

That said, I personally appreciate any article about ownCloud and highly recommend you to take a look at “Synchronize Your Life with ownCloud” published on the Linux Journal.

Let us know if you have any questions about this headers or have further ideas how we can improve ownCloud! Together we as a community can make ownCloud the best available solution.