What are we trying to accomplish with code signing content?

Help file content and web content have historically been significant attack vectors that hackers and viruses have utilized quite a bit over the last decade. We’ve seen significant issues with .CHM security issues since HTML Help 1.x was released. HTML based attacks in general are huge - we had a hack against our TechNet site just yesterday.

So how do we prevent this sort of thing – even though the TechNet issue is a web specific example. Here are some of the constraints:

· If anyone with minimal privileges can install or be tricked to install content with dangerous scripts, an Admin could potentially run unsafe content. On machines that are shared between multiple users, a user could unknowingly execute script that may have been installed by another user with lower execution privileges. In a review with the Windows Security group, they warned against the dangers of this scenario.

· Even with Admin privileges, Admins don’t always understand the implications of what they are installing, so we still wish to provide notification that the action they are about to take is potentially unsafe.

· With Self-branded content, there's higher risk of script being executed that is potentially unsafe – this, for us implies an even higher risk that we’ll need to protect the user against.

· With Help Viewer 1.0 we are ultimately aiming at a broader user base than just Visual Studio users. We would like to become a replacement for both WinHelp and HTML Help 1.x.

If you look at how security is managed for WinHelp today, its primary attack surface is around its macro capabilities. This is why in Vista and Win7, macros are completely disabled by default. You have to be an Admin to update the registry with some reg keys in order to re-enable these features.

Additionally, with HTML Help 1.x, check out this list on Microsoft Help MVP Rob Chandler’s site:

http://helpware.net/FAR/far_faq.htm#SecurityUpdates

For better or worse, there’s a whole lot of security restrictions on help files now. The difference you may argue is that these are generally mitigated when a user installs a .chm via a setup program.

The primary difference we have with Help Viewer 1.0 however is that a user can install content from media or the cloud, as well as updating from the cloud. Currently, this is mostly for Microsoft content, but we are not architecting to limit it to MS only content.

· We ideally wish for a secure mechanism for installing and updating content regardless of the source location.

· We need a mechanism that as a starting point helps guarantee against unsafe script being executed unintentionally, or at least with full knowledge that you’re opening yourself up for that.

I think we agree that this is a pain (perhaps a necessary evil), and we’re open to discussion for how we might better address this in SP1, for example. Maybe the Admin applied reg key solution like WinHelp and HTML Help employ would be OK. I think what we’re trying to get across though is that, as its apparent with all the UAC hoopla around Vista and Win7, we unfortunately live in a general “unsafe” age and at a platform level we need to both educate users about the potentially unsafe actions they are about to take, and where possible prohibit if they are not in a position to make that kind of evaluation.

How would you provide strong security given these constraints?

Since there isn't any way that you can be certain that your help system is always secure, an additional approach to security that might be useful is to make certain the anti-virus vendors are on board. If the documentation for how to read your storage system is readily available along with some encouragement from MS, the users with anti-virus software installed will have an additional layer of protection.

You could also implement a layer to go between the original HTML and whatever you are using to render the HTML. This layer would be responsible for looking at all links/script/java and not allowing anything through which goes outside of the root domain, or in the case of a local installation, anything outside of the folder the content is installed in. An exception method could be enabled via the registry for companies wanting to supply documentation that points to their website -- with the normal restriction to administrative privilege needed to modify the registry.