mojoPortal 2.3.5.3 is now available on our download page.
This is another security update in follow up to version 2.3.5.2 which we released on Friday afternoon to address 2 mojoPortal specific security issues and it had some initial defense against a more general ASP.NET vulnerability the full details of which were released Friday afternoon at a security conference in Argentina. On Friday night Microsoft released information about the vulnerability and a workaround to help protect sites until Microsoft can provide a fix to the underlying problem. On Saturday morning I updated the post for version 2.3.5.2 with the workaround information.
Over the weekend we continued to review how best to protect mojoPortal and this morning we are releasing mojoPortal 2.3.5.3.
This release has the same fixes provided in version 2.3.5.2, but also has the Microsoft suggested workaround pre-applied. Additionally, we have added a new page in the Administration Menu that can detect a few common configuration issues that affect security and provide links to information about how to correct the configuration. If a serious configuration issue is detected, it shows an alert in the Administration Menu to bring it to your attention.
Note that in a multi site installation this page is only available in the root administrative site.
I strongly advise everyone to upgrade as soon as possible if you haven't already.
There was also a bug introduced in version 2.3.5.2, the fix I had made for the FileService issue had caused an error in the page if using the alternate File Manager (which doesn't use the file service). This issue is fixed in version 2.3.5.3
Note that in this release I also commented out the PageNotFoundHandlerModule in Web.config. I'm not 100% sure this is needed but it is probably better to play it safe. The downside is that users who click bad links will not see the friendly page not found page but the generic error page.
For more details see also:
UPDATE 2010-09-25
Scott Guthrie of Microsoft just posted about an additional protection that can and should be applied at the server level. If you have control of your own server you should take the additional step of installing UrlScan and configuring a rule as indicated in the article.
http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx
UPDATE 2010-10-04
The fix for the ASP.NET security bug is now available in windows update. However, the change has a negative side effect for the current release of mojoPortal which may cause authenticated users to experience an error on your site. The error occurs when trying to decrypt the role cookie which was encrypted before the update was applied. Previously, if there was an error decrypting a role cookie, it was throwing a System.Security.Cryptography.CrypotgraphicException (which we were handling so the user would not experience any error). After the windows update it now throws a more generic HttpException which the current release does not handle so the user will see the error page, and the only way to solve it is to clear the cookie. I have added handling for the changed error for the next release of mojoPortal. There is one workaround you can do right away to solve this problem, you can add code to the ErrorPage.aspx in the root to clear the role cookie so that at least the user will only see the error page one time. To do this, edit the ErrorPage.aspx file with a text editor. At the top add this:
<%@ Import Namespace="mojoPortal.Business" %>
<%@ Import Namespace="mojoPortal.Business.WebHelpers" %>
<%@ Import Namespace="mojoPortal.Web" %>
then add this code to the bottom of the Page_Load event:
try
{
SiteSettings siteSettings = CacheHelper.GetCurrentSiteSettings();
if (siteSettings != null)
{
string roleCookieName = SiteUtils.GetRoleCookieName(siteSettings);
HttpCookie roleCookie = new HttpCookie(roleCookieName, string.Empty);
roleCookie.HttpOnly = true;
roleCookie.Path = "/";
HttpContext.Current.Response.Cookies.Add(roleCookie);
}
}
catch{}
Follow us on twitter or become a fan on Facebook
