What are we trying to accomplish with code signing content?

Article
01/22/2010

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:

https://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?

Comments

Anonymous
January 24, 2010
The comment has been removed
Anonymous
February 01, 2010
I agree with Ralph's thoughts.
Anonymous
February 10, 2010
Paul, You have excellent points. IMHO we've generally moved away from requiring any kind of signing for locally installed content. I'm not sure why help would be different. Ralph has very interesting thoughts. Anand..
Anonymous
February 12, 2010
Thanks for the suggestions, Ralph!

Share via

What are we trying to accomplish with code signing content?

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:

· 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:

https://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.

How would you provide strong security given these constraints?

Comments

Additional resources

Share via

What are we trying to accomplish with code signing content?

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:

· 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:

https://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.

How would you provide strong security given these constraints?

Comments

Additional resources

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.