Description of problem: When the horde package is installed the default configuration has an unauthenticated administration account. Horde has a "feature" which allows administrators to execute arbitrary shell commands from the web interface. Thus, in the default configuration, anyone can execute an arbitrary shell command on the machine without authentication. Version-Release number of selected component (if applicable): horde-3.2.1-1.fc8 How reproducible: Always Steps to Reproduce: 1. Install horde package 2. Make sure Apache is running 3. Point browser at http://machines.ip.address/horde 4. Expand "Administration" menu 5. Follow the "CLI" link 6. Enter whatever shell command you want to be executed and hit the "execute" button Actual results: A compromised machine on a high bandwidth internet connection making thousands of SSH scans against some other poor sods. Expected results: Installing an RPM should _not_ create a huge security hole before you've even touched the configuration! Additional info: Notably this also affects CentOS 5.2, so I guess Red Hat Enterprise is also affected.
Few notes regarding this from IRC discussion with Nigel: Access to Horde is restricted by default to only allow connections from localhost. Therefore, the default configuration can only allow local users to take advantage of the not configured authentication. Quoting /etc/httpd/conf.d/horde.conf : # Comment out the following 3 lines to make Horde accessible from anywhere Order Deny,Allow Deny from all Allow from 127.0.0.1 Additionally, README.Fedora is pretty clear in explaining the security implications of default configuration, quoting /usr/share/doc/horde-*/README.Fedora : **IMPORTANT** By default, everyone accessing Horde is automatically logged in as 'Administrator'. This is a security risk! It is very important that you change the authentication backend under the 'Authentication' tab. For this reason, Horde is currently only accessible from localhost. To enable wider access, edit: /etc/httpd/conf.d/horde.conf Possibly adding a note to horde.conf [1] reminding administrator to read README.Fedora may make sense. But otherwise, risk and required post-installation manual steps are documented, and the security hole is only opened when admin chooses to change the default configuration. [1] Now committed as: http://cvs.fedoraproject.org/viewvc/rpms/horde/devel/horde.spec?r1=1.10&r2=1.11
Another possibility may be do some more magic in %post: - Check auth driver defined in /etc/horde/conf.php - If default driver is configured - $conf['auth']['driver'] = 'auto'; - do: - Change it to http (HTTP Basic Authentication) - Create password file in /etc/horde with single admin account and randomly generated password stored in plain text This is bit more effort, which may not be worth the effort, given the defaults described in the previous comment. Though it provides better safety net for administrators opening their systems to outside world without properly configuring them. Steve, do you still think Fedora defaults described in comment #1 to be insufficient?
Ah, of course, we can modify default conf.php to use http driver instead of auto by default, and only deal with password file in %post when needed.
Okay, as pointed out, by default _we_ prevent access to horde to only localhost, which means to exploit this, you'd need physical access to the machine, or have some way to get around Apache's security. As for other distributions, I'm not sure if they've done similar, I know CentOS Extras carries Horde, which until recently was newer than EPEL so it could be a case of their packages by default do suffer. I've filed this upstream (http://bugs.horde.org/ticket/7317) for their consideration, and my change as pointed out by Tomas will take during the next update that I push out.
Ok, apologies guys - it seems I didn't investigate this well enough. I had a CentOS server with horde installed from the extras repository (but never configured) which was compromised. Some investigation showed that CentOS does _not_ try to limit access in any way (unfortunately there doesn't seem to be any way to report bugs in CentOS extras packages. Anyway, CentOS problems are a matter for another bug tracker. :) However, I decided I'd check to see if Fedora had the same problem, and tested it from the local host, completely failing to spot that Fedora does restrict access to localhost. I'm not convinced that giving everyone on the local host shell access is an ideal situation (for example, if a machine has Squid and Horde installed, it is conceivable that remote users who would normally have no shell access on the machine could exploit this), but it is certainly better than not restricting it at all. I'm not sure adding warnings to the config file helps a lot (although it is a good idea) since the problem occurs if no configuration has been done, so the user probably hasn't even looked in the config files yet. Would it not be possible to ship Horde itself with a sensible default configuration which would either authenticate against the system's password file or require the user to poke at the config (and thus see the big warnings in the config file :) before allowing *anyone* to log in?
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.