httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From HyperHacker <hyperhac...@gmail.com>
Subject Re: rational behind not checking the return value of apr_palloc and apr_pcalloc
Date Fri, 03 Sep 2010 12:37:11 GMT
On Fri, Sep 3, 2010 at 03:49, Graham Leggett <minfrin@sharp.fm> wrote:
> On 03 Sep 2010, at 5:31 AM, dave b wrote:
>
>> Sure ok :)
>> You have no complains from me really here. Just this could be an issue
>> on some platform with some mods potentially :)
>
> In order to understand why it isn't an issue for httpd, you need to
> understand how httpd works.
>
> httpd has a thin parent process, which is responsible for spawning children
> as required to do the actual work. Those children doing the actual work are
> expendable, and if the child process dies for any reason, the parent process
> will spawn new child processes to replace them.
>
> This is the fundamental reason why it is so difficult to crash an httpd
> server, because your module code only has the power to crash one child
> process. If a single child process goes bananas and tries to allocate all
> the RAM, that child will be terminated and replaced.
>
>> I only asked this list because the mod_wsgi guy wasn't checking the
>> result of memory allocation. The rational as I see it is: there is
>> only a few cases where this can happen 1: and 2: first the attacker
>> has to find  a way to reduce system memory to an almost oom condition
>> by the looks of it.
>
> If the attacker has found a way to create an OOM condition, that child
> process will terminate and be replaced, and the attacker would have caused
> no lasting damage.
>
> Regards,
> Graham
> --
>
>

...assuming he attacks a single httpd thread, as opposed to say a
distributed attack or attack on an unrelated process.

-- 
Sent from my toaster.

Mime
View raw message