You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/05/29 21:36:33 UTC
[Fwd: Apache httpd vulenrabilities]
Published - ergo moving discussion from security@ to dev@.
Of course if in the course of this discussion, you uncover a new
edge case, feel free to move that thread back to security@httpd
to discuss your new discovery.
Re: [Fwd: Apache httpd vulenrabilities]
Posted by André Malo <nd...@perlig.de>.
* 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]
Posted by Ruediger Pluem <rp...@apache.org>.
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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by Colm MacCarthaigh <co...@stdlib.net>.
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árthaigh Public Key: colm+pgp@stdlib.net
Re: [Fwd: Apache httpd vulenrabilities]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by Colm MacCarthaigh <co...@stdlib.net>.
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árthaigh Public Key: colm+pgp@stdlib.net
Re: [Fwd: Apache httpd vulenrabilities]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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->timeout_len < now) {
/* no progress, and the timeout length has been exceeded */
ss->timeout_len = 0;
- kill(ps->pid, SIG_TIMEOUT_KILL);
- }
+ pid = ps->pid;
+ if (in_pid_table(pid)) {
+ kill(pid, SIG_TIMEOUT_KILL);
+ }
+ else {
+ ap_log_error(APLOG_MARK, APLOG_NOERRNO|
APLOG_ERR, server_conf,
+ "Bad pid (%d) in scoreboard slot %d",
pid, i);
+ }
+ }
}
#endif
}
@@ -5126,11 +5183,18 @@
* while we were counting. Use the define SIG_IDLE_KILL to reflect
* which signal should be used on the specific OS.
*/
- kill(ap_scoreboard_image->parent[to_kill].pid, SIG_IDLE_KILL);
- idle_spawn_rate = 1;
+ pid = ap_scoreboard_image->parent[to_kill].pid;
+ if (in_pid_table(pid)) {
+ kill(pid, SIG_IDLE_KILL);
+ idle_spawn_rate = 1;
#ifdef TPF
- ap_update_child_status(to_kill, SERVER_DEAD, (request_rec *)
NULL);
+ ap_update_child_status(to_kill, SERVER_DEAD,
(request_rec *)NULL);
#endif
+ }
+ else {
+ ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
server_conf,
+ "Bad pid (%d) in scoreboard slot %d", pid,
to_kill);
+ }
}
else if (idle_count < ap_daemons_min_free) {
/* terminate the free list */
Re: [Fwd: Apache httpd vulenrabilities]
Posted by Sander Temme <sc...@apache.org>.
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
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [Fwd: Apache httpd vulenrabilities]
Posted by "Akins, Brian" <Br...@turner.com>.
On 5/30/07 6:09 PM, "Jim Jagielski" <ji...@jaguNET.com> 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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: [Fwd: Apache httpd vulenrabilities]
Posted by Ruediger Pluem <rp...@apache.org>.
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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by Ruediger Pluem <rp...@apache.org>.
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]
Posted by Jim Jagielski <ji...@jaguNET.com>.
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]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 (security@apache.org, security@httpd.apache.org)?
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 security@httpd.a.o 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 dev@.
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]
Posted by Ruediger Pluem <rp...@apache.org>.
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 (security@apache.org, security@httpd.apache.org)?
>
> #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]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 dev@.
>>
>> Of course if in the course of this discussion, you uncover a new
>> edge case, feel free to move that thread back to security@httpd
>> to discuss your new discovery.
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Apache httpd vulenrabilities
>> From:
>> Blazej Miga <bl...@man.poznan.pl>
>> Date:
>> Tue, 29 May 2007 20:00:42 +0200 (CEST)
>> To:
>> bugtraq@securityfocus.com
>>
>> To:
>> bugtraq@securityfocus.com
>>
>>
>> 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]
Posted by Ian Holsman <li...@holsman.net>.
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 dev@.
>
> Of course if in the course of this discussion, you uncover a new
> edge case, feel free to move that thread back to security@httpd
> to discuss your new discovery.
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Apache httpd vulenrabilities
> From:
> Blazej Miga <bl...@man.poznan.pl>
> Date:
> Tue, 29 May 2007 20:00:42 +0200 (CEST)
> To:
> bugtraq@securityfocus.com
>
> To:
> bugtraq@securityfocus.com
>
>
> 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
>
>
>