Re: CVE-2003-1418 - still affects apache 2 current
* Reindl Harald: > mtime -> well, is directly in the header -> Last-Modified > size -> well, directly in the header -> Content-Length > inode -> well, where is there any security implication? I guess you could use it to form an NFS handle, and use that to bypass intended access restrictions. But that's the fault of NFS, and systems which do not use cryptographic NFS handles probably use non-random or 32-bit inodes, which are open to guessing anyway. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: Mitigation Range header
* Dirk-WIllem van Gulik: > On 24 Aug 2011, at 13:43, Florian Weimer wrote: > >> * Dirk-WIllem van Gulik: >> >>> Hmm - when I remove mod_deflate (i.e. explicitly as it is the default >>> in all our installs) and test on a / entry which is a static file >>> which is large (100k)* - then I cannot get apache on its knees on a >>> freebsd machine - saturating the 1Gbit connection it has (Note: the >>> attack machines *are* getting saturated). The moment i put in >>> mod_deflate, mod_external filter, etc - it is much easier to get >>> deplete enough resources to notice. >> >> Oh. Have you checked memory usage on the server? > > I had not - and you are right - quite high. I also tried it on a > Ubuntu machine - and that one dies right out of the gate - regardless > as to wether deflate is on- or off. It seems that this reflects different approaches to memory overcommitment. I didn't see any crashes with vm.overcommit_memory=2 on Linux, either. I wouldn't mention this in the advisory, though, because even if no critical process is terminated due to the out-of-memory condition, thrashing could still push the system beyond the point of recovery. Including the increased memory usage in the adviosry, as a potential attack indicator, would make sense, IMHO. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: Mitigation Range header
* Dirk-WIllem van Gulik: > Hmm - when I remove mod_deflate (i.e. explicitly as it is the default > in all our installs) and test on a / entry which is a static file > which is large (100k)* - then I cannot get apache on its knees on a > freebsd machine - saturating the 1Gbit connection it has (Note: the > attack machines *are* getting saturated). The moment i put in > mod_deflate, mod_external filter, etc - it is much easier to get > deplete enough resources to notice. Oh. Have you checked memory usage on the server? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: Mitigation Range header
* Plüm, Rüdiger, VF-Group: > As said this has *nothing* to do with mod_deflate. This was IMHO just > a guess by the original author of the tool. This matches my testing, too. I see a significant peak in RAM usage on a server where "apachectl -M" does not print anything with the string "deflate" (so I assume that mod_deflate is not enabled). This is with 2.2.9-10+lenny9 on Debian. If it is more difficult to check if mod_deflate is enabled, the advisory should tell how to check your server. If the method I used is the correct one, I don't think it's reasonable to suggest disabling mod_deflate as a mitigation because it does not seem to make much of a difference. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
