securing log file locations

[iseries]

Good day!

I am working as a security researcher. I found during a review of web servers of German municipalities and authorities that many Roundcube instances in production are not configured correctly. Also a recent investigation of German universities showed the same picture. I was able to view log files and temporary email attachments on over 30 instances.

The data that was drained during my investigation amounted to several GB. Among them were ID cards, passports, medical cards, various applications, birth certificates, and sick notes.

In other words, highly sensitive personal data.

Of course, the responsibility for a correct configuration lies with the operator of the application. After exchanging information with the CCC and various data protection authorities, I would like to point out this issue and suggest that it would make sense to change the software in future Roundcube versions so that log files and temporary attachments are stored outside the documentRoot by default. This would not only contribute to the security of data, but also strengthen the Roundcube software in general in its confidentiality.

Best regards, Rene Rehme

[ghost]

So in other words, you have access to their roundcube /logs and /temp directories? If that is so, it implies one of the following:

• the .htaccess files have been removed
• AllowOverride is set to none (or not enough permissions)
• a required Apache module is not loaded
• they don't use Apache, thus there is no support for .htaccess files

I would guess, that it is the administrators responsibility to install roundcube correctly and if they don't use .htaccess files then they should take the appropriate action to block access to /logs and /temp directories.

Your suggestion to store these things out of the public_html directory is reasonable, but it could complicate roundcube's installation?

[alecpl]

There's public_html folder in Roundcube for a reason. We do not force users to use it. I'm not sure we should (e.g. by providing index.php file under public_html only). But we recommend to use it in the INSTALL file (SECURE YOUR INSTALLATION section).

[iseries]

There's public_html folder in Roundcube for a reason. We do not force users to use it. I'm not sure we should (e.g. by providing index.php file under public_html only). But we recommend to use it in the INSTALL file (SECURE YOUR INSTALLATION section).

Sorry to bring this up again. The question is: Why should you not provide an index.php file under public_html only?

Setting up a virtual host that points to a public_html directory to ensure that all other directories are not accessible via the internet should simply be standard and would be a huge contribution to security. This is standard with every common php framework.

If you really can't see that this is currently a critical thing, then have a look on google, check the first 50 pages and think about it again. Here is an excerpt from my list of "misconfigured" Roundcube instances.

Best

[ghost]

So all those websites had the .htaccess file removed or made inoperable in some way.

I don't see how this is roundcube's fault.

[iseries]

Stop. It is not about who is to blame. It's about modifying software so that a standard installation guarantees maximum security. As you can easily see, it is a problem if you only give "additional" installation hints how to do a secure installation. It should be the standard from the beginning. Especially when it comes to sensitive files being processed.

[ghost]

Sure I agree, which is why roundcube comes prepared with .htaccess files to block all requests under /temp and /logs.

I did some research and I found many roundcube installations that allow access to all subdirectories like logs and temp, in addition to that, these websites are very badly configured and allow directory listing by default, thus I can see the complete contents of those directories!

[beckerr-rzht]

I think this is not about why these mistakes are made. The question is rather: Why is it possible to make these mistakes?

I see the folder structure used as the cause here. Why are $RC/config, $RC/log, $RC/vendor etc. in the DocumentRoot by default?

Using .htaccess as the only protection can be problematic. For example, the file $RC/temp/.htaccess could be deleted from the web server because it or at least $RC/temp belong to the user www-data.

For self-testing: dirb

For me it was an eye opener to scan the web server via dirb with a custom word file.

You may try it yourself:

find /var/www/html -printf "%f\n" | sort -u >/tmp/rc-words.txt
dirb https://example.com/roundcube /tmp/rc-words.txt -X ",.orig,.rej,.bak,~,.n,.o,.old,.off,.save"

Where /var/www/html and https://example.com/roundcube must of course be adapted to your own environment. It might also make sense to temporarily switch off the Apache log:

CustomLog /dev/null vhost_combined

[ghost]

I don't see any difference with other open source projects, Wordpress has its config file in the DocumentRoot, along with all the admin files.

I run dirb the way you run it, and all it found was publicly accessible files, nothing of interest or of value. Same thing that would happen if I run it on a Wordpress installation, theme files, CSS, JS, etc.

Again, all I see, is some idiot administrator who does not understand what .htaccess files are all about. So the question is, does Roundcube want/care to protect those idiots? Or should be move on to more important issues, like releasing version 1.6.1? :D

[ghost]

You are dancing around the issue:

Those admins removed or disabled .htaccess files...

My comparison is sound, you can butcher a Wordpress installation and make it insecure, is Wordpress at fault because of the idiot admin?

[iseries]

I made my point.

[haslersn]

I think the roundcube devs should reconsider their opinion about secure defaults. This issue should be reopened.

[david-sawatzke]

The ./INSTALL file mentions mod_rewrite, but https://github.com/roundcube/roundcubemail/wiki/Installation#protect-your-installation doesn't, leading to some people not enabling it.

If it isn't enabled, directory listing is disabled but log access isn't and thus cursory checks if this issue is fixed don't show any problem.

This isn't your fault, but the roundcube-core package from debian buster doesn't include the public_html folder: https://packages.debian.org/buster/all/roundcube-core/filelist, leading to further confusion (This isn't the case anymore in bullseye, thankfully).

[thomascube]

The folder structure of Roundcube is still the same as in the beginning of the project 15 years ago where the goal was to make it as easy as possible to install Roundcube by simply unzipping and uploading it to a web server via FTP. This was one factor that made it popular. Of course times have changed with great popularity also comes responsibility.

I agree to the concerns of @iseries et al that defaults matter. Personally I think we as the developers of a software package should do our best "so that a standard installation guarantees maximum security". Removing the index.php in the root folder and updating the documentation may already help a lot and should be a simple task. But @alecpl is in charge of technical decisions and I leave it up to him to re-open this issue.

[alecpl]

If others are ok with this switch, I'll be too. However, I foresee some problems with these links in public_html directory. I remember someone saying that on windows they might not be created when you unpack the release package. This could be documented, but I wonder what other issues we can have.

We can try this in master.

[iseries]

@alecpl That is a justified counter-argument. Of course, the system should run without errors - even under Windows. Would it perhaps be a useful workaround to simply add a simple check that checks the sensitive directories for accessibility?

[alecpl]

How would you check that? I don't think you can do that with a CLI script. And if that would be a CLI tool, you assume users will use it, which I doubt.

Another argument: access to the Installer. It would have to be a link too. Then probably the .htaccess file should be moved (the link replaced).

Thinking about these links. Maybe we should just move these directories there, instead of using links. But then it becomes more complicated, and migration probably would not be easy (not mentioning switching between older releases for development purposes).

[iseries]

I thought about a check in application's runtime like the garbage collector is done. I thought about something like this:

$headers = @get_headers($tempDirectory);
if($headers[0] === 'HTTP/1.1 401 Unauthorized' || $headers[0] === 'HTTP/1.0 401 Unauthorized') {
    // protected
}

Maybe also check to read an index.php file in the directory, too. How exactly this can then really look in the end should of course be carefully considered again.

[ner00]

From a Windows stand-point, I'm curious how this would work without needing additional mandatory configurations by hand. For one, Unix-like symlinks won't work under Windows, they can't even be extracted from a release archive due to the different implementation of soft-links between Windows and *nix.

Currently I have Apache properly configured and .htaccess protects the resources. Installations, upgrades and migrations are a breeze - even cross-platform; but I see how that might be a problem if the target webserver is mis-configured and unsecured, which then shifts the onus of security entirely onto software developers, as is now the case.

I took a quick look at Squirrel mail and I personally wouldn't use that as an example, although it validates the original point. For example, logging is not enabled by default. It's not that it's not enabled, it's more like it literally does not exist in the core, you must install a 10 year old third-party plugin, so that's a win, I guess. The documentation on this portion is also outstanding, judging by the volume of questions on the matter over at StackExchange, probably as outstanding as the outdated release packages.

So this topic is of interest, I'm curious how much complexity and side-steps need to be introduced to cater to the fallibility of a few server admins. Or, contrary to my assumption, could turn out to be very easy to implement and maintain, which I admit would be the ideal outcome of this issue.

[ghost]

In my humble opinion, if the issue is with the logs and temp directories, then those two can be easily moved out of the public_html by just using sane defaults, like PHP's /tmp directory. Thus, we avoid any .htaccess problems and misconfigured web servers.

For example, PHP function sys_get_temp_dir returns the actual PHP temporary location.

[ner00]

Sure, no problem. Although an option to keep the current folder layout would be nice, I personally don't feel like keeping those folders in an external location if I know that the server is properly configured. And if by chance www-data is compromised, I have a bigger problem on my hands.

[ozgurkazancci]

The documentation was/is already clear enough.

@iseries I truly see your good point, however, web/server administrators should know what they install, how they install, what to protect and how to protect. They shouldn't be idiots. Especially the government ones -> too much critical data.

Just my two cents.

[Neustradamus]

To follow this ticket.