client timeout behavior.
We noticed that with mod_proxy_ajp, it's not possible to set an indefinite timeout like was possible with mod_jk. So a long running JSP page, for example: % Thread.sleep(96); % With mod_proxy_ajp timeout set to 300 will cause a 503 to be thrown back to the client since mod_proxy_ajp's timeout gets triggered. Two questions 1) Is there a way to force an indefinite timeout for mod_proxy_ajp like mod_jk has? With mod_jk, if the worker's timeout was set to 0 it will wait indefinitely 2) how is it that the client doesn't time out? My firefox client has network.http.keep-alive.timeout set to 300. Wireshark doesn't show any keepalive traffic sent back and forth between apache and the client in between the request and the 503 response. I'm probably reading this wrong, but according to the KeepAliveTimeout documentation: The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the |Timeout http://httpd.apache.org/docs/2.2/mod/core.html#timeout| directive applies. In my request to the Thread.sleep JSP page, the request was already made. Shouldn't the standard Timeout (300s in my case) apply and disconnect the client? Thanks, Andy
[Fwd: Apache httpd vulenrabilities]
Published - ergo moving discussion from security@ to [EMAIL PROTECTED] Of course if in the course of this discussion, you uncover a new edge case, feel free to move that thread back to [EMAIL PROTECTED] to discuss your new discovery. ---BeginMessage--- PSNC Security Team has got the pleasure to announce that, as a result of Apache httpd server (ver. 1.3.x, 2.0.x and 2.2.x) source code analysis, several vulnerabilities have been found that make it possible to perfom a DoS attack against the services and the system that the application is running on. Below the basic information on found vulnerabilities may be found: Vuln#1 Httpd Server DoS Test environment: ver. 2.0.59, 2.2.4, prefork mpm module An appropriate code run in the worker process context makes it possible to kill all worker processes with simultaneous blocking of creating new worker processes by the master process. As a result, the server stops to accept and handle new connections. Vuln #2 SIGUSR1 killer Test environment: ver. 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #3 SIGUSR1 killer Test environment: ver 1.3.37 An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #4 System DoS Test environment: ver 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to force the master process to create an unlimited amount of new worker processes. As a result, the activity of the whole system may be blocked. Countermeasures: Disabling the possibility of running the user.s code in the worker process context. An especial emphasis should be put on programming languages that may be configures as an Apache module (like mod_php, mod_perl etc.) in order to block dangerous functions, e.g. dl(), dlopen(). The information on the vulnerabilities above was sent to Apache Software Foundation on 16 May, 2006. For over 1 year no official patch has been issued. PSNC Security Team is currently working on its own, unofficial patches. Our patches will be published on 18 June, 2007 on the team webpage (http://security.psnc.pl). On 20 June, 2007 the detailed information on the found vulnerabilities will be issued. PSNC Security Team ---End Message---
Re: [Fwd: Apache httpd vulenrabilities]
Hey Bill just to clarify these are LOCAL DoS attacks? ie you need access to the machine (or the ability to execute php) in order for this to be an issue? William A. Rowe, Jr. wrote: Published - ergo moving discussion from security@ to [EMAIL PROTECTED] Of course if in the course of this discussion, you uncover a new edge case, feel free to move that thread back to [EMAIL PROTECTED] to discuss your new discovery. Subject: Apache httpd vulenrabilities From: Blazej Miga [EMAIL PROTECTED] Date: Tue, 29 May 2007 20:00:42 +0200 (CEST) To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] PSNC Security Team has got the pleasure to announce that, as a result of Apache httpd server (ver. 1.3.x, 2.0.x and 2.2.x) source code analysis, several vulnerabilities have been found that make it possible to perfom a DoS attack against the services and the system that the application is running on. Below the basic information on found vulnerabilities may be found: Vuln#1 Httpd Server DoS Test environment: ver. 2.0.59, 2.2.4, prefork mpm module An appropriate code run in the worker process context makes it possible to kill all worker processes with simultaneous blocking of creating new worker processes by the master process. As a result, the server stops to accept and handle new connections. Vuln #2 SIGUSR1 killer Test environment: ver. 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #3 SIGUSR1 killer Test environment: ver 1.3.37 An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #4 System DoS Test environment: ver 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to force the master process to create an unlimited amount of new worker processes. As a result, the activity of the whole system may be blocked. Countermeasures: Disabling the possibility of running the user.s code in the worker process context. An especial emphasis should be put on programming languages that may be configures as an Apache module (like mod_php, mod_perl etc.) in order to block dangerous functions, e.g. dl(), dlopen(). The information on the vulnerabilities above was sent to Apache Software Foundation on 16 May, 2006. For over 1 year no official patch has been issued. PSNC Security Team is currently working on its own, unofficial patches. Our patches will be published on 18 June, 2007 on the team webpage (http://security.psnc.pl). On 20 June, 2007 the detailed information on the found vulnerabilities will be issued. PSNC Security Team
Re: [Fwd: Apache httpd vulenrabilities]
* Ian Holsman wrote:
Hey Bill
just to clarify these are LOCAL DoS attacks? ie you need access to the
machine (or the ability to execute php) in order for this to be an issue?
Well, if your PHP script (running on mod_php) allows code injection, it's
also remotely exploitable. Untrusted code should not be run with mod_php,
though.
nd
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://pub.perlig.de/ #
Re: [Fwd: Apache httpd vulenrabilities]
Ian Holsman wrote: Hey Bill just to clarify these are LOCAL DoS attacks? ie you need access to the machine (or the ability to execute php) in order for this to be an issue? AIUI all of these are loading modules of untrusted code (or a scripting language which gives you the same effect.) Now mod_perl has minimal presumption that it can be used to run untrusted code, while the PHP community anticipates running untrusted code. The httpd community is (mostly) suspect on invoking untrusted code in-process. That said, #2/3 looks like the only significant issue IMHO. That the parent could be cooerced to do something 'as root' is badness, and we can agree with the reporter on that. As the reporter apparently believes 2 weeks is enough to solve any security issue, these are now public. #1 and #4 are minor, IMHO, as resource consumption is pretty trivial if you are running anyone's code on your machine, through the facilities of serving httpd or giving them a local user account. I'd classify #1 as a bug, and #4 as silly but possibly worth patching. Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. William A. Rowe, Jr. wrote: Published - ergo moving discussion from security@ to [EMAIL PROTECTED] Of course if in the course of this discussion, you uncover a new edge case, feel free to move that thread back to [EMAIL PROTECTED] to discuss your new discovery. Subject: Apache httpd vulenrabilities From: Blazej Miga [EMAIL PROTECTED] Date: Tue, 29 May 2007 20:00:42 +0200 (CEST) To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] PSNC Security Team has got the pleasure to announce that, as a result of Apache httpd server (ver. 1.3.x, 2.0.x and 2.2.x) source code analysis, several vulnerabilities have been found that make it possible to perfom a DoS attack against the services and the system that the application is running on. Below the basic information on found vulnerabilities may be found: Vuln#1 Httpd Server DoS Test environment: ver. 2.0.59, 2.2.4, prefork mpm module An appropriate code run in the worker process context makes it possible to kill all worker processes with simultaneous blocking of creating new worker processes by the master process. As a result, the server stops to accept and handle new connections. Vuln #2 SIGUSR1 killer Test environment: ver. 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #3 SIGUSR1 killer Test environment: ver 1.3.37 An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #4 System DoS Test environment: ver 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to force the master process to create an unlimited amount of new worker processes. As a result, the activity of the whole system may be blocked. Countermeasures: Disabling the possibility of running the user.s code in the worker process context. An especial emphasis should be put on programming languages that may be configures as an Apache module (like mod_php, mod_perl etc.) in order to block dangerous functions, e.g. dl(), dlopen(). The information on the vulnerabilities above was sent to Apache Software Foundation on 16 May, 2006. For over 1 year no official patch has been issued. PSNC Security Team is currently working on its own, unofficial patches. Our patches will be published on 18 June, 2007 on the team webpage (http://security.psnc.pl). On 20 June, 2007 the detailed information on the found vulnerabilities will be issued. PSNC Security Team
Re: [Fwd: Apache httpd vulenrabilities]
On 05/29/2007 11:28 PM, William A. Rowe, Jr. wrote: Ian Holsman wrote: Hey Bill just to clarify these are LOCAL DoS attacks? ie you need access to the machine (or the ability to execute php) in order for this to be an issue? AIUI all of these are loading modules of untrusted code (or a scripting language which gives you the same effect.) Now mod_perl has minimal presumption that it can be used to run untrusted code, while the PHP community anticipates running untrusted code. The httpd community is (mostly) suspect on invoking untrusted code in-process. That said, #2/3 looks like the only significant issue IMHO. That the parent could be cooerced to do something 'as root' is badness, and we can agree with the reporter on that. As the reporter apparently believes 2 weeks is enough to solve any security issue, these are now public. 2 weeks? The text in the reporters mail (see end of mail) speaks about May 16th, 2006. This would be about a year (and this is mentioned as reason for publishing) When did they actually send this to security@ and to which ([EMAIL PROTECTED], [EMAIL PROTECTED])? #1 and #4 are minor, IMHO, as resource consumption is pretty trivial if you are running anyone's code on your machine, through the facilities of serving httpd or giving them a local user account. I'd classify #1 as a bug, and #4 as silly but possibly worth patching. Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. So, I guess #2/#3 happens due to a manipulation of the pids in the scoreboard which tricks the parent process in sending the signals to the wrong pids (once it has a need to do so to its children). Any more details about #1/#4? Regards Rüdiger The information on the vulnerabilities above was sent to Apache Software Foundation on 16 May, 2006. For over 1 year no official patch has been issued. PSNC Security Team is currently working on its own, unofficial patches. Our patches will be published on 18 June, 2007 on the team webpage (http://security.psnc.pl). On 20 June, 2007 the detailed information on the found vulnerabilities will be issued. PSNC Security Team
Re: [Fwd: Apache httpd vulenrabilities]
Ruediger Pluem wrote: 2 weeks? The text in the reporters mail (see end of mail) speaks about May 16th, 2006. This would be about a year (and this is mentioned as reason for publishing) When did they actually send this to security@ and to which ([EMAIL PROTECTED], [EMAIL PROTECTED])? My bad, and apologies. We are actually looking at resolving this issue permanently. Essentially, PID tables need to move from the score to a local process list only in the parent, and unshared. That would solve the 80/20 of this entire class of issues. So, I guess #2/#3 happens due to a manipulation of the pids in the scoreboard which tricks the parent process in sending the signals to the wrong pids (once it has a need to do so to its children). Any more details about #1/#4? Yes, please refer to [EMAIL PROTECTED] archives, as exploit code is not published. But I have no issue at this point if we start discussing #1/#4 as bugs, here on [EMAIL PROTECTED] Informational pids aught to stay in the scoreboard. Let's face it, NOTHING stops a process from trying to sigkill each process ID from 0 to 65535, except for the language itself. If a scripting language allows you to send arbitrary signals to arbitrary processes, it's your own stupidity for letting untrusted code run on your box. SO, the parent running as root shouldn't be trusting the score for anything such as the pids it is killing, etc. But the fact is 'nobody' can kill the processes running as 'nobody', and nothing will ever change that. Bill
Re: [vote] Piped loggers and APR_SHELLCMD_ENV
I'm retracting my two proposed choices and going with Option #3 :) Does anyone object to Jeff's weird proposal below? I think it's the best of both worlds. Speak up before I hack this in. Bill William A. Rowe, Jr. wrote: Jeff Trawick wrote: On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: While I'm working on a solution to permit cmd.exe to be launched from a service process within Win32, I'm still struck by the inefficiency here and feel we need to resolve the core issue. Apparently it is a good APR testcase as well ;) :) No argument - I don't want to lose the 'feature', simply offer both behaviors... [ ] Revert to |foo to invoke foo, and add |$foo syntax to launch foo via sh [ ] Retain |foo to invoke foo through sh, and add ||foo syntax to directly launch foo Just to be weird: |$foo syntax launches foo via sh ||foo syntax launches foo directly |foo tries to make the right decision: ++1 - I prefer your idea, if everyone else can buy into it! Windows: APR is busted, so launch foo directly or rather, once cmd.exe behaves in the service process, we can fall over to the unix rules... Other platforms: starts with slash and contains no redirection? launches foo directly else launches foo via sh This is expected to do the right thing for just about everybody -- almost no regression, with neatness improvement (Unix users not needing to see the extra /bin/sh hanging around) or functional improvement (Windows users avoiding APR problem) for most folks. Nice Drawback: Some people may not be ready to understand the resulting doc. True - but with your solution, for the most part, folks won't need to. The ones who actually want to have the fine control will take the time to read it three times and figure it out.
httpd 1.3 / 2.0 / 2.2 tags this weekend?
I'd like to see new tarballs rolled soonish, given the single significant bug that was disclosed earlier today. Obviously most mass-vhosters are capable of compiling their own binary, so providing the seperate-pid-table patch (whoever gets around to writing one) resolves any immediate urgency. But people get skittish when they see httpd anywhere near vulnerability, so I'll roll apr 0.9/1.2 in 36 hours which means midday Sunday it's likely to be released and ready to drop into 2.0 / 2.2. 1.3 could be rolled/released whenever it's been patched, but I'd personally rather see *one* announcement, again, like we did about a year back, so we don't have silly people scrambling to install 1.3 in place of 2.2 :) I volunteer to roll 1.3 when it's ready, since Sander offered to roll 2.2 (and perhaps 2.0?) Bill
