On Tuesday 13 March 2012, Patrick Matthäi wrote: > If the regular expression is wrong, okay, but what is about e.g. > the RedirectLimit? This also could cause server problems with > crafted configurations, but there is internal apache limit > available.
You mean LimitInternalRecursion? That is to protect from misconfigurations. In the same way, it would be nice to have a protection from runaway regexes. PCRE has a way to limit its recursion, but no one has changed apache to use that, yet. And it would be considerable work to do this change while avoiding unintended side effects. > In this case an shared hosting server (~ 300 customers) was > affected and crashed several times about months and we had to > introduce workarounds ("killer scripts") to prevent the server to > crash at all; debugging was quite hard aka impossible. > Here upstream should introduce something which prevents apache to > crash itself and the whole server. > > Since this is IMHO opinion a DoS - against the whole server, not > only the service, which requires "local user access" (customer > uploading his .htaccess) - it is security important, severity > important okay, but not wishlist.. > > Regarding the mail from apache-dev: > How is "resource abuse" defined? IMHO if the customer uploads a > htaccess and after that e.g the cpu load + response times are > higher, okay... pure configuration issue > But adding a few lines to crash the whole server? This is not a > resource abuse. There is no clear dividing line between the two. What is only a slightly increased memory usage on a big server with 16GB of RAM will cause Linux's OOM-killer to wreak havoc on a small virtual server with 128MB RAM. Apache does not try to adjust its resource usage to the size of the used server (again, a missing feature, not a security defect). This tuning is left to the administrator. You can prevent the whole server from being affected by setting suitable MaxClients and memory limits. You could also change oom_adj on the apache processes, to ensure that apache is killed and not other processes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org