Making Sense of the SharePoint World

Apr-292010

SharePoint 2007 Security Vulnerability - Action Required

wpe3Stop the Presses!

Microsoft has announced the discovery of a cross-site scripting vulnerability in the SharePoint 2007 (and WSS 3.0) Help system. Although they are still investigating the root cause and working on a long-term solution, they have provided a workaround which will mitigate the only known (at the time of this writing) attack vector. You can read the details of the vulnerability and a server-side workaround in Security Advisory 983438. The Security team have also posted some more explanations about this class of vulnerability and some client-side mitigations in this blog post.

A Little More Info

The vulnerability is what is known as an "injection attack". Essentially, arbitrary JavaScript can be run by being passed as a carefully crafted parameter to the built-in SharePoint Help page. This script will run in the context of the current user's client session, and can therefore perform any actions against the SharePoint site that the user could.

This does not turn the user into an administrator, or otherwise elevate their own privileges. As far as I can tell, it does not (as some reports have suggested) expose the user's password. Update: This is with the default SharePoint authentication. Custom authentication methods could potentially store credentials in an accessible manner. I have no way to test that scenario, but any attacker would need intimate knowledge of how that authentication module worked in order to exploit it. So, while your passwords are probably safe, this vulnerability could allow an attacker to probe for and read any information in SharePoint that the user does have access to, or to vandalize or destroy information the user is permitted to update. Therefore, for the time being I strongly suggest disabling the help.aspx file in the Layouts folder of your SharePoint servers, either by following the instructions in the security advisory or through other means. (At this time, I don't suggest just deleting the file.)

Update #2

It has been pointed out that, although the attack itself cannot (usually) directly glean the user's credentials, an injected script could prompt an unsuspecting user into providing them, thinking the request was coming from your site. This does not change my advice (applying the mitigation procedures), but it should increase your priority in doing so.


Nov-272009

FeedBurner Under Control

MCBD07000_0000[1]The Fix is In, Thanks to Tom Resing

I have great news, thanks to fellow SharePointer Tom Resing. In my previous post I mentioned the problems the Community Kit for SharePoint:Enhanced Blog Edition has with the new link tracking parameters FeedBurner just started adding to their links.

In that post, I talked about the trials and tribulations of trying to get CKS:EBE working by installing an updated version. It turns out there was another approach to the problem. Although Google made the change to FeedBurner effective by default, Tom pointed out that they do offer an option to turn it off.

The Quick Fix

So, for those of you using both FeedBurner and CKS:EBE, here's the scoop. On the left menu in your FeedBurner Feed Stats Dashboard, in the Services section, is an option called "Configure Stats":

image

When you select Configure Stats, you have a section called "Reach", which has several options. You need to uncheck the box for "Track Clicks as a traffic source in Google Analytics":

image

That's all there is to it! Save the settings, and everything should be back to "normal".

Of course, it would have been nice if Google had posted a more conspicuous notice that they were making this change, and where it could be configured. It would have been even nicer if they had made the change "opt in" instead of "opt out".

Nevertheless, what's done is done. You should now be able to click through from my RSS feed directly to the articles you are interested in.

I apologize for any inconvenience.


Nov-252009

Burned by FeedBurner

MCj04314980000[1]At Least They Didn't Burn the Turkey

Just a quick note before I run off for the Thanksgiving holiday (USA). If you have been a subscriber to my RSS feed, you may have noticed a problem clicking through to my blog posts lately. This is because of a change that FeedBurner made a few weeks ago. They added extra parameter information to the connection string of links back to the blog.

This is theoretically a good thing, as it allows site logging to better determine where visitors are coming from. However, this blog uses the Community Kit for SharePoint: Enhanced Blogging Edition (CKS:EBE). The way CKS:EBE handles URLs doesn't allow it to correctly interpret these additional parameters. This resulted in broken page displays. You can still eventually navigate back to the right page, but it isn't as convenient as it should be.

I have just tested a patched version of CKS:EBE to resolve that problem. While the patch for the FeedBurner problem seems to work correctly, there are significant issues with other changes to the patched build of CKS:EBE. I noticed that my tag cloud was no longer resizing the keyword links to their proportions, for example, and there were major authentication problems. These glitches are bad enough that I decided to retract the update.

I apologize for the inconvenience. Rest assured, I'll continue working on getting links from FeedBurner working (without breaking everything else).

In the mean time, Have a Happy Turkey Day!


Jun-262009

SharePoint Service Pack 2 Repair Patch

MCSY00579_0000[1]"You Are Now Free to Upgrade Your Servers..."

Several weeks ago, Microsoft released Service Pack 2 for SharePoint. It was great! SP2 fixed many problems, large and small, as well as introduced a feature to scan your environment for potential upgrade issues.

There was just one problem. If you were running anything other than plain Windows SharePoint Services (WSS), SP2 would trip an expiration flag that made your computer think you were running an evaluation version. For many users this was just a little inconvenience. You could simply re-enter your product key, and the timeout would be removed. Unfortunately, users of Microsoft Search Server 2008 Express (MSSX) were in a pickle. For you see, MSSX doesn't have a license key.

Of course, MSSX user or not, Microsoft didn't plan for SP2 to do this. So they have been working diligently to come up with a patch to resolve the issue. As of last night, that patch has been released. You can read about the details, and/or download it, on the SharePoint Team Blog, or KB Article 971620.

So, install the patch, apply Service Pack 2, and the April 2009 cumulative update package, and you'll soon be SharePoint-ing your way into the future!