i noticed, that the gentoo linux default configuration is insecure: an excerpt from /etc/apache2/conf/apache2.conf shows, that apache loads the following modules by default: LoadModule access_module modules/mod_access.so LoadModule auth_module modules/mod_auth.so LoadModule auth_anon_module modules/mod_auth_anon.so LoadModule auth_dbm_module modules/mod_auth_dbm.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule include_module modules/mod_include.so LoadModule log_config_module modules/mod_log_config.so LoadModule env_module modules/mod_env.so LoadModule mime_magic_module modules/mod_mime_magic.so LoadModule cern_meta_module modules/mod_cern_meta.so LoadModule expires_module modules/mod_expires.so LoadModule headers_module modules/mod_headers.so LoadModule usertrack_module modules/mod_usertrack.so LoadModule unique_id_module modules/mod_unique_id.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule mime_module modules/mod_mime.so LoadModule status_module modules/mod_status.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule asis_module modules/mod_asis.so LoadModule info_module modules/mod_info.so LoadModule cgi_module modules/mod_cgi.so LoadModule cgid_module modules/mod_cgid.so LoadModule vhost_alias_module modules/mod_vhost_alias.so LoadModule negotiation_module modules/mod_negotiation.so LoadModule dir_module modules/mod_dir.so LoadModule imap_module modules/mod_imap.so LoadModule actions_module modules/mod_actions.so LoadModule speling_module modules/mod_speling.so LoadModule userdir_module modules/mod_userdir.so LoadModule alias_module modules/mod_alias.so LoadModule rewrite_module modules/mod_rewrite.so ### ### New Modules for 2.0 (some are experimental) ### LoadModule file_cache_module modules/mod_file_cache.so LoadModule echo_module modules/mod_echo.so LoadModule charset_lite_module modules/mod_charset_lite.so LoadModule cache_module modules/mod_cache.so LoadModule disk_cache_module modules/mod_disk_cache.so LoadModule mem_cache_module modules/mod_mem_cache.so LoadModule ext_filter_module modules/mod_ext_filter.so LoadModule case_filter_module modules/mod_case_filter.so LoadModule case_filter_in_module modules/mod_case_filter_in.so LoadModule deflate_module modules/mod_deflate.so #LoadModule optional_hook_export_module modules/mod_optional_hook_export.so #LoadModule optional_hook_import_module modules/mod_optional_hook_import.so #LoadModule optional_fn_import_module modules/mod_optional_fn_import.so #LoadModule optional_fn_export_module modules/mod_optional_fn_export.so #LoadModule bucketeer_module modules/mod_bucketeer.so LoadModule logio_module modules/mod_logio.so especially, i don't like the following modules to be loaded: LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule userdir_module modules/mod_userdir.so i already learned, that gentoo default configuration does _not_ use these modules (proxy*), so an apache default installation should not be an open proxy. But the usage of mod_userdir is a nice method, to test for valid usernames on a system. and _this_ is definitely a security issue... a quick test shows: --->>> existent user (root) >>> http://127.0.0.1/~root <<< Forbidden <<< You don't have permission to access /~root on this server. <<< Additionally, a 403 Forbidden error was encountered while trying to use an <<< ErrorDocument to handle the request. --->>> existent user (flo) >>> http://127.0.0.1/~flo <<< Forbidden <<< You don't have permission to access /~flo on this server. <<< Additionally, a 403 Forbidden error was encountered while trying to use an <<< ErrorDocument to handle the request. --->>> nonexistent user (blah) >>> http://127.0.0.1/~blah <<< Not Found <<< The requested URL /~blah was not found on this server. so basically, testing for valid users on a system is easy with this configuration... basically, it would be a nice idea, to comment out most of the modules (which one?) and let the user decide, which modules should be loaded. best regards florian [rootshell]
Apache team: please comment.
We're aware of the bloat/security issues/etc and will be cleaning up the default config file for the next merge of the #gentoo-apache herd's apache tree. Thanks for the mod_userdir example, we'll be deactivating it.
Following policy, bug should remain assigned to security until resolved...
Please let us know when an updated default configuration will be shipped with Apache.
Apache herd : any target date for fixing this ?
I don't agree that it's a good idea to turn off mod_userdir. It's enabled by default on UPSTREAM, and the majority of our users would expect it to be switched on by default. The way to fix this would be to support more options in /etc/conf.d/apache[2], so that these modules are loaded or not based on the settings in that file. Best regards, Stu
as an alternative solution, what about if we make non-existant users return the same value as users that are blocked (403 forbidden)?
Yes, that would do it (IMHO). I would suggest using 404 rather than 403, if you have the choice.
umm, it's already giving a 404: the current logic is: if(userdir exists) { if(not denied) { serve page; } else { send 403 forbidden; } } else { send 404 not found; } changing the 403 to give a 404 is a bad idea as well, as it makes debugging hell.
Then make it both 403. I thought 404 was better because it doesn't give away the fact that mod_userdir is loaded, but I really don't care, as long as both cases (existent and non-existent users) return the same thing.
Changing the behaviour of Apache (especially as upstream won't accept this change) isn't something we should do. If you want that sort of fix, please take this bug upstream. Best regards, Stu
stuart: i was considering that this may be doable without any source changes. in the case that a user doesn't exist, ~foobar should fall through to the normal apache backend, where we can handle it via mod_rewrite or even mod_access possibly.
Re: Comment #12 I believe this is worse. It adds a complication to the configuration file, and does not resolve the issue of changing the error condition reported to the error log. I think the best resolution is to add a define 'USERDIR' so users can easily disable the module in conf.d/apache2. Adding a bogus configuration or changing the soruce code is far worse.
The security team goal is to have a "secure by default" configuration. Having one that let's attackers enumerate usernames of people on single-user systems not even knowing what mod_userdir is, is not secure by default. To solve this, we can view this thing from two angles : - we prefer to keep mod_userdir functionality on by default, in which case we must find a way of returning the same HTTP return code in both cases so that default installations are not vulnerable to a username guessing attack. - we prefer to keep different HTTP return codes for unknown user and forbidden access and then we should disable mod_userdir by default, so that default installations are not vulnerable to a username guessing attack. I thought it was easy to return the same code in both cases, I was probably wrong, then we should disable mod_userdir by default. mod_userdir is mostly used in multi-user systems where the admin can find his way and turn it on if needed...
Koon: would having it disabled by default, but re-enabled via the usual apache module route (-D USERDIR) satisify your security concerns?
Robin : that would be perfect :)
Hi Koon, We've already agreed that, as part of the merging in our Apache overlay, we'll switch off mod_userdir by default. The Apache Herd does *not* support changing the HTTP status codes which Apache returns. We respectfully ask that the security team takes that sort of request up with UPSTREAM. We feel that making this sort of change isn't what Gentoo is about, and needs to be handled by UPSTREAM. If the security team wishes to press for changes like this in future, then we'll need to raise the issue in a Monday managers meeting. Best regards, Stu
Everything is perfect then. Let us know when it's merged.
apache team... any news on this yet? It seems that mod_userdir is still loaded by default in the new ebuilds, right?
this is fixed in cvs now (gentoo-src/apache/dist/*/conf)
When will this make it into the tree?
These changes are already in the tree, though only in the new package.mask'd apache packages (currently, that is apache-2.0.52-r3 and apache-1.3.33-r1).
This will be available to users when we unmask. Bug 76457 (now added as a depend) is the tracker for this. There are currently a few blockers to us unmasking. We're working on getting these taken care of.
New packages unmasked -- bug fixed
