On Tue, Jun 26, 2007 at 11:03:41PM +0200, Ruediger Pluem wrote: > On 06/26/2007 08:37 PM, Joe Orton wrote: > > My summary: I've still not seen any argument why it presents a security > > risk for a "malicious child" to be able to kill a piped logger or other > > non-MPM-spawned process, so: > > What about signals other than SIGKILL and SIGTERM? > > We also send SIGUSR1 in some cases.
This will either terminate the process (the default disposition) or not. I don't think it's particularly useful to invent a hypothetical piped logger implementation which happens to "rm -rf /" if sent SIGUSR1! :) ... > Regarding the piped logger: > > I would guess that a "malicious child" can disable logging for itself by > closing > the fd of the piped logger. IMHO this is even harder to detect for the admin > than a killed logger. The important thing to note is that an attacker who can run arbitrary code in one child can run such code in *any* (MPM) child. It is entirely at the discretion of the attacker whether requests are processed at all, let alone logged. So the disappearance of a piped logger or termination of a CGI script seems completely irrelevant to me. The attacker has complete control over "service" (of connections) and whether it continues. The attacker can already fork bomb as you say below, or force the parent to ramp up children as if under maximum load. ... > IMHO the advantage of the PID table is that it opens the possibility > for further sanity checks of the scoreboard, especially for cross > checking how many childs we really have. OTOH if I think about it more > closely it is questionable if the added overhead is really worth it, > because a "malicious child" at least can create a "fork bomb" without > the help of the scoreboard. Right: it adds overhead without benefit, and there is also a risk of regressions. e.g. in the trunk code it looks like children from ap_register_extra_mpm_process() don't go in the pid table, so the reclaim_one_pid() path to kill them won't work. joe
