Re: mod_deflate DoS
On Sun, Jun 28, 2009 at 08:20:20PM +0200, Stefan Fritsch wrote: we have received a bug report [1] that a DoS is possible with mod_deflate since it does not stop to compress large files even after the network connection has been closed. This allows to use large amounts of CPU if there is a largish (10 MB) file available that has mod_deflate enabled. Thanks for posting the report. This issue has been assigned CVE-2009-1891. On the security list, Ruediger suggested these fixes, which I've proposed for inclusion in 2.2.x: http://people.apache.org/~jorton/CVE-2009-1891.1.diff http://people.apache.org/~jorton/CVE-2009-1891.2.diff along with a third fix which concerned event MPM write completion - AFAICT that is not relevant on the 2.2.x branch. Regards, Joe
Information about svn commit: r570307 - in /httpd/httpd/branches/2.0.x:CHANGES STATUS server/log.c
Hi William Rowe,
After upgrading Apache from version 2.059 to 2.0.63, in Netware the Apache
process doesn't stop immediately but waits for some action like a key press
from user.
But when looked into it, the issue started appearing from Apache version 2.0.61
So, i started testing this issue by removing the changes one by one that went
into 2.0.61 and i'm suspecting that the changes made for the revision 570307
might be the cause of this issue.
http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/server/log.c?r1=421178r2=570307
Similarly, i tested this issue by removing changes one by one that went into
2.0.63 and i'm suspecting that the changes made for the revision 607255 (for
the function log_child) might also be the cause of this issue.
http://svn.apache.org/viewvc/httpd/httpd/tags/2.0.63/server/log.c?r1=603921r2=607255
So, if we comment out the code in Apache version 2.0.63 which will create a
pipe between the newly created child process and child's stdin (server/log.c,
function name - log_child), we are not able to reproduce the problem:
/* ** Commenting for Netware specific functionality **
if ((rc = apr_file_open_stdout(outfile, p)) == APR_SUCCESS) {
rc = apr_procattr_child_out_set(procattr, outfile, NULL);
if (dummy_stderr)
rc = apr_procattr_child_err_set(procattr, outfile, NULL);
else if ((rc = apr_file_open_stderr(errfile, p)) == APR_SUCCESS)
rc = apr_procattr_child_err_set(procattr, errfile, NULL);
}
*/
I'm suspecting that some open file handles might be the reason for the improper
shutdown (but not sure). So, can you please provide me some more information
about the changes and what might be the affect of these changes.
Thanks and regards,
S.M Siva Rama Krishna
Immortal vs Pool Buckets
A quick question about immortal buckets. In all the examples I've seen, they are used with data that has static storage duration. However, the requirement for using them appears to be just that the data will live for at least as long as the brigade. I'm wondering about the borderline case, where the data has the same lifetime as the brigade. In my use case the data is either allocated from the request pool, as is the brigade, or is allocated from the heap but freed in a cleanup registered with the request pool. If I use pool buckets I'm concerned that sometimes the pool buckets will be converted to heap buckets when the request pool goes away, only to be immediately discarded anyway because the brigade is also on that pool. On the other hand, I'm not quite sure my data satisfies the conditions for an immortal bucket. Can anyone help? Tom ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
