Re: [Vote] .htaccess logic abuse
When I am involved in Security questions I try to discuss security breaches in terms of confidentiality, integrity and availability. If something is suppossed to be confidential, but a workaround makes it not so - it is a security breach; idem for integrity - a workaround makes it possible to modify data without any application knowledge hence affecting application integrity; availability - if a workaround disrupts application availability then it is a security breach. On Fri, Nov 18, 2011 at 11:38 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: After several prods, it seems the security@ and hackathon participants can't be drawn out of their shells on to dev@. So I'll simply call for a majority vote on the following statement... Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [ ] Is not a security defect This would obviously need to be clarified in the associated .htaccess documentation, be associated with an advisory and affect the conclusion of several recent defect reports, both embargoed and discussed plainly here on this list.
Re: [Vote] .htaccess logic abuse
Hence - my vote - for what it is worth: [X] Represents a security defect On Sat, Nov 19, 2011 at 12:46 AM, Graham Leggett minf...@sharp.fm wrote: On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote: After several prods, it seems the security@ and hackathon participants can't be drawn out of their shells on to dev@. So I'll simply call for a majority vote on the following statement... Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [X] Represents a security defect [ ] Is not a security defect The config is clearly demarcated into two types, a trusted config loaded at startup time rooted at /etc/httpd (or wherever), and a limited untrusted config placed into .htaccess files within the content and loaded at runtime. If we were to declare .htaccess as containing trusted content only, most of the point behind .htaccess is lost. The trusted admin simply needs to merge .htaccess into the main config, and he gains load-on-startup and copy-on-write, there is little point in one common administrator scattering their config in two separate places or mechanisms. The people given the power to change both .htaccess and content are typically customers of a hosting company, or employees at a corporate, and admins are generally not comfortable exposing themselves to avoidable risk from either group. That said, I do concede that these two groups are more trusted than the typical end user who might access a site, but I still believe we should fix .htaccess problems as reported where it is practical to do so to bring the risk as low as is practical. Regards, Graham --
Re: [Vote] .htaccess logic abuse
On 12/26/2011 3:24 PM, Michael Felt wrote: Hence - my vote - for what it is worth: That's understood, but the vote was concluded, and the votes by the project committee members indicated a very clear consensus is that it would not be possible to provide for untrusted .htaccess files, in spite of a few votes to the contrary. This has been a topic of careful evaluation, unfortunately but by necessity in private on the security@ discussion list, and with this conclusion, we can begin to set about realistic expectations for web server administrators who choose to let anonymous and untrusted individuals host content plus configuration on those machines they are responsible and liable for... I'll post a document describing the dilemma tomorrow to dev@httpd, and we can update the docs accordingly.
RE: [Vote] .htaccess logic abuse
-Original Message- From: Stefan Fritsch [mailto:s...@sfritsch.de] Sent: Samstag, 19. November 2011 03:37 To: dev@httpd.apache.org Subject: Re: [Vote] .htaccess logic abuse On Friday 18 November 2011, William A. Rowe Jr. wrote: Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [X] Is not a security defect This would obviously need to be clarified in the associated .htaccess documentation, be associated with an advisory and affect the conclusion of several recent defect reports, both embargoed and discussed plainly here on this list. We should not make any promises we won't be able to keep. There are countless ways to cause a DoS from .htaccess. The .htaccess mechanism has not been designed with resource limitation in mind. Changing that will be a lot of work and will likely break ABI/API, i.e. the fixes won't be backportable to stable releases. We should treat those issues as regular bugs and make DoS safe .htaccess a goal. But we should make it clear that this goal likely won't be reached in 2.4.x and earlier. +1. Well put. Regards Rüdiger
Re: [Vote] .htaccess logic abuse
On Fri, Nov 18, 2011 at 04:38:14PM -0600, William Rowe wrote: After several prods, it seems the security@ and hackathon participants can't be drawn out of their shells on to dev@. So I'll simply call for a majority vote on the following statement... Thanks for the prod! Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [X] Is not a security defect I agree for resource consumption attacks. I think there's still a good case for treating bugs which allow escalation of privileges as security issues (i.e. something which gets you from an .htaccess file to arbitrary code execution in the httpd child). Regards, Joe
Re: [Vote] .htaccess logic abuse
On 21/11/2011 18:19, Joe Orton wrote: On Fri, Nov 18, 2011 at 04:38:14PM -0600, William Rowe wrote: After several prods, it seems the security@ and hackathon participants can't be drawn out of their shells on to dev@. So I'll simply call for a majority vote on the following statement... Thanks for the prod! Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [X] Is not a security defect I agree for resource consumption attacks. I think there's still a good case for treating bugs which allow escalation of privileges as security issues (i.e. something which gets you from an .htaccess file to arbitrary code execution in the httpd child). *cough* perl/lua *cough* But still, users need to be warned, but it's not a security defect IMHO. Issac
Re: [Vote] .htaccess logic abuse
On 11/21/2011 10:19 AM, Joe Orton wrote: I agree for resource consumption attacks. I think there's still a good case for treating bugs which allow escalation of privileges as security issues (i.e. something which gets you from an .htaccess file to arbitrary code execution in the httpd child). Afraid I agree with Issac, that impersonating nobody/nobody (Apache user/group) is always going to be barely protected. Allowing users to touch .htaccess always creates an avenue for getting their fingers into cgi configuration. We often stress that the Apache User/Group should have less privileges than typical local users, I guess this is one more section that we might repeat that refrain.
Re: [Vote] .htaccess logic abuse
On 19/11/2011 00:38, William A. Rowe Jr. wrote: Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [X] Is not a security defect The sysadmin knows best. If it's a problem, disable it (or the problematic type of directives via Options) on your system.
Re: [Vote] .htaccess logic abuse
Am 19.11.2011 17:44, schrieb Issac Goldstand: On 19/11/2011 00:38, William A. Rowe Jr. wrote: Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [X] Is not a security defect The sysadmin knows best. If it's a problem, disable it (or the problematic type of directives via Options) on your system. +1 where not everybody has the permissions to write .htaccess it is absolutly no problem, there where foreigen people can create such files the admin should know what he does inclduing every single option in httpd-configuration has as example the side-effect taht after a restart opcode-caches are empty which hurts more than .htaccess signature.asc Description: OpenPGP digital signature
Re: [Vote] .htaccess logic abuse
Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [x ] Is not a security defect No fine-grained controls on htaccess, we only provide the means to delegate entire classes of directive.
Re: [Vote] .htaccess logic abuse
On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote: After several prods, it seems the security@ and hackathon participants can't be drawn out of their shells on to dev@. So I'll simply call for a majority vote on the following statement... Resource abuse of an .htaccess config in the form of cpu/memory/ bandwidth; [X] Represents a security defect [ ] Is not a security defect The config is clearly demarcated into two types, a trusted config loaded at startup time rooted at /etc/httpd (or wherever), and a limited untrusted config placed into .htaccess files within the content and loaded at runtime. If we were to declare .htaccess as containing trusted content only, most of the point behind .htaccess is lost. The trusted admin simply needs to merge .htaccess into the main config, and he gains load-on-startup and copy-on-write, there is little point in one common administrator scattering their config in two separate places or mechanisms. The people given the power to change both .htaccess and content are typically customers of a hosting company, or employees at a corporate, and admins are generally not comfortable exposing themselves to avoidable risk from either group. That said, I do concede that these two groups are more trusted than the typical end user who might access a site, but I still believe we should fix .htaccess problems as reported where it is practical to do so to bring the risk as low as is practical. Regards, Graham --
Re: [Vote] .htaccess logic abuse
On Sat, 2011-11-19 at 01:46 +0200, Graham Leggett wrote: On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote: After several prods, it seems the security@ and hackathon participants can't be drawn out of their shells on to dev@. So I'll simply call for a majority vote on the following statement... Resource abuse of an .htaccess config in the form of cpu/memory/ bandwidth; [X] Represents a security defect [ ] Is not a security defect The config is clearly demarcated into two types, a trusted config loaded at startup time rooted at /etc/httpd (or wherever), and a limited untrusted config placed into .htaccess files within the content and loaded at runtime. If we were to declare .htaccess as containing trusted content only, most of the point behind .htaccess is lost. The trusted admin simply needs to merge .htaccess into the main config, and he gains load-on-startup and copy-on-write, there is little point in one common administrator scattering their config in two separate places or mechanisms. The people given the power to change both .htaccess and content are typically customers of a hosting company, or employees at a corporate, and admins are generally not comfortable exposing themselves to avoidable risk from either group. That said, I do concede that these two groups are more trusted than the typical end user who might access a site, but I still believe we should fix .htaccess problems as reported where it is practical to do so to bring the risk as low as is practical. Agree completely with Graham signature.asc Description: This is a digitally signed message part
Re: [Vote] .htaccess logic abuse
On Friday 18 November 2011, William A. Rowe Jr. wrote: Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth; [ ] Represents a security defect [X] Is not a security defect This would obviously need to be clarified in the associated .htaccess documentation, be associated with an advisory and affect the conclusion of several recent defect reports, both embargoed and discussed plainly here on this list. We should not make any promises we won't be able to keep. There are countless ways to cause a DoS from .htaccess. The .htaccess mechanism has not been designed with resource limitation in mind. Changing that will be a lot of work and will likely break ABI/API, i.e. the fixes won't be backportable to stable releases. We should treat those issues as regular bugs and make DoS safe .htaccess a goal. But we should make it clear that this goal likely won't be reached in 2.4.x and earlier.
