Since the DotNetNuke application was originally released, we have been committed to providing a highly secure web platform to the Microsoft community. Security on the web is a challenging area and we have gone to great lengths over the past 5 years to ensure the integrity of the application. We are certainly not perfect; therefore, we have (regrettably) dealt with a number of security issues over the years. In each case, we were able to solve the problem and issue a patch release which offered the necessary level of protection to the community. There is a tough balancing act between disclosing too much information or too little information, and we have relied on the process established by some of the industry giants in terms of dealing with these types of issues.
In 2006, we worked with Microsoft to establish an official Security Policy for the DotNetNuke project:
The purpose of the Security Policy was to provide clear guidance on how we deal with security issues in the DotNetNuke project. This includes instructions on how security details should be confidentially reported to us ( [email protected] ) as well as information on how we notify the community of security issues, explanation of severity levels, and our policy regarding detailed disclosure. Our security lead, Cathal Connelly, was instrumental in creating the policy and ensuring its long term execution.
Since the establishment of the Security Policy, we have dealt with a number of security issues of varying levels of severity. In order to do this properly, it takes time and focused effort. Typically this means dropping all other activities while we verify the existence of a problem and work towards a complete solution. Here I think its important for people to realize that it is not a trivial amount of effort. Generally, once a security vulnerability has been validated and the risk level is known, we must develop a solution which addresses the problem, thoroughly test the solution, package a new release, test the release, formulate a plan for the distribution, create the security bulletin, and write the security notification. The responsibility for the tasks outlined above is shared between a number of different resources on our team and the impact on their other project duties is usually somewhat compromised for a period of time. Regardless, the process we follow is thorough and is completely consistent with the way that any professional organization deals with security matters.
One of the benefits of having a large, passionate open source community is that people are generally willing to cooperate with us when it comes to matters pertaining to security. This is especially true for people who are committed to the platform and want to ensure its continued growth and prosperity. Most security issues are discovered by community members who are actively pushing the limits of the framework and are more than willing to contribute their findings back to the core for the benefit of the entire community. We have also successfully dealt with a number of "white hat" professional security organizations in the past. In these cases, the "white hats" are paid by clients to perform a thorough security analysis on a particular application. Generally, these organizations are willing to share their results with us in exchange for some minimal recognition ( which helps promote their business ). We have also had to deal with "black hats" ( ie. hackers ) on a few occasions. This is the most difficult security issue to contend with because there is no cooperation. Nonetheless, we have dealt with each incident successfully and the reputation of DotNetNuke as a secure platform has been maintained.
Late last week, we were notified of a security vulnerability which allowed an unauthorized user to upload a file into a DotNetNuke site. Attempting to contact the person who performed the exploit proved to be futile; so we spent considerable time over the weekend attempting to isolate the source of the vulnerability. As we worked the problem from our side, a number of emails came in to the [email protected] alias from community members who were further along in the analysis and were eager to share their findings with us. These community members represent a variety of stakeholder groups including user group leaders, government organization, and even the U.S. Military. It turned out that the problem was not as severe as anticipated, as only files with "safe" extensions could be uploaded to the server. We are actively working on a solution which will likely involve a 4.8.3 general release.
Why a general release? Well the main reason is that once you start deploying patches, there is no guarantee that the patch does not affect other areas of the system in adverse manner. Since DotNetNuke is a mission critical application, users must have 100% confidence that the software they are running is rock solid. As a result we provide full releases to ensure that the security fix is fully integrated with the rest of the framework and adequately tested. In addition, patches have a tendency to get distributed around the web and it is critical that users of the DotNetNuke platform have assurance that the code they are running has not been tampered with. By supplying full releases, it makes it easier for users to have confidence that the package came from a reliable source.
Late last night, a security issue was published by a third party hosting provider. Since the hosting provider ( a familiar member of the DotNetNuke ecosystem ) did not follow the standard security policy, we have not been able to verify the security vulnerability claims yet. After numerous requests for the hosting company to provide us with the details of the exploit, we are still waiting for a response ( ironically we have received more cooperation out of 'hackers' in the past than we are from this hosting provider ). It appears that the hosting company is actually using the exploit as a competitive advantage so that they can charge people a fee for a solution. Clearly this violates every professional, ethical, and moral value which the DotNetNuke community has been built upon. Unfortunately, we can not dictate how vendors in our ecosystem choose to conduct business. Therefore, we can only rely on the community to pass judgement on who is being a good citizen and who is not. Once we are able to obtain more information about this issue, I will provide a status update.