ModSecurity versions 2.5.8 and 2.5.9 have been released to fix two vulnerabilities which could be used to cause a denial of service (DoS).  The first vulnerability is fixed in version 2.5.8 and the second (as it was disclosed after version 2.5.8 was already frozen) is fixed in version 2.5.9.  Because of this, the 2.5.8 release should be disregarded in favor of 2.5.9.  Both vulnerabilities, however, have workarounds until ModSecurity can be upgraded/patched.

Vulnerability in the PDF XSS engine

The ModSecurity PDF XSS protection engine prior to version 2.5.8 would allow a NULL pointer to be dereferenced when a non-GET request was used to generate a PDF.  This would cause Apache to crash and allow for a denial of service (Low Risk).

As a workaround, you should disable PDF XSS protection (the default), such as in the following example, until an update to ModSecurity is in place.

SecPdfProtect Off

Vulnerability in the multipart request parser

The ModSecurity multipart request parser prior to version 2.5.9 would allow a NULL pointer to be dereferenced under some circumstances when a zero length part header name is used.  This would cause Apache to crash and allow for a denial of service (Med-High Risk).

As a workaround, you should disable multipart/form-data parsing and add a rule to detect exploitation, as in the following example, until an update to ModSecurity is in place.

###
# BEGIN TEMPORARY WORKAROUND
#
# Force URLENCODED processing so that the vulnerability is bypassed
# and the REQUEST_BODY target variable is populated, but at the 
# expense of no longer being able to parse multipart form arguments.
SecRule REQUEST_HEADERS:Content-Type "multipart/form-data" \
 "phase:1,t:none,t:lowercase,nolog,pass,ctl:requestBodyProcessor=URLENCODED"
#
# Deny any multipart requests with a zero length header name
SecRule REQUEST_HEADERS:Content-Type "multipart/form-data" \
 "chain,phase:2,t:none,t:lowercase,deny,msg:'ModSecurity DoS attempt - NULL part header name'"
SecRule REQUEST_BODY "(?m:^--.*\\x0d\\x0a?:.*\\x0d\\x0a?--)" "t:none"
#
# END TEMPORARY WORKAROUND
###

More details can be found in the CHANGES file within the released source packages.  Special thanks to those at Red Hat and Internet Security Auditors for disclosing the vulnerabilities.

Both of these are excellent examples of how ModSecurity can be used to provide a virtual patch before an upgrade and/or proper patch can be applied -- even a vulnerability within ModSecurity itself.

If you are unfamiliar with what the HTTPOnly cookie flag is or why your web apps should use it, please refer to the following resources -

• Mitigating Cross-site Scripting With HTTP-only Cookies - http://msdn.microsoft.com/en-us/library/ms533046.aspx
• OWASP HTTPOnly Overview - http://www.owasp.org/index.php/HTTPOnly

The bottom line is this - while this cookie option flag does absolutely nothing to prevent XSS attacks, it does significanly help to prevent the #1 XSS attack goal which is stealing SessionIDs.  While HTTPOnly is not a "silver bullet" by any means, the potential ROI of implement it is quite large.  Notice I said "potential" as in order to provide the intended protections, two key players have to work together -

• Web Applications - whose job it is to append the "HTTPOnly" flag onto all Set-Cookie response headers for SessionIDs, and
• Web Browsers - whose job it is to identify and enforce the security restrictions on the cookie data so that javascript can not access the contents.

The current challenges to realizing the security benefit of the HTTPOnly flag is that universal adoption in both web apps and browsers is still not there yet.  For example, depending on your web app platform, you may not have an easy mechanism to implementing this feature.  For example - in Java you could following the example provided here on the OWASP site - http://www.owasp.org/index.php/HTTPOnly#Using_Java_to_Set_HTTPOnly, however this doesn't work well for the JSESSIONID as it is added by the framework.  Jim Manico has been fighting the good fight to try and get Apache Tomcat developers to implement his patch to add in HTTPOnly support - http://manicode.blogspot.com/2008/08/httponly-in-tomcat-almost.html.  The point is that with so many different web app development platforms, it isn't going to be easy to find support for this within every web app that you have to secure...

As for browsers - they too have sporadic, non-consistent adoption of HTTPOnly.  It was for this reason that the OWASP Intrinsic Security group has started an RFC Spec for HTTPOnly - http://groups.google.com/group/ietf-httponly-wg.  Hopefully this group will get some traction with the various browser developers.

So, at this point you might be asking yourself - Ryan, that is interesting news and all, but why is this being posted on the ModSecurity site?  What can a web application firewall do to help with this issue?  I would then in turn reply - Great question, I am glad that you asked. ;)

One of my pet peevs with the web application security space is the stigma that is associated with a WAF.  Most everyone only focuses in on the negative security and blocking of attacks aspects of the typical WAF deployment and they fail to realize that WAFs are a highly specialized tool for HTTP.  Depending on your circumstances, you may not ever intend to do blocking.  There are many other use-cases for WAFs and how they can help, in this case as a tactical response tool to help address an underlying vulnerability  In this case, we could monitor when back-end/protected web applications are handing out SessionIDs that are missing the HTTPOnly flag.  This could raise an alert that would notify the proper personnel that they should see if editing the web language code is possible to add this feature in.  A rule to do this with ModSecurity would look like this -

# Identifies SessiondIDs without HTTPOnly flag
#
SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "!(?i:\;? ?httponly;?)" "chain,phase:3,t:none,pass,log,auditlog,msg:'AppDefect: Missing HttpOnly Cookie Flag.'"
  SecRule MATCHED_VAR "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid))" "t:none"

While this rule is pretty useful for identifying and alerting of the issue, many organizations would like to take the next step and try and fix the issue.  If the web application does not have a way to add in the HTTPOnly cookie flag option internally, you can actually leverage ModSecurity+Apache for this purpose.  ModSecurity has the ability to set environmental data that Apache reads/acts upon.  In this case, we can modify our previous rule slightly to use the "setenv" action and then we add an additional Apache "header" directive that will actually overwrite the data with new Set-Cookie data that includes the HTTPOnly flag -

# Identifies SessiondIDs without HTTPOnly flag and sets the "http_cookie" ENV
# Token for Apache to read
SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "!(?i:\;? ?httponly;?)" "chain,phase:3,t:none,pass,nolog"
  SecRule MATCHED_VAR "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid))" "t:none,setenv:http_cookie=%{matched_var}"

# Now we use the Apache Header directive to set the new data

Header set Set-Cookie "%{http_cookie}e; HTTPOnly" env=http_cookie

The end result of this ruleset is that ModSecurity+Apache can transparently add on the HTTPOnly cookie flag on the fly to any Set-Cookie data that you define.  Thanks goes to Brian Rectanus from Breach for working with me to get the Header directive syntax correct.

One note of warning - make sure that you understand how the web application is handling setting SessionIDs meaning if they are created server-side vs. client-side (in javascript).  This rule set will work fine if the SessionIDs are generated server-side.  If they are created client-side, however, this will disrupt session management.

Hopefully the data presented here will help people who would like to have the security benefit of this flag however are running into challenges with implementing it within the app.

Deciding to leave a job is rarely easy, but leaving your job and the project you've nurtured for six years is very difficult. In a few weeks' time I will no longer be working for Breach Security and, as a consequence, I will be joining the ModSecurity community as a user. I leave ModSecurity in the capable hands of Brian Rectanus, who has been taking care of it for some time now.

It's been an exciting journey, starting ModSecurity and growing it for all these years. It's been a pleasure working with the community and helping others solve their problems. It's been hard at times, but that made it all the more interesting.

Finally, I would like to take this opportunity to thank every single ModSecurity user, because we, all together, made ModSecurity what it is. I couldn't have done it without you.

I spent the last week importing ModSecurity's source code repository into subversion at Source Forge. I am proud to announce that a read-only version of ModSecurity's subversion repository is now publicly available. In addition to this, Atlassian has graciously given the ModSecurity project a license to use their software. We are currently using Jira to track reported issues, FishEye to track and analyze the code repository and have plans to add Confluence (a wiki) in the near future. Together, these tools allow users to test and apply fixes immediately as well as monitor the progress of reported issues and the progress of ModSecurity as a whole.

This is a big step forward for the ModSecurity project. The project is becoming much more open and feels more like an Open Source project should. Please take some time to look at the new tools. Comments are always welcome.

This year, the OWASP's Summer of Code event contains one project that's of particular interest to me (and possibly to you, consider that you're following this blog): Securing WebGoat Using ModSecurity. If you've even seen WebGoat (a learning sandbox that contains samples of many application security issues) then you know how difficult it might be to secure. It's true; it's probably the worst-case scenario for ModSecurity, because it's not your typical application, and it contains a number of problems that require the understanding of application state to exploit (and thus protect too). So we should all congratulate Stephen Evans for pulling through and reaching the end of the project.

I find the project interesting because it stretches the boundaries of what ModSecurity can do. For example, one of the features Stephen relied heavily on is the Lua scripting language, which is currently marked as experimental. As we are currently working on the design for ModSecurity 3, Stephen's feedback is going to be very useful to us.

If this sort of thing is indeed of interest to you then you need to know that Stephen will be sharing his experiences during the OWASP Summit in Portugal next week. If you'll be attending the summit (or even if you can schedule a trip on short notice) do consider attending.