On Tue, 24 Apr 2012 17:06:27 +0200, Vincent Lefevre wrote: > On 2012-04-23 15:06:44 +0000, Camaleón wrote: >> On Mon, 23 Apr 2012 12:51:58 +0200, Vincent Lefevre wrote: >> >> > On 2012-04-20 14:37:11 +0000, Camaleón wrote: >> >> >> The user is the admin of his/her site and so the ultimate resposible >> >> for his/her site security. >> > >> > What do you mean by site security? AFAIK, the problem is a *host* >> > security problem. >> >> As Apache can be run in a multi-homed (virtual host) environmenet I can >> be the admin of *my* site (my apache configuration) but not for the >> others. I can fix my site but not the rest, meaning, there can be >> "sites" exposing a vulnerable configuration while another sites in the >> same host don't. > > 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). >> >> > There is a better solution: to fix mod_php and mod_rivet. >> >> >> >> What's the fix you propose? I mean, what's what you think is wrong >> >> in these two packages? Fixing the sample scripts? Are these scripts >> >> poorly written and exposing flaws? >> > >> > Your last questions make no sense. >> >> Sorry, the DSA explains little about the origin of the error and how it >> can be exploited. >> >> > The sample scripts are *not* in these two packages, but under /usr >> > /share/doc! So, there is nothing to fix in the sample scripts >> > themselves. The fix should be in the two packages, which shouldn't >> > execute scripts stored in a random directory, i.e. the scripts in >> > /usr /share/doc should just be seen as text files. This should be a >> > bit like CGI's: they are executed only if the ExecCGI option has been >> > set on the directory. >> >> 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? >> 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. 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. 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/jn6i0m$got$4...@dough.gmane.org
