« December 2012 | Main | February 2013 »

3 posts from January 2013


Tomcat 7.0.35 Released

This is probably old news for many but the Apache Tomcat team released version 7.0.35. The changelog lists 31 bug fixes and improvements. Download a copy from a mirror near you.


iRule Fun Fact - HTTP::uri Doesn't Decode

Here's something unpleasant I learned recently. Take the following sample irule, which looks at the incoming URI of a request and rejects the connection if /jmx-console/ is matched:

    switch -glob [HTTP::uri] {
        "/jmx-console*" {
            reject }

It's one of those irules where you say, "Golly...I did that with just 5 lines! That's awesome! I am going to add other well-known, exploitable URIs and then roll this out everywhere!!"

There's a couple of problems with the pattern matching above. First, HTTP::uri only matches the literal string "/jmx-console*" What if one were to URL encode the request so that /jmx-console/ becomes /%6A%6D%78%2D%63%6F%6E%73%6F%6C%65/. Well, that gets right through. HTTP::uri doesn't decode the URI before handling like mod_proxy does so any URL encoded portion of jmx-console is not going to be matched.

The second issue: /JMX-CONSOLE != /jmx-console, which makes sense because URI's are case-sensivite after all. So, that will get through, (although you'll get a blank page in jboss for requests matching /JMX-CONSOLE) but if you've got some passionate security folks on your team, you'd probably want to handle that consistently.

The third issue: Place a couple of slashes in front of your url encoded jmx-console URI and that will go through, too. I think that requests for ///jmx-console are going to get through, too, but I don't recall testing that specific case.

Here's an updated version of the above sample rule:

    set tmpUri [string tolower [HTTP::uri]]
    set uri [URI::decode $tmpUri]
    switch -glob $uri { 
    "*/jmx-console*" {
            HTTP::respond 404 content {<html><head><title>Page Not Found</title></head><body>Page Not Found</body></html> }

The updated rule does a few things. First, it sets a temporary variable tmpUri, which sets the value of the incoming request's HTTP::uri to a lower case value. In the second line, I then decode that URI and set that to a second variable uri. The nice thing about URI::decode is that it doesn't matter if the request comes in as jmx-console, /%6A%6D%78%2D%63%6F%6E%73%6F%6C%65/, or even /j%6Dx%2Dc%6Fn%73o%6Ce/—it will still decode to jmx-console. (There might be a way to do this all in one line with one variable but this is what I've got so far.) Once all this business is worked out, then the switch statement evaluates the value of $uri instead of HTTP::uri to see if a pattern is matched. Note that I've prepended an asterisk in front of the slash in order to pick up those cases where multiple slashes are placed in front of the resource name.

Finally, don't reject or drop requests. Worms, vulnerability scanners, and script kiddies might be fooled/satisfied/fooled but folks that are determined may have their interests piqued if they send a bunch of requests to your web site and some of them result in a tcp reset while others result in a 404.

More investigation continues to see whether I can find other ways to get jmx-console requests through but this is a big improvement over what I was doing in the past.


Build Notes for Apache HTTP Server 2.4.3 on OS X 10.8 Mountain Lion

Prerequisites: XCode and the XCode Command Line Tools (downloadable from developer.apple.com or from within the Downloads preference panel within XCode)


Once the apache httpd source has been downloaded, run the following command to remove the "quarantined" extended attribute from executables in your source directory, (needed in order to execute the configure script):

xattr -rd com.apple.quarantine /path/to/source

The following options to pass to configure will enable and load ALL apache modules, (fun for playing with Apache but not necessarily good for production use and don't be surprised if some modules need to be unloaded):

./configure --prefix=/usr/local/apache-httpd-2.4.3 --enable-load-all-modules --enable-mods-shared=reallyall

If you get a configure error like: error: C compiler cannot create executables, run the following to create a symlink to help configure find cc:

sudo ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain

For me, configure also complained that PCRE was missing. Running

brew install pcre (from the Homebrew package manager for OS X) took care of that.

Attribution: This post on StackOverflow was invaluable in clearing the configure error "C compiler cannot create executables"