On Tue, 24 Apr 2012 18:19:11 +0200, Vincent Lefevre wrote: > On 2012-04-24 15:48:38 +0000, Camaleón wrote: >> On Tue, 24 Apr 2012 17:06:27 +0200, Vincent Lefevre wrote: >> > You assume that there is just a user Apache configuration for each >> > virtual host. This is not the case. If a site decides to make script >> > contents available (as text), but then a global configuration (e.g. >> > the fact to install some Apache module) changes the behavior so that >> > the script, instead of being displayed as text, becomes executed when >> > the URL is opened, then it is not the site that exposes a vulnerable >> > configuration, but a global problem. >> >> Still a problem that has to be fixed by the admin of the site >> regardless its scope (global or local). > > This is just a workaround. The real problem hasn't been fixed. And this > means that it is no longer possible to read arbitrary documentation from > doc directories easily.
I'm still not sure about that mainly because I don't see other distributions (besides Ubuntu) fixing it :-? >> >> So you consider the flaw is "where", exactly? >> > >> > As I've said, in the mod_php and mod_rivet modules. >> >> Yes, but what part of the code you think it needs to be fixed. The *.so >> library file itself? > > I don't know how they work. Ideally modules that change the behavior > should be used with something like, e.g. for a module providing some > feature Foo: > > <Directory /path/to/dir> > Options +Foo > </Directory> > > Only sites (of parts of sites) that need such a module would do that. > Thus directories like /usr/share/doc would be unaffected by such > modules. > > Or if for some reason, the behavior may be enabled globally, the default > config for doc could be: > > <Directory /usr/share/doc> > Options -Foo > </Directory> > > to be sure that Foo is not used, even if the configuration is changed > somewhere else. Well, in one of my lenny servers (that don't have any of those "mod_" packages installed) the alias to the "/usr/share/doc" path is present in Apache's default config file. >> >> What do you think the packages are doing wrong? And most important, >> >> have you contacted the Apache guys to share your concerns with them? >> > >> > I know nothing about these modules (except that they will change the >> > Apache configuration), but this may also be due to Debian-related >> > settings. >> >> Mmm... "libapache2-mod-php5" and "libapache2-mod-rivet" are both >> conformed by a bunch of files, updating these would have been even >> easier than having to touch Apache's default config file(s), there must >> be a good reason for having proceed in this way, then. > > Perhaps because this hasn't been done yet? If they have hardcoded > non-configurable features, this may not be easy. It can be a possibility, yes. True is that I neither have found more detailed information about this security flaw. >> And now I think... I wonder if users running Lenny with any of these >> packages installed and the default alias to the doc path are also >> vulnerable. > > I would say: probably. The Mitre¹ site (updated recently) says "The default configuration of the apache2 package in Debian GNU/Linux squeeze before 2.2.16-6+squeeze7, wheezy before 2.2.22-4, and sid before 2.2.22-4 (...)", note the "before". Gee, I'm thinking in manually removing the alias block in the servers running Lenny where those packages are installed :-/ ¹http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0216 Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jn6m2f$got$7...@dough.gmane.org