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

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.

Best

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.

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

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

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.