ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to

ModSecurity Blog: August 2008

ModSecurity Issue Tracker Now Available

I am happy to announce that we've just launched a public issue tracking facility for ModSecurity. It's available at We've selected JIRA for this purpose, not only because it is the best issue tracking product our there, but also because we were given a free licence. Atlassian, the company behind JIRA, is generously offering free licences to open source projects. I had used JIRA in a previous job, and have nothing but good things to say about it. I am happy now that we will be using it for my favourite project.

We've been using a private Trac instance to track ModSecurity issues for nearly two years now. There wasn't any particular reason we decided to go with a private system, apart that to run a public system required additional effort. However, you can't really have an open source project with a private issue tracking system, so the pressure to go public (which we've put on ourselves) eventually pushed the task to the top. Furthermore, we've noticed that there are people who are not using the latest version of ModSecurity. Naturally, you are not supposed to upgrade just because there's a new version out there, but we were lacking a facility that would enable our users to judge for themselves whether an upgrade is needed. For example, an upgrade that improves security might be justified, but an upgrade because of a feature you are not using is not likely to be.

Our new tracker is empty at the moment, but it will start to fill-up as we start to use it to plan future releases. The system is open for public registration, so feel free to use it to report the problems you encounter.

Issue tracking is just a start, by the way. The generous people of Atlassian have granted us free licences for all their products. FishEye, Confluence and Crucible are all candidates for installation in the near future.

Microsoft and Oracle Helping "Time-to-Fix" Problems

Before I talk to the title of this post, I have to provide a little back story. I have had an ongoing DRAFT blog post whose subject was basically a rant against many vendors who were unwilling to offer vulnerability details. Every now and then I would review and update it a bit, but I never got to the point of actually posting it. I figured it wouldn't do much good in the grand scheme of things and the mere act of updating it provided adequate cathartic relief that a public post was not required.  There has been some recent developments, however that has allowed me to dust off my post and to put a "kudos" spin on it :)

I have long been a proponent of providing options for people to mitigate identified vulnerabilities.  We all realize that the traditional software patching process takes way too long to complete and push out into production when considering that the time it takes for the bad guys to create worm-able exploit code is usually measured in days.  When you combine this with most vendor's vulnerability disclosure policies (which is essentially not to disclose any details), then it is obvious that the bad guys have a distinct advantage in this particular arms race...

Ideally, all vulnerability researchers would work with the vendor and they would jointly release details with patches and then customers would immediately implement them on production hosts.  Unfortunately, reality is much different.  Researchers often have their own agendas and decided to release vulnerability details on their own.  In these cases, the end users have no mitigation options provided by the vendor and are thus exposed to attacks.  For those situations where the researchers and the vendor work together, then the end user at least has a fix that they can apply.  The problem is that the standard time-to-fix for organizations to test and install patches is usually a couple months.  So, the vendor has pushed the pig over the fence onto the customer and essentially takes a "it's now your problem now" approach.

What would be useful would be some technical details on the vulnerabilities that are addressed within the patches.  Let's take a look at Oracle's position on public disclosure.  The fact that this is Oracle is irrelevant as many vendors share this same view and that is that they don't want to disclose any technical details of a vulnerability BEFORE patches are released.  I really can't fault them for this stance as they want to ensure that they have patches ready.  What I am focusing on here is when they have a patch set ready, they should provide enough technical details about the vulnerability so that an organization can implement some other mitigation options until the actual patches are installed.  Unfortunately, the vendors position is that they didn't want to release the details as to prevent the bad guys from obtaining the info.  What they are missing, however, is that both the good guys (Sourcefire, iDefense, etc...) and the bad guys are reverse engineering the vendors patches to uncover the details about the vulnerability.  The only people who don't have any details are the end users.

So the point is that Pandora is already out of the box when vendors release patches.  What they should do then is to give technical details for security folks to implement some defenses (for IDSs/IPSs).  A great example of this is when bleeding edge/emerging threats folks would create Snort signatures so that an organization can identify if someone is attempting to exploit a flaw.

Now, the whole point of this post is to highlight that I have been fighting the good fight with many vendors to try and get them to see the light on the value of either releasing technical details on web-based vulnerabilities so that end users can create virtual patches with a web application firewall, or even better, for the vendor to release some virtual patches themselves (using the ModSecurity rules language).  Well, we haven't achieved the latter one yet but we are seeing signs that both Oracle and Microsoft are starting to address the former.  Specifically, Oracle/BEA recently released details about a WebLogic plug-in for Apache and in the mitigation section they actually mentioned the use of ModSecurity to address the problem!  That is a huge step and something that I am extremely excited about.  Then just within the last week we saw the announcement of Microsoft's Active Protections Program (MAPP).  Here is the short overview -

The Microsoft Active Protections Program (MAPP) is a new program that will provide vulnerability information to security software providers in advance of Microsoft Corp.’s monthly security update release. By receiving vulnerability information earlier, security software providers can give customers potential improvements to provide security protection features, such as third-party intrusion detection systems, intrusion prevention systems or security software signatures.

This is certainly an interesting initiative and may help organizations to receive more timely mitigation options to help protect themselves until the official patches are deployed.

Overall, I have have say GREAT job Oracle and Microsoft for truly helping your customers to close their time-to-fix windows.   

ModSecurity 2.5.6 and Mlogc

The ModSecurity Log Collector (mlogc) is used to send ModSecurity audit log data to a console or Breach Security appliance.  The final packaged release of ModSecurity 2.5.6 did not contain the mlogc source as it should have.  This means that a "make mlogc" will fail.  However, the mlogc source is also packaged separately and can be downloaded from Breach Labs (  Please use the source from Breach Labs to build mlogc until the next release of ModSecurity.

ModSecurity Party at Black Hat

Breach Security (also known as the company behind ModSecurity) is organising an OWASP/WASC party at Black Hat US again this year, but if you are a ModSecurity user we are going to call it a ModSecurity party. See below for details.

2nd Annual Shadow Bar Cocktail Party

Once again Breach Security, OWASP and WASC are hosting the Shadow Bar
cocktail party during BlackHat at Caesar's Palace. Join us for great
food, great people and of course the Shadow Bar entertainment.

When:   Wednesday, August 6, 7:30 PM - 9:30 PM
Where:  Shadow Bar, Caesar's Palace, Las Vegas

RSVP:   Please stop by the Breach Security booth to pick up your
wristband which will give you entrance to the Shadow bar.

Transformation Caching Unstable, Fixed, But Deprecated

We have just released ModSecurity 2.5.6 to address several issues with transformation caching: the subsystem is unstable, can crash your server server, and is even susceptible to evasion in certain circumstances. Although the issues have all been fixed in 2.5.6 we have decided to deprecate the entire subsystem because there has been too many problems with it. If you are using the 2.5.x branch of ModSecurity you are advised to turn transformation caching off (it is on by default until 2.5.6) until you upgrade. You can do this with:

SecCacheTransformations Off

On the positive side, ModSecurity 2.5.6 is the first version to use the previously discussed licensing exception, which allows ModSecurity to be combined with other open source projects.


November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Atom Feed



Recent Entries