BOA settings.php security [#1814836]

Why barracuda stores passwords as plain text in settings.php files?
So a user can read all the passwords quite easily.
An octopus instance called o1 can access all settings.php files of all other octopus instances...

I know that Aegir project, does hide the passwords and instead uses environment variables.

Comments

Comment #1

omega8cc CreditAttribution: omega8cc commented 17 October 2012 at 08:51

Title:	Barracuda settings.php security	» BOA settings.php security
Project:	Barracuda	» Octopus
Category:	bug	» feature
Priority:	Critical	» Normal

It is not possible to use the Apache SetEnv method in Nginx, because there is no Nginx config equivalent, so Nginx based Aegir by design disables hiding database credentials from settings.php. We could try to use fastcgi_param method, probably.

Also, BOA manages secure enough permissions, so the attacker would have to know the full system path to the site to try to read its settings.php file, but note that no user has access to the Aegir system user, and only to the limited shell and FTPS user, which is locked in its virtual chroot, so it is not easily possible to access files between Octopus instances.

If you host untrusted users, you should make sure to use better system user names than o1, o2, o3 etc, to make the path guessing harder for those trying to crawl the system via SFTP, which doesn't respect limited shell nor FTPS virtual jail/chroot, but is still hard and would require guessing, because BOA blocks read access for some critical directories in the system to prevent it.

I'm changing this to feature request, as we should investigate possibility to use fastcgi_param method.

Comment #2

hejazee CreditAttribution: hejazee commented 17 October 2012 at 09:04

I think Aegir is wrong in base idea.
I think it would be much better if aegir made one unix user per site.
So it would be able to define strong access policies.

I have an Idea to open a new project like BOA, but without using drupal's multisite feature.
We'll have a shared code base of all drupal releases and modules; with read access for all users.
Then when we want to make a new site, we'll simply make some symbolic links.
each user will have a dedicated drupal site (with shared code base) and strong access controls.
But I don't have enough linux knowledge so that I can create it right now.

Comment #3

hejazee CreditAttribution: hejazee commented 17 October 2012 at 09:14

When an attacker or even an 'untrusted' user who owns an octopus instance, gains access to execute php code either via devel.module or php filter or possibly some kind of drupal bug, He will be able to execute php code.
And he can use file_get_contents() to read all the settings.php files

Guessing the names of users on the system is not so hard...
I have tried it!

Comment #4

omega8cc CreditAttribution: omega8cc commented 17 October 2012 at 09:17

Creating separate system user per site doesn't fix anything, since the web server needs to be able to read settings.php files and you must add FTPS/SSH user managing the site to the web server group so it will have a chance to manage site's files (many of them are created and owned by web server user, which is shared).

You may want to read this: #762138: Design security issue with developer access to sites' modules and themes