Rule 330005: Blocklist of known malware sites w/ Anti-evasion features but in the actual rule its id:360005
Thank you for the reply. So when you ran your backtrace, can you tell me where in the modsecurity code this error is occurring?
If you do not know how to do this, please see this article:
https://www.atomicorp.com/wiki/index.php/Apache
If you didnt use a backtrace, then I have bad news - its probably not fixed. What you have there is a symptom, and you probably just treated the symptom.
So if you did run a backtrace, skip this part, this is just a refresher on segfaults:
The joy of segfaults
Segfaults, as you may know, are memory faults or "bus errors". All odd terms, but it all means the same thing = memory error. Specifically, it means you are trying to access memory the CPU physical can not access. That rule uses a lot of memory, and when you disable it you will use less. As a result, theres more memory to play with. These segfaults generally happen when theres a bug in some code somewhere that isnt using memory correctly. Now the bug is still there, and whatever isn't using memory correctly is still doing that, you just don't "see" it happening because you have more memory to work with and a lower probability of that happening (thats also why people see segfault happen "frequently" but not constantly, or periodically in general - they can happen constantly if you have a REALLY broken application or system.
Think of it like a bucket with holes in it, when its got less water in it, less will leak out, if it has even less nothing leaks out - but if you fill it up those holes start to leak. Its not the water (rules in this case) that cause the water to leak, its the holes (code). So if you have a segfault, its not the rules - they are just the harmless water, something else is causing the system to not use memory correctly. And with apache its all shared, so anything thats not doing that right it punching holes higher up on the bucket. Too much water, and it starts to leak out.
Now, with that said, I can say this with 99% certainty because you aren't the first person to think that modsecurity itself was the cause of a segfault, it seems logical I changed this and it stopped. However, each time we ran a backtrace it turned out to be something else entirely that was the cause. Not the rules and not modsec. Like I said, this isnt something thats ever occurred with modsecurity, it just seems like it is because you are treating the symptom and not the actual cause and that rule uses a lot of memory. Its an "innocent bystander" that has been blammed constantly for segfaults, and every time (look at faris posts for example) when we looked into this, low and behold it was something else.
I'd be delighted to help you with this because hopefully we can finally put this to bed once and for all. If you could run that backtrace I'm sure the entire Apache community would benefit because its a bug somewhere, and it needs to get fixed. Disabling that rule isnt actually fixing your problem, expect it to happen again at some point if something else needs a lot of memory. So far we've found bugs in Apache, APR, several apache modules (but not modsecurity), PHP, accelerators, encoders, lots of htaccess files (with loops in some cases), web applications and even virtualization bugs.
So we would really really love to see that backtrace.
