Re: [Nolug] brain-dead Linksys (CISCO) engineers

From: Jimmy Hess <mysidia_at_gmail.com>
Date: Mon, 3 Nov 2014 20:46:19 -0600
Message-ID: <CAAAwwbVb=zBUVq7_O6auKPb70eBuCm_78SW+qD-6Ydx+jzhdwg@mail.gmail.com>

On Mon, Nov 3, 2014 at 8:46 AM, Joey Kelly <joey@joeykelly.net> wrote:
> Check this out...
> Any decent webserver is going to disallow access to HTTP AUTH .htaccess
> files, for obvious reasons. Any programmer with even a modicum of sense is

.htaccess files are an Apache extension, which are also only
supported on Directory paths with AllowOverride enabled and set to
something other than "none".

Apache WILL happilly serve up .htaccess files for anyone to see.
Most linux distributions include a default httpd.conf with

<Files ~ "^\.ht">
Deny from all
</Files>

However, not everyone uses these. Some people like to start with a
blank httpd.conf and configure things from scratch, and unless they
are extremely attentive, there will be security misconfigurations.

In case you blank the default config and write your own from scratch,
you will want to take .htaccess into account. Certainly if your
httpd.conf or .htaccess file uses the Basic Auth module with a
file-based backend; the file should not be in your web directory, and
the file should not be in a location that scripts launched by the
webserver such CGIs or PHPs will have read access to.

I would say best security practice would be to define access settings
in httpd.conf and set AllowOverride to none for all directories;
the httpd.conf and htpasswd files need to be readable to the
webserver, but they should not be world-readable, or accessible to
the user id that CGIs or PHP scripts are run as.

Then use mod_chroot to Chroot your Apache environment, and use
Filename-based sockets for inter process communications (with the
trusted daemon monitoring Socket file in your chroot), if a CGI
process is required to request changes outside the secure
environment, with the management processes designed for Separation of
Privilege and independent authentication (or assumption of compromise
of the contained web server process), and at that point, you have
the minimal degree of protection that should be expected from a
secure appliance.

> going to put the .htpasswd file out of the path of the webserver, just
> like the docs say. Not Cisco:
>
> http://www.kb.cert.org/vuls/id/447516
>
> --Joey Kelly

--
-JH
___________________
Nolug mailing list
nolug@nolug.org
Received on 11/03/14

This archive was generated by hypermail 2.2.0 : 11/07/14 CST