Security Flaw

In January 2004, another interesting dilemma presented itself. I received an e-mail from an external party, a web application security specialist who claimed to have discovered a severe vulnerability in the DotNetNuke application (version 1.0). Upon further research, I confirmed that the security hole was indeed valid and immediately called an emergency meeting of the more trusted Core Team members to determine the most appropriate course of action. At this point, we were fully focused on the DotNetNuke 2.0 development project but also realized that it was our responsibility to serve and protect the growing DotNetNuke 1.0 community. From a technical perspective, the patch for the vulnerability proved to be a simple code modification.

The more challenging problem was related to communicating the details of the security issue to the community. On the one hand we needed the community to understand the severity of the issue so that they would be motivated to patch their applications. On the other hand, we did not want to cause widespread alarm, which could lead to a public perception that DotNetNuke was an insecure platform. Exposing too many details of the vulnerability would be an open invitation for hackers to try and exploit DotNetNuke web sites, but revealing too few details would downplay the severity. And the fact that the project is open source meant that the magnitude of the problem was amplified. Traditional software products have the benefit of tracking and identifying users through restrictive licensing policies. Open source projects have licenses that allow for free redistribution, which means the maintainer of the project has no way to track the actual usage of the application and no way to directly contact all community members who are affected.

The whole situation really put security issues into perspective for me. It's one thing to be an outsider, expressing your opinions on how a software vendor should or should not react to critical security issues in their products. It's quite another thing to be an insider, stuck in the vicious dilemma between divulging too much or too little information, knowing full well that both options have the potential to put your customers at even greater risk. Ultimately, we created a new release version and issued a general security alert that was sent directly to all registered users of the DotNetNuke application by e-mail and posted in the DotNetNuke Forum on www.asp.net:

 Subject: DotNetNuke Security Alert Yesterday we became aware of a security vulnerability in DotNetNuke. It is the immediate recommendation of the DotNetNuke Core Team that all users of DotNetNuke based systems download and install this security patch as soon as possible. As part of our standard security policy, no further detailed information regarding the nature of the exploit will be provided to the general public. This email provides the steps to immediately fix existing sites and mitigate the potential for a malicious attack. Who is vulnerable? -- Any version of DotNetNuke from version 1.0.6 to 1.0.10d What is the vulnerability? A malicious user can anonymously download files from the server. This is not the same download security issue that has been well documented in the past whereby an anonymous user can gain access to files in the /Portals directory if they know the exact URL. This particular exploit bypasses the file security mechanism of the IIS server completely and allows a malicious user to download files with protected mappings (ie. *.aspx). The vulnerability specifically *does not* enable the following actions: -- A hacker *cannot* take over the server (e.g. it does not allow hacker code to be executed on the server) How to fix the vulnerability? For Users: { Instructions on where to download the latest release and how to install } For Developers: { Instructions with actual source code snippets for developers who had diverged from the official DotNetNuke code base and were therefore unable to apply a general release patch } Please note that this public service announcement demonstrates the professional responsibility of the Core Team to treat all possible security exploits as serious and respond in a timely and decisive manner. We sincerely apologize for the inconvenience that this has caused. Thank you, we appreciate your support... DotNetNuke - The Web of the Future 

The security dilemma brings to light another often misunderstood paradigm when it comes to open source projects. Most open source projects have a license that explicitly states that there is no support or warranty of any kind for users of the application. And while this may be true from a purely legal standpoint, it does not mean that the maintainer of the open source application can ignore the needs of the community when issues arise. The fact is, if the maintainer did not accept responsibility for the application, the users would quickly lose trust and the community would dissolve. This implicit trust relationship is what all successful open source communities are based upon. So in reality, the open source license acts as little more than a waiver of direct liability for the maintainer. The DotNetNuke project certainly conforms to this model because we take on the responsibility to ensure that all users of the application are never left on an evolutionary dead-end and security issues are always dealt with in a professional and expedient manner.