On Fri, 2009-10-16 at 08:00 +1100, Bojan Smojver wrote:
> While playing with slowloris against prefork, I wrote the attached
> craziness.
Here is another take on the problem, call it "Craziness 2.0".
The idea here is that a busy server is highly unlikely to be stuck
reading using all its children
On Sunday 18 October 2009, Bojan Smojver wrote:
> The idea here is that a busy server is highly unlikely to be stuck
> reading using all its children over a maintenance interval (i.e. we
> expect at least one of those readers to turn into something else
> during the interval).
An attacker can eas
On Sun, 2009-10-18 at 10:37 +0200, Stefan Fritsch wrote:
> An attacker can easily circumvent this by opening one connection that
> slowly downloads a large file. Checking for a certain percentage of
> all children would be better.
Yeah, I was thinking of that too - just wanted to err on the side
On Sunday 18 October 2009, Bojan Smojver wrote:
> But the real deal is that there is a finite amount of resources we
> have (be that sockets, threads or processes) and we need to decide
> how we are willing to dole these out.
What about defining an API to determine if the server has resource
sh
On Sun, 2009-10-18 at 19:48 +1100, Bojan Smojver wrote:
> We can also create a checksum of pids/states and if this is the same
> second time around, pronounce it under attack
Like this.
--
Bojan
--- httpd-2.2.14-v/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14/
On Sun, 2009-10-18 at 21:56 +1100, Bojan Smojver wrote:
> Like this.
Ah, details, details...
--
Bojan
--- httpd-2.2.14-v/server/mpm/prefork/prefork.c 2009-02-01 07:54:55.0 +1100
+++ httpd-2.2.14/server/mpm/prefork/prefork.c 2009-10-18 23:42:13.831280800 +1100
@@ -48,6 +48,7 @@
#include
On Sun, 2009-10-18 at 23:46 +1100, Bojan Smojver wrote:
> +/* If after one maintenace interval we still see the same
> + * situation on the scoreboard, close 10% of client
> sockets.
The percentage picked out of thin air, of course.
--
Bojan
APIs were changed to avoid hard-wiring the MPM into the base server
compilation (replacing stuff like MPM_NAME, MPM_CHILD_PID(), mpm.h,
etc. with callable equivalents).
I didn't make these changes to these two MPMs previously because:
* OS/2 MPM was not in trunk at the time
* the NetWare maintaine
On Wed, May 27, 2009 at 7:13 PM, William A. Rowe, Jr.
wrote:
> Jeff Trawick wrote:
>> On Wed, May 27, 2009 at 4:26 PM, William A. Rowe, Jr.
>> mailto:wr...@rowe-clan.net>> wrote:
>>
>> and --enable-mods-shared=all still results in (unlinked) static
>> libevent.a, libworker.a objects, inste
On Fri, Oct 9, 2009 at 9:04 PM, William A. Rowe, Jr.
wrote:
> Rainer Jung wrote:
>> On 09.10.2009 20:55, Jeff Trawick wrote:
>>> Related to clarifying the executable part of the wrapper command-line
>>> (823657): Handling wrapper executables with embedded blanks,
>>> especially to confront the Fcg
Hi Jeff,
Jeff Trawick schrieb:
> I am happy to
>
> * start committing the necessary changes (unbuilt and untested)
> * provide some notes on what needs to be done
> * continue to ignore
>
> as desired by the maintainers. Just let me know ;)
please do! Although I have current trunk working, its s
On Thursday 15 October 2009, Dick Davies wrote:
> In any event, does it made sense to use something other than the
> inode as the key into the lockDB - the URI for example?
Is the performance improvement of inode keyed locking so large that it
is worth the hassle? If mod_dav_fs used filename keye
On 10/18/2009 09:35 PM, s...@apache.org wrote:
> Author: sf
> Date: Sun Oct 18 19:35:42 2009
> New Revision: 826506
>
> URL: http://svn.apache.org/viewvc?rev=826506&view=rev
> Log:
> htdigest: Fix possible overflow in command line processing. htdigest is not
> supposed to be suid save, therefore
On Sunday 18 October 2009, Ruediger Pluem wrote:
> Don't we still have an overflow? If argv[3] and argv[4] are of size
> MAX_STRING_LEN (which is sizeof(user) and sizeof(realm) we still
> have a
>
> sprintf(string, "%s:%s:%s", user, realm, pw);
>
> in line 147 with string, user, realm and pw al
Jeff Trawick wrote:
> APIs were changed to avoid hard-wiring the MPM into the base server
> compilation (replacing stuff like MPM_NAME, MPM_CHILD_PID(), mpm.h,
> etc. with callable equivalents).
>
> I didn't make these changes to these two MPMs previously because:
> * OS/2 MPM was not in trunk at t
On 10/18/2009 10:39 PM, s...@apache.org wrote:
> Author: sf
> Date: Sun Oct 18 20:39:05 2009
> New Revision: 826520
>
> URL: http://svn.apache.org/viewvc?rev=826520&view=rev
> Log:
> Fix some more overflows spotted by Ruediger Pluem
>
> Modified:
> httpd/httpd/trunk/support/htdigest.c
>
>
On Sun, 2009-10-18 at 21:56 +1100, Bojan Smojver wrote:
> Like this.
Here is a more aggressive variant, which disconnects all sockets in read
state and at least 10% of all sockets when we get in trouble. On my test
machine, it is quite effective against slowloris.
General idea is that:
- a prope
Hi,
Ruediger Pluem schrieb:
> Why do you think that line should be also 3 * MAX_STRING_LEN?
> I guess currently it can be MAX_STRING_LEN at max because of line
> 256:
>
> while (!(get_line(line,
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200107.mbox/%3csb52b03e@prv-mail20.provo.
On Sunday 18 October 2009, Guenter Knauf wrote:
> Hi,
>
> Ruediger Pluem schrieb:
> > Why do you think that line should be also 3 * MAX_STRING_LEN?
> > I guess currently it can be MAX_STRING_LEN at max because of line
> > 256:
> >
> > while (!(get_line(line,
> > http://mail-archives.apache.org
On Sunday 18 October 2009, Ruediger Pluem wrote:
> Why do you think that line should be also 3 * MAX_STRING_LEN?
> I guess currently it can be MAX_STRING_LEN at max because of line
> 256:
>
> while (!(get_line(line, MAX_STRING_LEN, f))) {
>
> But maybe this should be changed to
>
> while (!(
Hi,
Guenter Knauf schrieb:
> another problem I see here is that MAX_STRING_LEN = 8192 bytes, that
> means that already 6*8k are allocated from stack which is a problem at
> least on NetWare, as already discussed here back in 2001:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200107.mbox/%3c
Hi Stefan,
Stefan Fritsch schrieb:
> digest.c already has
>
> #define MAX_STRING_LEN 256
>
> No problem there.
ah, thanks for the pointer - I thought the setting was inherited from
the httpd.h define ...
Gün.
On Sunday 18 October 2009, Bojan Smojver wrote:
> - a properly configured server will not be maxing out
> - if maxing out does happen, scoreboard is bound to change within
> some time period (which we can pick), or we are seeing an attack
>
> With this approach (i.e. the scoreboard checksum), it
On Mon, 2009-10-19 at 00:00 +0200, Stefan Fritsch wrote:
> Randomly killing possibly legitimate connections is some kind of DoS,
> too.
For sure. Anything we do, including reducing connection timeout on a
heavily loaded server is DoS. We just pick the type of DoS we want,
instead of the one attac
On Mon, 2009-10-19 at 09:22 +1100, Bojan Smojver wrote:
> that SIGINT is a poke in the eye
Maybe we could use SIGURG here. After all we do have an urgent message
for the socket :-)
--
Bojan
On Mon, 2009-10-19 at 10:40 +1100, Bojan Smojver wrote:
> Maybe we could use SIGURG here. After all we do have an urgent message
> for the socket :-)
Hmm, it's a real bummer we don't have more user defined signals. We
could reach for RT stuff, but I'm not sure how portable that is.
Anyhow, here i
On Mon, 2009-10-19 at 12:27 +1100, Bojan Smojver wrote:
> +#ifndef NO_USE_SIGACTION
> +static void close_client_socket(int sig, siginfo_t *info, void
> *context)
> +#else
> +static void close_client_socket(int sig)
> +#endif
> +{
> +if (client_socket != -1) {
> +#ifndef NO_USE_SIGACTION
> +
27 matches
Mail list logo
