Re: about DSA-2452-1 apache2 -- insecure default configuration
On 2012-04-24 16:57:52 +, Camaleón wrote: On Tue, 24 Apr 2012 18:19:11 +0200, Vincent Lefevre wrote: 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 :-? Perhaps it's Debian-specific (the bug was just about the default configuration), and users may also have an insecure (non-default) configuration on other distributions without knowing it. I've reported a bug for Debian, at least so that Debian gives more information about such security problems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670518 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120426111032.gg3...@xvii.vinc17.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On 2012-04-23 15:06:44 +, Camaleón wrote: On Mon, 23 Apr 2012 12:51:58 +0200, Vincent Lefevre wrote: On 2012-04-20 14:37:11 +, 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. 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. 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. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120424150627.gd3...@xvii.vinc17.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On Tue, 24 Apr 2012 17:06:27 +0200, Vincent Lefevre wrote: On 2012-04-23 15:06:44 +, Camaleón wrote: On Mon, 23 Apr 2012 12:51:58 +0200, Vincent Lefevre wrote: On 2012-04-20 14:37:11 +, 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
Re: about DSA-2452-1 apache2 -- insecure default configuration
On 2012-04-24 15:48:38 +, 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. 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. 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. 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. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120424161911.ge3...@xvii.vinc17.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On Tue, 24 Apr 2012 18:19:11 +0200, Vincent Lefevre wrote: On 2012-04-24 15:48:38 +, 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
Re: about DSA-2452-1 apache2 -- insecure default configuration
On 2012-04-20 14:37:11 +, Camaleón wrote: On Fri, 20 Apr 2012 01:50:29 +0200, Vincent Lefevre wrote: On 2012-04-19 15:08:55 +, Camaleón wrote: I can be wrong but the bug seems aimed to correct the package which contains the file that enables the alias by default, hence the apache2 package. But the user isn't necessarily the administrator. If the admin installs mod_php, making the bug appear if the user has added a symlink to /usr/share/doc, that's very bad. Sure, but in such case the user (who is in charge of the alias for their domains) will have to manually make the required corrections and the same goes for the vhosts. Except that if the user doesn't do this, the same security problem will occur. 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. There are times when a global solution can't be applied and this seems to be one of that situations. 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. 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. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120423105158.gb3...@xvii.vinc17.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On Mon, 23 Apr 2012 12:51:58 +0200, Vincent Lefevre wrote: On 2012-04-20 14:37:11 +, 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. 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? What do you think the packages are doing wrong? And most important, have you contacted the Apache guys to share your concerns with them? 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/jn3r64$68l$3...@dough.gmane.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On Fri, 20 Apr 2012 01:50:29 +0200, Vincent Lefevre wrote: On 2012-04-19 15:08:55 +, Camaleón wrote: I can be wrong but the bug seems aimed to correct the package which contains the file that enables the alias by default, hence the apache2 package. But the user isn't necessarily the administrator. If the admin installs mod_php, making the bug appear if the user has added a symlink to /usr/share/doc, that's very bad. Sure, but in such case the user (who is in charge of the alias for their domains) will have to manually make the required corrections and the same goes for the vhosts. Except that if the user doesn't do this, the same security problem will occur. The user is the admin of his/her site and so the ultimate resposible for his/her site security. There are times when a global solution can't be applied and this seems to be one of that situations. 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? If this is so, it has to be corrected in the upstream project and I guess other linux distributions are also affected by this, but I have not read any further notice. Anyway, if you're concerned on this, better contact the Debian Apache team, they'll be able to explain why the fix has been on the Apache's package default config file instead the other two. 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/jmrsan$o0u$9...@dough.gmane.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On Wed, 18 Apr 2012 18:24:34 +0200, Vincent Lefevre wrote: On 2012-04-17 15:39:48 +, Camaleón wrote: On Mon, 16 Apr 2012 14:25:17 +0200, Vincent Lefevre wrote: IMHO, the real bug is in mod_php or mod_rivet, that shouldn't be active (at least concerning the scripting features) by default unless this is explicitly told with some Options for the concerned directory. I can be wrong but the bug seems aimed to correct the package which contains the file that enables the alias by default, hence the apache2 package. But the user isn't necessarily the administrator. If the admin installs mod_php, making the bug appear if the user has added a symlink to /usr/share/doc, that's very bad. Sure, but in such case the user (who is in charge of the alias for their domains) will have to manually make the required corrections and the same goes for the vhosts. There are times when a global solution can't be applied and this seems to be one of that situations. 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/jmp9q7$kai$8...@dough.gmane.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On 2012-04-19 15:08:55 +, Camaleón wrote: On Wed, 18 Apr 2012 18:24:34 +0200, Vincent Lefevre wrote: On 2012-04-17 15:39:48 +, Camaleón wrote: On Mon, 16 Apr 2012 14:25:17 +0200, Vincent Lefevre wrote: IMHO, the real bug is in mod_php or mod_rivet, that shouldn't be active (at least concerning the scripting features) by default unless this is explicitly told with some Options for the concerned directory. I can be wrong but the bug seems aimed to correct the package which contains the file that enables the alias by default, hence the apache2 package. But the user isn't necessarily the administrator. If the admin installs mod_php, making the bug appear if the user has added a symlink to /usr/share/doc, that's very bad. Sure, but in such case the user (who is in charge of the alias for their domains) will have to manually make the required corrections and the same goes for the vhosts. Except that if the user doesn't do this, the same security problem will occur. There are times when a global solution can't be applied and this seems to be one of that situations. There is a better solution: to fix mod_php and mod_rivet. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120419235029.ga5...@xvii.vinc17.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On 2012-04-17 15:39:48 +, Camaleón wrote: On Mon, 16 Apr 2012 14:25:17 +0200, Vincent Lefevre wrote: IMHO, the real bug is in mod_php or mod_rivet, that shouldn't be active (at least concerning the scripting features) by default unless this is explicitly told with some Options for the concerned directory. I can be wrong but the bug seems aimed to correct the package which contains the file that enables the alias by default, hence the apache2 package. But the user isn't necessarily the administrator. If the admin installs mod_php, making the bug appear if the user has added a symlink to /usr/share/doc, that's very bad. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120418162434.gp3...@xvii.vinc17.org
Re: about DSA-2452-1 apache2 -- insecure default configuration
On Mon, 16 Apr 2012 14:25:17 +0200, Vincent Lefevre wrote: There has been the following change in apache2: apache2 (2.2.22-4) unstable; urgency=high * CVE-2012-0216: Remove Alias /doc /usr/share/doc from the default virtual (...) More information on: http://www.debian.org/security/2012/dsa-2452.en.html However, what if some user has a symlink to /usr/share/doc in his public_html? I haven't tried, but it seems that the bug would still occur (otherwise the right solution wouldn't have been to remove the alias, but to change how the scripting modules can affect some paths). The additional information for the updaters encourage users to review another configuration files that can be also affected: *** This updates removes the problematic configuration sections from the files /etc/apache2/sites-available/default and .../default-ssl. When upgrading, you should not blindly allow dpkg to replace those files, though. Rather you should merge the changes, namely the removal of the Alias /doc /usr/share/doc line and the related Directory /usr/ share/doc/$gt; block, into your versions of these config files. You may also want to check if you have copied these sections to any additional virtual host configurations. *** So at a first glance, I'd also say the bug can be present regardless the location of the hosted files but the DSA only addresses the default template config. IMHO, the real bug is in mod_php or mod_rivet, that shouldn't be active (at least concerning the scripting features) by default unless this is explicitly told with some Options for the concerned directory. I can be wrong but the bug seems aimed to correct the package which contains the file that enables the alias by default, hence the apache2 package. 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/jmk2s4$h73$1...@dough.gmane.org
about DSA-2452-1 apache2 -- insecure default configuration
There has been the following change in apache2: apache2 (2.2.22-4) unstable; urgency=high * CVE-2012-0216: Remove Alias /doc /usr/share/doc from the default virtual hosts' config files. If scripting modules like mod_php or mod_rivet are enabled on systems where either 1) some frontend server forwards connections to an apache2 backend server on the localhost address, or 2) the machine running apache2 is also used for web browsing, this could allow a remote attacker to execute example scripts stored under /usr/share/doc. Depending on the installed packages, this could lead to issues like cross site scripting, code execution, or leakage of sensitive data. -- Stefan Fritsch s...@debian.org Sun, 15 Apr 2012 23:41:43 +0200 More information on: http://www.debian.org/security/2012/dsa-2452.en.html However, what if some user has a symlink to /usr/share/doc in his public_html? I haven't tried, but it seems that the bug would still occur (otherwise the right solution wouldn't have been to remove the alias, but to change how the scripting modules can affect some paths). IMHO, the real bug is in mod_php or mod_rivet, that shouldn't be active (at least concerning the scripting features) by default unless this is explicitly told with some Options for the concerned directory. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20120416122517.ga31...@xvii.vinc17.org
