The Problem
When you have a network consisting of several subnets and routers at each of the boundaries looking something like this:

INET <-> router A <-> subnet1 <-> router B <-> subnet2

The issue here is, that clients in subnet1 ideally should know about both routers to reach all networks. By default they only receive one of them as a default gateway. Of course one could set a static route on each client by using some sort of logon script but a more elegant way is to use DHCP for this purpose.

Solution
After some research I finally figured out how to do this. You need to use a feature classless static route¹ which is of course documented in the corresponding RFC3442 (but hardly anywhere else). This option is supported by Windows 2k, XP, and upwards.

So to get dhcpd to serve this new option I did some further googling and came across this post with a solution for dhcpd3 by John Robinson:

# MS routes: adds extras to supplement routers option
option ms-classless-static-routes code 249 = array of integer 8;

# RFC3442 routes: overrides routers option
option rfc3442-classless-static-routes code 121 = array of integer 8;

option routers 172.22.0.1;
option ms-classless-static-routes 24, 172, 22, 99, 172, 22, 0, 1 ;
option rfc3442-classless-static-routes 24, 172, 22, 99, 172, 22, 
0, 1, 0, 172, 22, 0, 1 ;

The first two lines define the new commands to point to the corresponding option codes. These have to be in the global section. The rest of the lines can be specific to any of the other section if desired. The format for the information passed to the options is encoded in the following format:

If you want to supply a static route as follows: 192.168.1.0/24 (equivalent to netmask of 255.255.255.0) with a gateway of 192.168.1.1 you write the address as follows:

option ms-classless-static-routes 24, 192, 168, 1, 192, 168, 1, 1;

As also mentioned in the original post, it is required to supply the default gateway if using classless static routing. In the above example, this is done by the appended route

0, 1, 0, 172, 22, 0, 1 ;

equivalent to a default gateway of 172.22.0.1.

I hope this post will help some people running into the same kind of issues that I came across. Any thoughts welcome.

¹ The option code is 121, grep for that in the RFC for further information

MIME Sniffing is a technique implemented by IE >= 4.0 allowing the browser to dynamically guess the content type of downloaded files. Basically the browser analyzes the magic bytes of any downloaded file and decides whether to trust the server's transmitted content type or use its own guess. What IE does is, if there is a mismatch between the content type of the server and the one defined by the magic bytes, then it uses its own content type guess. The problem arises once a website allows users to upload content which is then published on the web server. If an attacker manipulates the content in a way to be accepted by the web app and rendered as HTML by the browser, it is possible to inject code in e.g. an image file and make the victim execute it by viewing said image. For more details read heise online on the topic here³

Quick test for web applications
To quickly assess whether an application is vulnerable to this type of attack, check if the following criteria are fulfilled:

1. The application allows uploads
2. The application does no post-processing on the uploaded content
3. The content is downloadable throught the application
4. The content is not checked for MIME type mismatches

Try uploading the following PNG file which pretends to be a JPG (pay close attention when downloading the file, some browsers such as FF might append a .PNG at the end, remove this) to the site in question. If a subsequent download of the file returns the exact same file with a content type of JPEG, the app is vulnerable. Opening the file in IE will render an alert box on the screen.

For this to work, you need to direct the browser to the file itself, having it loaded from an image tag inside an HTML page e.g. is not enough

Sidenote: IE 8 is no longer vulnerable to the image based attack².

The same attack also works in PDFs and other types of files. So if the app doesn't allow images but other content to be uploaded, it still needs to be evaluated if such attacks are possible.

How to protect your web app
There are several means of protecting you application from these type of attacks.

If dealing with images, use something like the Image Magick tools to resize or recompress the uploaded images prior to serving them. Any of these operations will remove the attack code⁵.

Microsoft also introduced several HTTP headers to disable content sniffing in IE 8²:

To force the browser to trust the servers content type, use the following additional HTTP header:

X-Content-Type-Options: nosniff

Additionally, it is also a good idea to use Wikipedia's approach as a 2nd line of defense. Use a separate (sub)domain to host your user-uploaded content. With this approach you ensure, that none of the scripts that might potentially be included in the content, are executed in the context of your web application and therefore don't have access to session cookies, etc.

Background

For further background on this type of attack I recommend the paper¹ by Barth et al of UCS Berkeley providing details of the inner workings of MIME sniffing.

Another interesting angle comes into play, once an attacker has control over the server itself. Jose Nazario over at arbor networks blog is describing a phishing attack also based on abusing the MIME sniffing⁴.

¹ Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves by Barth et al. of UCS Berkeley

² IE8 security, Part V IEBlog, Microsoft

³ Risky MIME sniffing in IE heise online

⁴ MIME sniffing and phishing arbor networks security blog

⁵ Watch out for new attack vectors based on buffer overflows in Image Magick, though.

München, 09. Juli 2009. Die OPTIMAbit GmbH, Beratungsunternehmen mit Sitz in München und führender Experte zum Thema Anwendungssicherheit, hat eine Studie zu Web Application Firewalls (WAFs) veröffentlicht. Komplett unabhängig werden mehrere Hersteller von WAFs sowie deren Lösungen betrachtet und vorgestellt. Ziel soll es sein, Wissenslücken zu schließen und interessierten Unternehmen theoretisches Wissen und praktische Einblicke anhand von Beispielen zu geben.

Weitere Informationen direkt bei OPTIMAbit

Here's an abstract of the contents of the speech:

A number of open source and commercial Web Application Firewalls (WAF) promise "all around" protection, freeing developers from the burden of dealing with security, while increasing the overall security level. This session presents the results of a study, clarifies where it makes sense to deploy a WAF and how to use it. Further topics are performance evaluations, details about rulesets, automatic learning features as well as maintenance and what level of interaction with developers is required.

The audience was particularly interested in the practical aspects of the study and comparison between different product vendors and on how the tests were executed.

The study covers the following products:

• BigIP by F5 Networks
• NetScaler by Citrix
• mod_security (open source)
• hyperguard by art of defence
• rWeb by deny all

OPTIMAbit will make the extended results of the study available to its customers by the end of the year.

For further information please contact me directly or refer to Bruce Sams of optima.
Thanks again to all vendors for supporting the study by supplying test machines and/or licenses.

The vendor offers an open ticket system to directly report security issues to development. Vendor response was very quick and a new release of the product fixing all reported vulnerabilities was issued within 1 month of reporting.

The reported vulnerabilities included several Cross Site Scripting and one critical privilege escalation issue. For further information please refer to Atlassian's security advisory.

I also want to thank Atlassian for giving proper credits for helping them solve these issues.