Planet COSI

I've been playing around with Nginx web server over the past few days, its a great light weight web server, ideal for VPS's or smaller Amazon EC2 instances where resources are not as abundant.

One thing I like about nginx so far is the configuration, while I haven't had to do anything overly complex with it yet, it does seam to be quite flexible.

Here's a quick example of redirecting a www domain to the non www version:

server {
   listen 80;
   server_name www.example.com;
   rewrite ^ http://example.com/ permanent;
}

Note that's just one way of doing it, by creating a new virtual server for the non-www hostname and redirecting all requests. You can also do this from within your main server declaration, eg:

server {
   listen 80
   root /web/root/;
   if ($host != 'example.com') {
      rewrite ^ http://example.com/ permanent;
   }
}

I like the first method better, but this just goes to show how flexible the configuration is for nginx

Happy New Year!

I am going to interrupt my long hiatus of posting by a few pictures from my trip out to the Sierras in California.I’ve been staying in near the Kirkwood ski resort both working on building my quads of steel tele-mark skiing and hiking up the countless peaks in the area. The weather here has been unseasonably warm, with little to no snow outside of what’s man-made (which is a pity for skiing), but hiking in a tee-shirt in the crisp air and bright sun is unbeatable.

Peace and chow,

Jacob

Earlier this week at the 28C3 security conference in Berlin researchers presented on a denial of service (DOS) technique that several web application platforms (PHP, ASP.NET, Node.js, Tomcat, Java's HashMap/Hashtable etc) are vulnerable to, known as hashdos.

The exploit takes advantage of hash collisions in the internal implementation of hashtables / hashmaps (think CFML struct). When two keys are hashed and result in the same hash code a collision occurrs, and additional processing must take place to store or retrieve the item. Most application servers store request input variable (eg form, url scopes) in such a data structure. If you can construct a request with variable names that all have the same internal hashcode, the request goes from taking less than a second to process to several minutes.

As you can imagine this can cause a server to crawl/crash pretty quickly with a relatively small payload. Microsoft has released an out of band security patch for ASP.NET already. Tomcat has provided a work around in versions 7.0.23 or 6.0.35 and up.

The typical patch / workaround for this issue is to limit the number of input request variables, ASP.NET defaults this limit to 1000, tomcat defaults to 10,000.

It's not clear yet if this vulnerability is remotely explotable within JRun, or ColdFusion. I did run some tests on a JRun/ColdFusion install and did not replicate the problem, when I tried on Tomcat I did experience the DOS, however it's still very possible that the issue exists on JRun - my tests were certainly not conclusive. If you are running ColdFusion on something other than JRun (such as Tomcat, JBoss which runs on tomcat, etc) make sure to check with your vendor about this issue.

I haven't seen any word from Adobe about this issue yet, but I'll be sure to update this entry and post another if anything becomes public.