Posted by: cathal connolly
Saturday, May 31, 2008 3:43:00 PM 

As per the old proverb , we're seeing a lot of activity around security these days. Hopefully by now, people are aware of last weeks release that fixed a number of security issues including a few that we rated as "Critical" .

Unfortunately since then a number of other issues have come to light, which mean that we'll we working hard over the weekend (again ) to resolve these. Hopefully we'll be able to get a 4.8.4 release together quickly, get it into testing on dotnetnuke.com, and release it to the community early next week.

We encourage anyone who finds what they believe is a security issue to follow responsible disclosure practices and email the details to security@dotnetnuke.com . This is a highly monitored email alias, and we typically respond to any mails within a few hours. Two of the issues that we're going to be resolving were both handled in this fashion, one from an extremely large publishing company, and another discovered by one of the project leads. These are both cross-site scripting  issues, that we rate as "Low"., and both rely on altering querystring parameters.

The final issue however was not responsibly disclosed. Whilst the group who discovered the issue emailed us, they simultaneously contacted a number of sites that list security vulnerabilities. As the details are now in the public domain I thought it would be prudent to blog about his and offer advice to the community. This issue is another "Low" issue, and is again a cross-site scripting problem. However, in this case the issue relies on URL's that are invalid being incorrectly interpreted. Due to this reliance on invalid URL's a majority of the community are already secure from this issue.

In early versions of the MIcrosoft IIS Webserver, IIS would pass virtually any URL to the underlying application, even if it did not follow the rules set out via the relevant W3C RFC's. Often security vulnerabilities relied on these invalid URL's, and recognising this as an issue Microsoft developed their URLScan filter . I'm running this filter on my development machine (XP pro) and have validated that it stops this issue. The good news is with IIS6 (Windows 2003), and IIS7 (Vista/WIndows 2008) the URLScan filter is typically not needed as many of the capabilites were built into the updated versions of IIS - though I would still recommend any hosting providers to consider running it as it has some additional protections. In my experience it's a common practice for hosting providers to run URLScan filter (in two that I worked for we automatically installed it as part of the Microsoft IIS Lockdown tool when we built webservers), so I expect that only a small portion of the community are theoretically vulnerable to this issue. That said, we will be working hard on getting an updated release out to ensure the ongoing security of the community.

Finally, I'd like to say a few words about the security of the DotNetNuke platform as a whole. I'm sure that in can be a disheartening to hear about security issues and the need to perform updates (trust me, when you get 3 emails on a Friday night and know you're not going to have much of a weekend it's pretty depressing), but paradoxically the finding of issues is not a negative, but rather should be seen as a positive. One of the strengths of open-source over closed-source, often known as "Linus's law" is that "given enough eyeballs, all bugs are shallow" - from a security perspective this means that as the source is available for all to see, errors are in plain view, and can be found, reported and quickly fixed.

In the early days of DotNetNuke many issues were found by community members and responsibly disclosed, in fact that's how I initially became involved as a core member - I was working as a security consultant performing audits for major banking, financial and e-commerce sites and decided to audit an early version of DotNetNuke and found a few issues that I helped Shaun resolve. Whilst this still happens, in the past year or two we've seen more and more reports from professional security companies and large organisations. As DotNetNuke has evolved, getting used in more and more enterprise level sites, many of these are choosing to pay for professional audits or purchase high-end security tools costing thousands of dollars. As many of these audits take days/weeks, and lots of these companies are incentivised to find issues, we are being regularly and comprehensively audited, and yet the number of issues found is still quite low, pointing I think to our general code quality and use of best practices. I also know of a number of audits that failed to find a single issue, and I'm sure there are a great many we never hear of as few organisations would feel the need to email us to report a successful audit, we only hear about the failings. In general I am convinced that the community is benefiting from hundreds of thousands of dollars being spent on security every year.

In a future blog post I hope to talk more on some of the efforts we make in the security area such as using tools and performing manual audits of new code, our application of defence in depth policies, and our use of general best practices.

Trackback Print

Tags:

Categories:

Location: Blogs Cathal Connolly Core :: Security