Re: [Fwd: Apache httpd vulenrabilities]
On Jun 1, 2007, at 3:35 PM, Jim Jagielski wrote: FWIW, I've created a branch of the work in progress, so people can follow along and provide comments and patches :) http://svn.apache.org/repos/asf/httpd/httpd/branches/httpd-pid- table this is based off of trunk, so once we have this where we want it, we'll backport to 2.2 and 2.0
Re: [Fwd: Apache httpd vulenrabilities]
On Jun 1, 2007, at 2:13 PM, Jim Jagielski wrote: On Jun 1, 2007, at 11:39 AM, Jim Jagielski wrote: I will likely just commit the updated patch, and we can fine-tune via commits rather than having rounds of patches posted :) I just started on the trunk patches, not sure when they will be done... anyway, I was think that in addition to the checks, it would also be useful if, instead of just logging the issue, maybe the code should also set the pid to 0 and maybe a different status (maybe SERVER_UNKNOWN ?) Haven't thought this all the way through yet. As one would expect the 2.x patches are much larger, since things aren't as centralized... FWIW, I've created a branch of the work in progress, so people can follow along and provide comments and patches :) http://svn.apache.org/repos/asf/httpd/httpd/branches/httpd-pid- table
Re: [Fwd: Apache httpd vulenrabilities]
On Jun 1, 2007, at 11:39 AM, Jim Jagielski wrote: I will likely just commit the updated patch, and we can fine-tune via commits rather than having rounds of patches posted :) I just started on the trunk patches, not sure when they will be done... anyway, I was think that in addition to the checks, it would also be useful if, instead of just logging the issue, maybe the code should also set the pid to 0 and maybe a different status (maybe SERVER_UNKNOWN ?) Haven't thought this all the way through yet. As one would expect the 2.x patches are much larger, since things aren't as centralized...
Re: [Fwd: Apache httpd vulenrabilities]
On Jun 1, 2007, at 10:45 AM, Colm MacCarthaigh wrote: On Fri, Jun 01, 2007 at 10:50:09AM -0400, Jim Jagielski wrote: Should we get rid of it from the table here? Can we get away without removing stale pids in general? What if they are recycled by the OS for something else? No, that's a good point. We should likely remove the pid from our table once the child goes away. I think we need to do it with an actual table unset call too, not just set the entry to "0" or whatever, so that we don't exhaust our table. Yes, agreed. On that point, instead of initialising with ap_make_table(pglobal, 100) , it should probably use HARD_SERVER_LIMIT (if that's not in scope, it may even justify making it in scope) instead of 100 too, to avoid potential immediate exhaustion. Nice simple fix though, using a simple table seems like a way better approach than trying to replicate a paralell scoreboard. I will likely just commit the updated patch, and we can fine-tune via commits rather than having rounds of patches posted :)
Re: [Fwd: Apache httpd vulenrabilities]
On Fri, Jun 01, 2007 at 10:50:09AM -0400, Jim Jagielski wrote: > >Should we get rid of it from the table here? Can we get away without > >removing stale pids in general? What if they are recycled by the OS > >for something else? > > > > No, that's a good point. We should likely remove the > pid from our table once the child goes away. I think we need to do it with an actual table unset call too, not just set the entry to "0" or whatever, so that we don't exhaust our table. On that point, instead of initialising with ap_make_table(pglobal, 100) , it should probably use HARD_SERVER_LIMIT (if that's not in scope, it may even justify making it in scope) instead of 100 too, to avoid potential immediate exhaustion. Nice simple fix though, using a simple table seems like a way better approach than trying to replicate a paralell scoreboard. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Fwd: Apache httpd vulenrabilities]
On Jun 1, 2007, at 10:19 AM, Colm MacCarthaigh wrote:
On Fri, Jun 01, 2007 at 10:05:26AM -0400, Jim Jagielski wrote:
- if (ap_scoreboard_image->servers[n].status != SERVER_DEAD &&
- kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) {
- ap_update_child_status(n, SERVER_DEAD, NULL);
- /* just mark it as having a successful exit status */
- bzero((char *) status, sizeof(ap_wait_t));
- return(pid);
- }
+pid = ap_scoreboard_image->parent[n].pid;
+if (ap_scoreboard_image->servers[n].status != SERVER_DEAD) {
+if (in_pid_table(pid)) {
+if (kill(pid, 0) == -1) {
+ap_update_child_status(n, SERVER_DEAD, NULL);
+/* just mark it as having a successful exit
status */
+bzero((char *) status, sizeof(ap_wait_t));
+return(pid);
+}
Should we get rid of it from the table here? Can we get away without
removing stale pids in general? What if they are recycled by the OS
for something else?
No, that's a good point. We should likely remove the
pid from our table once the child goes away.
Re: [Fwd: Apache httpd vulenrabilities]
On Fri, Jun 01, 2007 at 10:05:26AM -0400, Jim Jagielski wrote:
> - if (ap_scoreboard_image->servers[n].status != SERVER_DEAD &&
> - kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) {
> - ap_update_child_status(n, SERVER_DEAD, NULL);
> - /* just mark it as having a successful exit status */
> - bzero((char *) status, sizeof(ap_wait_t));
> - return(pid);
> - }
> +pid = ap_scoreboard_image->parent[n].pid;
> +if (ap_scoreboard_image->servers[n].status != SERVER_DEAD) {
> +if (in_pid_table(pid)) {
> +if (kill(pid, 0) == -1) {
> +ap_update_child_status(n, SERVER_DEAD, NULL);
> +/* just mark it as having a successful exit
> status */
> +bzero((char *) status, sizeof(ap_wait_t));
> +return(pid);
> +}
Should we get rid of it from the table here? Can we get away without
removing stale pids in general? What if they are recycled by the OS
for something else?
--
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [Fwd: Apache httpd vulenrabilities]
For 1.3, I'm looking at something like this...
Similar approach for 2.x...
Comments and feedback appreciated before I work on
"porting" to the 2.x trees:
Index: main/http_main.c
===
--- main/http_main.c(revision 543486)
+++ main/http_main.c(working copy)
@@ -354,9 +354,17 @@
char tpf_mutex_key[TPF_MUTEX_KEY_SIZE];
#endif /* TPF */
+/*
+ * Shared memory scoreboard
+ */
scoreboard *ap_scoreboard_image = NULL;
/*
+ * Parent process local storage of child pids
+ */
+static table *pid_table;
+
+/*
* Pieces for managing the contents of the Server response header
* field.
*/
@@ -372,6 +380,26 @@
API_VAR_EXPORT int ap_change_shmem_uid = 0;
/*
+ * Check the pid table to see if the actual pid exists
+ */
+static int in_pid_table(int pid) {
+char apid[64];
+const char *spid;
+snprintf(apid, sizeof(apid), "%d", pid);
+spid = ap_table_get(pid_table, apid);
+if (spid && spid[0] == '1' && spid[1] == '\0')
+return 1;
+else
+return 0;
+}
+
+static void set_pid_table(int pid) {
+char apid[64];
+snprintf(apid, sizeof(apid), "%d", pid);
+ap_table_set(pid_table, apid, "1");
+}
+
+/*
* This routine is called when the pconf pool is vacuumed. It
resets the
* server version string to a known value and [re]enables
modifications
* (which are disabled by configuration completion).
@@ -2787,6 +2815,11 @@
if (pid == my_pid || pid == 0)
continue;
+if (!in_pid_table(pid)) {
+ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
server_conf,
+ "Bad pid (%d) in scoreboard slot %d",
pid, i);
+continue;
+}
waitret = waitpid(pid, &status, WNOHANG);
if (waitret == pid || waitret == -1) {
ap_scoreboard_image->parent[i].pid = 0;
@@ -2887,13 +2920,21 @@
for (n = 0; n < max_daemons_limit; ++n) {
ap_sync_scoreboard_image();
- if (ap_scoreboard_image->servers[n].status != SERVER_DEAD &&
- kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) {
- ap_update_child_status(n, SERVER_DEAD, NULL);
- /* just mark it as having a successful exit status */
- bzero((char *) status, sizeof(ap_wait_t));
- return(pid);
- }
+pid = ap_scoreboard_image->parent[n].pid;
+if (ap_scoreboard_image->servers[n].status != SERVER_DEAD) {
+if (in_pid_table(pid)) {
+if (kill(pid, 0) == -1) {
+ap_update_child_status(n, SERVER_DEAD, NULL);
+/* just mark it as having a successful exit
status */
+bzero((char *) status, sizeof(ap_wait_t));
+return(pid);
+}
+}
+else {
+ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
server_conf,
+"Bad pid (%d) in scoreboard slot %d",
pid, n);
+}
+}
}
return 0;
}
@@ -2916,15 +2957,21 @@
#define MAXWAITOBJ MAXIMUM_WAIT_OBJECTS
HANDLE h[MAXWAITOBJ];
int e[MAXWAITOBJ];
-int round, pi, hi, rv, err;
+int round, pi, hi, rv, err, pid;
for (round = 0; round <= (HARD_SERVER_LIMIT - 1) / MAXWAITOBJ +
1; round++) {
hi = 0;
for (pi = round * MAXWAITOBJ;
(pi < (round + 1) * MAXWAITOBJ) && (pi < HARD_SERVER_LIMIT);
pi++) {
if (ap_scoreboard_image->servers[pi].status != SERVER_DEAD) {
- e[hi] = pi;
- h[hi++] = (HANDLE) ap_scoreboard_image->parent[pi].pid;
+e[hi] = pi;
+pid = ap_scoreboard_image->parent[pi].pid;
+if (in_pid_table(pid))
+h[hi++] = (HANDLE) pid;
+else {
+ap_log_error(APLOG_MARK, APLOG_NOERRNO|
APLOG_ERR, server_conf,
+ "Bad pid (%d) in scoreboard slot %
d", pid, pi);
+}
}
}
@@ -4339,6 +4386,7 @@
ap_server_pre_read_config = ap_make_array(pcommands, 1, sizeof
(char *));
ap_server_post_read_config = ap_make_array(pcommands, 1, sizeof
(char *));
ap_server_config_defines = ap_make_array(pcommands, 1, sizeof
(char *));
+pid_table = ap_make_table(pglobal, 100);
}
#ifndef MULTITHREAD
@@ -4987,6 +5035,7 @@
ap_scoreboard_image->parent[slot].last_rtime = now;
#endif
ap_scoreboard_image->parent[slot].pid = pid;
+set_pid_table(pid);
#ifdef SCOREBOARD_FILE
lseek(scoreboard_fd, XtOffsetOf(scoreboard, parent[slot]), 0);
force_write(scoreboard_fd, &ap_scoreboard_image->parent[slot],
@@ -5049,6 +5098,7 @@
int i;
int to_kill;
int idle_count;
+int pid;
short_score *ss;
time_t now = time(NULL);
int free_length;
@@ -5113,8 +5163,15 @@
else if (ps->last_rtime + ss
Re: [Fwd: Apache httpd vulenrabilities]
On 5/30/07 6:09 PM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote: > "The only issue..." refers to the problems if we try to restructure > the scoreboard instead, which is good for 2.4/3.0 Scoreboard needs an overhaul anyway. So I wouldn't muck with it now. The local pid table sounds fine. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [Fwd: Apache httpd vulenrabilities]
On 05/31/2007 12:09 AM, Jim Jagielski wrote: > > "The only issue..." refers to the problems if we try to restructure > the scoreboard instead, which is good for 2.4/3.0 but not for 2.2, 2.0 > and 1.3... Any patches that tried to address the issue using that > method would be problematic. Hence my thoughts to just have local > storage for checking and keeping scoreboard as-is. Ahh. Got it. Completely agree. Thanks for the clarification. Regards Rüdiger
Re: [Fwd: Apache httpd vulenrabilities]
On May 30, 2007, at 3:09 PM, Jim Jagielski wrote: Hence my thoughts to just have local storage for checking and keeping scoreboard as-is. +1 on this approach. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [Fwd: Apache httpd vulenrabilities]
Ruediger Pluem wrote: > > > > On 05/30/2007 09:45 PM, Jim Jagielski wrote: > > > > On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: > > > >> > >> > >> On 05/30/2007 08:10 PM, Jim Jagielski wrote: > >> > >>> > >>> On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: > >>> > > 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. > > >>> > >>> Yes... Of course, it doesn't even need to be that extensive. > >>> If the parent process simply keeps in local storage a > >>> list of PIDs and before it does anything to the child > >>> process (send signal), it checks that the PID in the > >>> scoreboard is also in its own list, and only > >>> continues if it is This means that the scoreboard > >>> stays as is and the parent process just needs a > >>> small list of pid's added to it, plus some minor > >>> logic. > >> > >> > >> This is also my thought on this. Maybe the logic could be extended > >> somewhat so that the parent cross checks / sanity checks the number of > >> pids in its local storage and the number of active pids (a.k.a "non > >> empty" > >> slots) in whatever state they are every time it decides that it needs > >> to start additional childs / kill childs. This should avoid / reduce > >> issues #1 / #4. > >> > > > > :) My thoughts exactly... > > > > The only issue with pulling parent out of scoreboard is, > > of course, the backwards compatibility with modules that > > may be interested in it... > > Sorry for being confused now. I thought the idea was to have an additional > local pid list in the parent for cross / sanity checking. The scoreboard > remains as it is (including the pids). So what could modules possible miss > after the patch? > Not sure where the confusion is... the idea is to keep the scoreboard exactly as-is (as noted above, pulling out the parent parts (pid), would be a major issue for backwards compatibility), and just add pid-checking logic (and a local store of pids) in the parent process. Thus, it's completely transparent and no changes to the scoreboard or any entities that use it (except for the mentioned parent-side checking, 'natch) :) "The only issue..." refers to the problems if we try to restructure the scoreboard instead, which is good for 2.4/3.0 but not for 2.2, 2.0 and 1.3... Any patches that tried to address the issue using that method would be problematic. Hence my thoughts to just have local storage for checking and keeping scoreboard as-is. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: [Fwd: Apache httpd vulenrabilities]
On 05/30/2007 09:45 PM, Jim Jagielski wrote: > > On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: > >> >> >> On 05/30/2007 08:10 PM, Jim Jagielski wrote: >> >>> >>> On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: >>> 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. >>> >>> Yes... Of course, it doesn't even need to be that extensive. >>> If the parent process simply keeps in local storage a >>> list of PIDs and before it does anything to the child >>> process (send signal), it checks that the PID in the >>> scoreboard is also in its own list, and only >>> continues if it is This means that the scoreboard >>> stays as is and the parent process just needs a >>> small list of pid's added to it, plus some minor >>> logic. >> >> >> This is also my thought on this. Maybe the logic could be extended >> somewhat so that the parent cross checks / sanity checks the number of >> pids in its local storage and the number of active pids (a.k.a "non >> empty" >> slots) in whatever state they are every time it decides that it needs >> to start additional childs / kill childs. This should avoid / reduce >> issues #1 / #4. >> > > :) My thoughts exactly... > > The only issue with pulling parent out of scoreboard is, > of course, the backwards compatibility with modules that > may be interested in it... Sorry for being confused now. I thought the idea was to have an additional local pid list in the parent for cross / sanity checking. The scoreboard remains as it is (including the pids). So what could modules possible miss after the patch? Regards Rüdiger
Re: [Fwd: Apache httpd vulenrabilities]
On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote: On 05/30/2007 08:10 PM, Jim Jagielski wrote: On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: 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. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. This is also my thought on this. Maybe the logic could be extended somewhat so that the parent cross checks / sanity checks the number of pids in its local storage and the number of active pids (a.k.a "non empty" slots) in whatever state they are every time it decides that it needs to start additional childs / kill childs. This should avoid / reduce issues #1 / #4. :) My thoughts exactly... The only issue with pulling parent out of scoreboard is, of course, the backwards compatibility with modules that may be interested in it...
Re: [Fwd: Apache httpd vulenrabilities]
On 05/30/2007 08:10 PM, Jim Jagielski wrote: > > On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: > >> >> 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. >> > > Yes... Of course, it doesn't even need to be that extensive. > If the parent process simply keeps in local storage a > list of PIDs and before it does anything to the child > process (send signal), it checks that the PID in the > scoreboard is also in its own list, and only > continues if it is This means that the scoreboard > stays as is and the parent process just needs a > small list of pid's added to it, plus some minor > logic. This is also my thought on this. Maybe the logic could be extended somewhat so that the parent cross checks / sanity checks the number of pids in its local storage and the number of active pids (a.k.a "non empty" slots) in whatever state they are every time it decides that it needs to start additional childs / kill childs. This should avoid / reduce issues #1 / #4. > > The next coupla days I'll be mostly offline since my oldest > son Jon is graduating and so there's the graduation, and > planning, and party, etc... All the best to Jon. Regards Rüdiger
Re: [Fwd: Apache httpd vulenrabilities]
On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote: 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. Yes... Of course, it doesn't even need to be that extensive. If the parent process simply keeps in local storage a list of PIDs and before it does anything to the child process (send signal), it checks that the PID in the scoreboard is also in its own list, and only continues if it is This means that the scoreboard stays as is and the parent process just needs a small list of pid's added to it, plus some minor logic. The next coupla days I'll be mostly offline since my oldest son Jon is graduating and so there's the graduation, and planning, and party, etc...
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: [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]
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]
* 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]
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
