Re: [RFC] Fallout from Apache CVE-2011-3192

On 08/31/2011 01:39 AM, Amos Jeffries wrote:
> Summary:
> overlapping multipart ranges causes Apache to spawn multiple process
> threads and DoS the server RAM and CPU capacities with one or few HTTP
> requests. Major for them.
>
>
> We had complaints/issues related to this with Squid a few years ago.
> While we do not have anything like the RAM and CPU issues (AFAIK), the
> bandwidth consumption part of the problem still occurs.
>
> IIRC we decided against compacting ranges due to issues with Adobe
> reader products combined with a lack of clear RFC support to stand on.
>
>
> I'm wondering which road we should go down and would like opinions from
> the rest of you. These are just the first choices that come to mind,
> other ideas welcome:
>
> 1) nothing. pass 206 replies straight through. continue to serve HIT in
> the specified range sizes and order.
> Pros: not our fault when things go wrong.
> Cons: users wont care about that. remains hard to cache.
>
>
> 2) re-structure range parts on the fly. Possibly due to ACL or config
> options.
> Pros: happy clients with broken agents.
> we can emit Warning headers.
> Cons: more CPU consumed, would require disker backing to avoid the RAM
> vulnerability that hit apache.
> No incentive for clients to ever get fixed.
> HTTPbis seem to be working towards requiring range compacting
> and maybe reordering.
>
>
> 3) answer with compacted ranges ourselves to HITs.
> Pros: bandwidth savings. service time savings. can be implemented in
> days.
> Cons: unhappy clients when using broken agents.
>
>
> 4) join (2)+(3): re-structure requested ranges but pass reply back as
> given by the server.
> Pros: less resource consumption. Net bandwidth savings.
> Cons: potentially breaks client agents?

If there is no real demand for these changes other than our general
desire to better Squid, than I vote for #1, its biggest "pro" being that
it is already implemented.

If are real users asking for a specific related feature/optimization,
then I would do #2 and/or #3 (but not #4 if I understand it correctly),
each controlled by ACLs to bypass broken agents and guided by specific
user needs. For example, if a user wants #3 but not #2, then just do #3
with ACLs but do not implement #2.

HTH,

Alex.

> Is the Adobe reader problem still valid today? Anyone aware of other
> clients doing similar things?
>
>
> Amos
Received on Wed Aug 31 2011 - 17:44:37 MDT