Re: protocol for reporting bug that 'may' be considered exploit
Thank you! Will file one shortly. On Mon, Jun 29, 2009 at 9:24 PM, Eric Covener wrote: > On Tue, Jun 30, 2009 at 12:10 AM, Toadie wrote: >> Hello, >> >> I think we may have discovered an issue with mod_proxy that 'could' be >> used as an exploit to render an Apache server useless. > > report via email to secur...@apache.org ( more detail at > http://www.apache.org/security/ ) > > > -- > Eric Covener > cove...@gmail.com >
Re: Creating a new thread inside a module
William A. Rowe, Jr. wrote: However it requires to be statically compiled so it can survive the child death. *That's* the reason for static?!? See mod_aspdotnet and several others for how to pin a particular .so module for the lifetime of the process, instead of per-restart. Why can't we make some simpler API for such modules instead hacking the current one when it is obvious that there are modules that cannot survive the graceful restart? No modules in trunk should require static compilation, period. There is a difference between should and must, but seems to me there's no decent API for that. Regards -- ^(TM)
Re: protocol for reporting bug that 'may' be considered exploit
On Tue, Jun 30, 2009 at 12:10 AM, Toadie wrote: > Hello, > > I think we may have discovered an issue with mod_proxy that 'could' be > used as an exploit to render an Apache server useless. report via email to secur...@apache.org ( more detail at http://www.apache.org/security/ ) -- Eric Covener cove...@gmail.com
protocol for reporting bug that 'may' be considered exploit
Hello, I think we may have discovered an issue with mod_proxy that 'could' be used as an exploit to render an Apache server useless. I normally report more benign bugs via the normal bug reporting interface. However, this one bug is quite easy to create an exploit for so I am looking for guidance on how to report this issue. Should I report this on the apache bug tool (which will make this info publicly available) ? What I have so far 1. a confirmed repro of the bug 2. a general area where we think the offending line in the code is causing the problem 3. attempted to fix the bug and created a patch but to no avail (we aren't familiar with the apr* modules and various ap* functions.) In addition I have scanned through the bug DB and found several instances of similar symptoms that we have observed around issues with mod_proxy. None of the bug a repro. I believe we could have found a repro case that consistently causes a lockup in Apache. Because of the sensitivity of this bug and its relative ease to craft an exploit, let me know how to proceed. We are willing to work with one or more individuals on the apache team who are familiar with the code to repro and test one or more patches. If the normal procedure is to report the bug via the Apache bug db, please let me know. Thanks in advance. PS: During our discovery, we also found another bug but it's more benign and I will file it as a separate bug
Re: Creating a new thread inside a module
Hi Mladen Turk, Thank you very much. I roughly gone throug the mod_watchdog. I create my background thread inside the balancer_init method at mod_proxy_balancer module. But after finished the execution of balancer_init method my thread also terminate automatically. Do you or any body have idea to avoid this. I need to run my background thread until the server stop by user. Best Regards, Iroshan.
Re: Creating a new thread inside a module
Mladen Turk wrote: > > Take a look at trunk's mod_watchdog. > It should compile with 2.2 without a problem. > However it requires to be statically compiled so it > can survive the child death. *That's* the reason for static?!? See mod_aspdotnet and several others for how to pin a particular .so module for the lifetime of the process, instead of per-restart. No modules in trunk should require static compilation, period.
Re: Creating a new thread inside a module
h iroshan wrote: Hi All Actually I need *to* modify *Apache* and *run* one custom background *thread*. In addition, my custom modules have *to* be able *to* access the shared memory and it should be done through the background *thread*. Did anybody do this before? Is *there* an example I can use as a starting point? please help me. I already told you to look at the trunk (mod_watchdog) http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/core/ It is used to manage the hartbeat module at regular intervals (you might look at this as well) and it listens and send data via socket using shared memory extensively and can manage mod_proxy (well should ;) Regards -- ^(TM)
Re: Creating a new thread inside a module
Hi All Actually I need *to* modify *Apache* and *run* one custom background *thread *. In addition, my custom modules have *to* be able *to* access the shared memory and it should be done through the background *thread*. Did anybody do this before? Is *there* an example I can use as a starting point? please help me. Best Regards, Iroshan Under graduate UCSC Sri Lanka.
Re: Creating a new thread inside a module
Hi Mladen Turk, Thank you .In Apache 2.2.x trunk there is no such a module mod_watchdog. Is this is from later version?. Can I compile this in DSO mode with mod_proxy_balancer.? Help me Iroshan. > Take a look at trunk's mod_watchdog. > It should compile with 2.2 without a problem. > However it requires to be statically compiled so it > can survive the child death. > > If that's not feasible, hack it ;) > > > Regards > -- > ^(TM) >
Re: A modest proposal, was Re: Mitigating the Slowloris DoS attack
On Jun 23, 2009, at 8:39 PM, Akins, Brian wrote: On 6/23/09 12:48 AM, "Paul Querna" wrote: Mitagation is the wrong approach. We all know our architecture is wrong. Another heretical suggestion: Lighttpd and nginx are both release under BSD-like licenses. Hear me out. I've actually been thinking "how possible would it be to transform one of them into httpd 3.0?" Most prob not that hard since Lighttpd is a fork of Apache 1.3.
Re: Mitigating the Slowloris DoS attack
On Jun 24, 2009, at 5:18 AM, Joe Orton wrote: Regardless, the only thing I've ever wanted to see changed in the server which would somewhat mitigate this type of attack is to have coarser granularity on timeouts, e.g. per-request-read, rather than simply per-IO-operation. ++1. Timeout would set universal defaults and we could then have something like Timeout ReqRead 2 to provide further refinement.
Re: mod_noloris: mitigating against slowloris-style attack
On Jun 25, 2009, at 11:12 AM, William A. Rowe, Jr. wrote: Nick Kew wrote: Is this worth hacking up, or more trouble than it saves? It already lives in /repos/asf/httpd/mod_ftp/trunk/modules/ftp/ ... see the http://httpd.apache.org/mod_ftp/mod/mod_ftp.html#ftplimitloginip docs. It would be reasonably simple to rip this out and use a single shared implementation for both protocols. An extended scoreboard based solution would be much more efficient, I suspect. Actually, I have a hacked version that uses mod_slotmem :)
Re: Using slotmem in /mod_lbmethod_heartbeat/mod_heartmonitor
On Jun 24, 2009, at 8:54 AM, jean-frederic clere wrote: Paul Querna wrote: On Tue, Jun 23, 2009 at 5:35 AM, jean-frederic clere> wrote: Hi, I plan to use slotmem (additionally to the actual file based logic) in the heartbeat logic. HeartbeatStorage mem:logs/hb.dat (slotmem and key/save uses logs/ hb.dat). HeartbeatStorage logs/hb.dat (existing logic). Of course the hearthbeat handler will use slotmem and issue en error at the start if that is not the storage configured. (actualy the the hearthbeat handler doesn't work). The slotmem element will use the proxy_worker_stat and heartbeat actual format...(Well a string big enough). Comments? why do we need to store the same information twice? Not twice, I will just keep the old file logic and add a new one, the proxy_worker_stat would come from the slotmem not from the scoreboard. +1
Re: Creating a new thread inside a module
h iroshan wrote: Hi All, I want to open a port to communicate my Apache hhtpd (2.2) with small software run on a separate machine .Without affecting the httpd how can i create a new thread to listen to that software. Also I want to start this thread when the mod_proxy_balancer is initialize its balancer members(balancer_init). Take a look at trunk's mod_watchdog. It should compile with 2.2 without a problem. However it requires to be statically compiled so it can survive the child death. If that's not feasible, hack it ;) Regards -- ^(TM)
Creating a new thread inside a module
Hi All, I want to open a port to communicate my Apache hhtpd (2.2) with small software run on a separate machine .Without affecting the httpd how can i create a new thread to listen to that software. Also I want to start this thread when the mod_proxy_balancer is initialize its balancer members(balancer_init). please helpp me, thank you, Iroshan Under graduate-UCSC Ari Lanka
Re: httpd initd daemon
many thanks it is working. Graham Dumpleton-2 wrote: > > 2009/6/29 Yahav : >> >> i would like to set the httpd instance to run as standard linux daemon. >> the >> daemon should be controlled by the init daemon. the problem is that the >> apachectl that runs the httpd is starting the main server process then >> forking N StarServers and return 0 or something else. I would like it to >> be >> hang while it run i.e. right before exiting addin select command that >> will >> listen on some signal, like SIGTERM. >> is there any way to add it? if so can somebody recomands what is the best >> place to make the change? is there allready such feature? > > Have you tried: > > httpd -DFOREGROUND > > instead of apachectl. > > Read the httpd manual page and Google search on that for more information. > > Graham > > -- View this message in context: http://www.nabble.com/httpd-initd-daemon-tp24251132p24253136.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: httpd initd daemon
many thanks Graham Dumpleton-2 wrote: > > 2009/6/29 Yahav : >> >> i would like to set the httpd instance to run as standard linux daemon. >> the >> daemon should be controlled by the init daemon. the problem is that the >> apachectl that runs the httpd is starting the main server process then >> forking N StarServers and return 0 or something else. I would like it to >> be >> hang while it run i.e. right before exiting addin select command that >> will >> listen on some signal, like SIGTERM. >> is there any way to add it? if so can somebody recomands what is the best >> place to make the change? is there allready such feature? > > Have you tried: > > httpd -DFOREGROUND > > instead of apachectl. > > Read the httpd manual page and Google search on that for more information. > > Graham > > -- View this message in context: http://www.nabble.com/httpd-initd-daemon-tp24251132p24253128.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: httpd initd daemon
2009/6/29 Yahav : > > i would like to set the httpd instance to run as standard linux daemon. the > daemon should be controlled by the init daemon. the problem is that the > apachectl that runs the httpd is starting the main server process then > forking N StarServers and return 0 or something else. I would like it to be > hang while it run i.e. right before exiting addin select command that will > listen on some signal, like SIGTERM. > is there any way to add it? if so can somebody recomands what is the best > place to make the change? is there allready such feature? Have you tried: httpd -DFOREGROUND instead of apachectl. Read the httpd manual page and Google search on that for more information. Graham
httpd initd daemon
i would like to set the httpd instance to run as standard linux daemon. the daemon should be controlled by the init daemon. the problem is that the apachectl that runs the httpd is starting the main server process then forking N StarServers and return 0 or something else. I would like it to be hang while it run i.e. right before exiting addin select command that will listen on some signal, like SIGTERM. is there any way to add it? if so can somebody recomands what is the best place to make the change? is there allready such feature? -- View this message in context: http://www.nabble.com/httpd-initd-daemon-tp24251132p24251132.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
