Equal Time: Positive changes in the MCE
Security in software processes is a difficult business. Many times, a product can attempt to trade UI features and beauty for vulnerability. The Media Center Edition of Windows XP is a product that, I believe, requires these trade-offs. The product managers have a difficult task on their hands and I didn't make it any easier.
So when the lower cased one linked the MCE Update Rollup 2 and the Important Changes, I had to see if there was anything that might have been improved in security. My biggest concerns were in attempts to phish (or pharm) and attempts to heist a session while running the MCE extender. It would appear that the MCE team has improved the security in this rollup. Whether my post had any influence (I doubt that it did) is not the issue. Two things are important: 1) I probably should have raised these issues in conversations with that team through appropriate channels (I come clean) and 2) They show improvements in their product (They come clean). Given the Trusted Computing Initiative and Microsoft's awareness of security, I'm not surprised. Let's enumerate some of my earlier complaints and the improvements we see in Rollup 2.
Hosted HTML application & .NET add-in snooping - Rollup 2 now provides for HTML and add-ins in it's own process, separate of the MCE. While I'm uncertain of the constraints of CAS or other approaches that could be used here, the reality is that this cross-process approach provides a layer of protection to the MCE and behaviors of malicious add-ins or HTML. Their wording is as follows:
In previous versions, it was possible for a crash in a third-party add-in or HTML page to crash the Media Center itself. This latest version is much more robust, running these add-ins and pages in a different process. On failure of these components, the user is simply returned to the Media Center.
While crashes are a legitimate problem and I don't have data to support otherwise, this change provides a useful separation for security.
Security dialog boxes are now readable from a distance - Given the wording in the previous release of the MCE release, I believed that the team responsible for the MCE had chosen to trade beauty of UI interface for almost no security. I also believe that an ugly interface with great security would be awful, so given those two ends of the spectrum, i.e. beauty and security, there is some point where the user is provided with a reasonable level of security on a beautiful interface. Let me quote from the Microsoft Rollup 2 page on this issue:
Security dialog boxes that warn a user that they are crossing from a secure site (using the HTTPS protocol) to an unsecure site (typically using HTTP), or the reverse, are now readable from a remote position, rather than being displayed as normal Windows dialog boxes. Specifically, this feature applies to three security dialog boxes: crossing from a secure site to an unsecure site, crossing from an unsecure to a secure site, and sending the contents of a completed form to a secure site. For example, a security dialog box would be displayed while securing the user's private data (such as a password, credit card number, or other information) using a Secure Sockets Layer (SSL) page. However, if a process is outside of the scope of the hosted MSHTML, a Windows security dialog box may still be displayed.
There are other security dialog boxes that are not readable from a distance.
For more information about security dialog boxes, see Avoiding Internet Explorer Security Dialog Boxes (ed: link not active from here).
Before writing a feature such as an ActiveX control, consider how attackers might exploit your feature by using it on their own pages. For more information, see Designing Secure ActiveX Controls on the Microsoft Web site.
Note that they also give further advice on Secure ActiveX controls, i.e. raise the awareness of concerns for security with the developer that reads this document. I still don't like the "avoiding security dialog boxes", so there is improvement needed there.
Indication of Security Context - Rollup 2 addresses this as follows:
When viewing an HTML page in Media Center, the context menu now has a new button to display information about the page—such as the title and the URL—to indicate whether the page is secure.
Additionally, they have added the following:
Hosted HTML now incorporates the following Microsoft Internet Explorer security feature controls:
- FEATURE_DISABLE_MK_PROTOCOL
- FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
- FEATURE_MIME_HANDLING
- FEATURE_MIME_SNIFFING
- FEATURE_OBJECT_CACHING
- FEATURE_PROTOCOL_LOCKDOWN
- FEATURE_SAFE_BINDTOOBJECT
- FEATURE_UNC_SAVEDFILECHECK
- FEATURE_VALIDATE_NAVIGATE_URL
- FEATURE_ZONE_ELEVATION
I'll state it loudly, so that everyone can hear it:
CONGRATULATIONS TO THE MCE TEAM FOR IMPROVEMENTS IN THEIR SECURITY MODEL.
I never doubted they had the capability to make these changes. I just questioned whether these improvements would make it in the product in a reasonable time frame, if at all. It would seem that most questions that I had were answered in a way that has become a standard for Microsoft. Find the security deficiencies and fix them. Security is a process and Microsoft has adopted good practices in this process.