mojoPortal 188.8.131.52 is now available on our download page.
This is an important security and bug fix release. All users of mojoPortal are urged to upgrade as soon as possible.
if the site is configured as recommended with only the /App_Data and /Data folders being writable by the web process, this attack would not work because the web process would not be able to rename the user.config file in the root. So the site would have to be mis-configured for this exploit to work.
if the site is actively monitored the Denial of Service would be corrected quickly
Issue # 2
There was a cross site scripting vulnerability on the public profile page /ProfileView.aspx where we were appending the user name/id into the page title without sanitizing it first. Since we were not enforcing any rules on user name/id by default other than it must be unique, a user could register with a specially crafted string to add an external script to the page. The script could be used for malicious purposes such as stealing the authentication cookie of a user who visited the infected user profile page. The fix for this involved both sanitizing the user name/id before we append it to the title and also adding some validation of user names /id when the user registers to prevent characters that can be used for this kind of exploit such as angle brackets.
The user name/id is shown on the member list and is html encoded there so that no exploit is possible. It would be easy to spot a malicious user name/id on the member list and then edit the user profile and lock the account.
For several versions now we have had an optional config setting for entering a regular expression for user name/id validation. Sites that were already using this would not be affected since the user would not be able to enter the malicious user name.
Potential Issue # 3
This one was not from this exploit bulletin, and is not specific to mojoPortal, but could potentially affect millions of ASP.NET sites. This article was brought to my attention by a community member, George Birbilis.
The full details of the vulnerability have not been posted yet so I'm not 100% sure whether it will affect mojoPortal or not. I will have to review it once the full details are posted. However from what I gathered so far, it sounds like a real issue that will affect a lot of sites. When I first read the article, I thought it was saying that the hacker would use error messages received from the server to crack the machine key and then they could forge a cookie to get administrative access to a site. If that is true then it is not as bad because by default no error details are sent from the server, there would only be sent the 500 status code which indicates an error. However from reading comments on a few other places it sounds like they do not in fact need any error details but can gradually decipher the machine key through a lot of requests just using the response status codes 200 (success) 404 (not found) and 500 (error). I took steps in this release in case that is how it works to help protect against this attack. Basically what I did was make it always return a 404 if there is a cryptography error. So if the theory is true that they need to see the 500 status code this solution may protect against it. We will have to wait for the full details to know for sure. As I understand it the full details will be released today at a security conference.
Microsoft has posted a Security Advisory 2416728 on TechNet which says they are investigating this problem to provide an update. They also provide a workaround. The workaround is basically to use a custom error page so that no error details are returned from the server. We already have that by default in mojoPortal where we use error.htm as the default error page. The only difference in their workaround suggestion, is that they use a custom.aspx page to show the generic error instead of plain html, and they use some logic to make a random amount of time for the thread to sleep so that timing of the 500 status code cannot easily be used as an alternate to error details. I recommend that you copy the C# version of the error page they provide into a text file named ErrorPage.aspx, put it in the root of your web site, and edit the web.config as follows (this is also shown in the Microsoft article):
wrap the entire <system.web section inside a location element <location allowOverride="false"></location> - this might cause an error in some installations, if it does just skip it and follow step 2.
find this in your Web.config file:
<customErrors mode="RemoteOnly" defaultRedirect="Error.htm">
<error statusCode="413" redirect="~/NeatUpload/Error413.aspx"/>
and change it like this:
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/ErrorPage.aspx">
That should help defend against possible attacks until an update is available from Microsoft. For more details to understand this problem, see http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx
You should also review the post installation check list to make sure you have configured your site securely.
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.
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:
SiteSettings siteSettings = CacheHelper.GetCurrentSiteSettings();
if (siteSettings != null)
string roleCookieName = SiteUtils.GetRoleCookieName(siteSettings);
HttpCookie roleCookie = new HttpCookie(roleCookieName, string.Empty);
roleCookie.HttpOnly = true;
roleCookie.Path = "/";
Other Non Security Bug Fixes
fixed a long standing issue in the VirtualPathProvider that we use to serve the theme.skin file from the skin folder. For a long time this problem was not very noticeable because most skins did not have much variation in the theme.skin files, but more recently with our support for Artisteer we use settings in the them.skin file to control how markup is rendered so that we can add the needed markup for Artisteer and also the newer jQueryUI skin. The problem was that whatever skin was used first after the application startup, would have its theme.skin file cached and when pages with other skins were used it was getting the copy from the cache because the cache key was identical. Since the one in the cache may not have the correct settings then it could cause it to render incorrectly. The fix was to make sure they are uniquely cached. Note however that VirtualPathProvider does not work under medium trust in .NET 3.5 (it does work in 4.0), in that case all skins use the theme.skin file from App_Themes/default. For those in full trust or in .NET 4 hosting, you should see things work better in this release when using multiple skins or allowing user skins.
fixed an issue in folder based child sites where the canonical url rendered in the head was not correct, it was doubling the folder name.
fixed a bug where if using related sites mode, newly created sites were not correctly inheriting security settings from the parent site unitl you saved the parent site again and then it would propagate to the child sites.
fixed a bug where if using related sites mode, the admin and edit links were not shown consistently to site editors in child sites
fixed a bug where jquery script was disabled if you set the StyleSheetCombiner to not load jQuery UI
fixed a bug where the Superfish menu was not rendering the mouse over effects in .NET 4 - Thanks to Benedict for the solution!
fixed a bug where if FirstName and LastName were used as custom profile properties it was not loading them correctly
fixed a pgsql data layer error in the forums feature
fixed a SQL CE data layer error in the image gallery
added error handling to the feed manager so that if a feed is missing the required channel element it does not crash the page
Follow us on twitter or become a fan on Facebook