- From: <bugzilla@jessica.w3.org>
- Date: Sat, 22 Sep 2012 15:54:02 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18975 Summary: registerContentHanlder and registerProtocolHandler open huge security and privacy holes Product: HTML WG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P2 Component: HTML5 spec AssignedTo: erika.doyle@microsoft.com ReportedBy: lmm@acm.org QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org The 6.5.1.2 Custom scheme and content handlers features of registerProtocolHandler and registerContentHandler open huge security and privacy holes which are not described in the specification and for which there is no reliable mitigation such that users of these features could count on. It's understandable that these are attractive features from the point of view of the power they put in the hands of developers of new protocols and content-types. The bug is that these features are inadequately specified and the security of them inadequately analyzed and mitigated. Here is an incomplete analysis: These features expand the attack surface for introduction of malware, for leakage of private information in unanticipated and undisclosed ways. While the security section alludes to a few of the problems, the mitigations given are not implementable in a way that a browser-independent web application that wished to use the features could do so reliably. For one small example, registerContentHandler for a new image type might merely prompt the user for permission to install a new content-type handler, without clearly identifying that now, all images of that type will be sent to the handler site as soon as the image is received. This gives the site that registers the content handler far more information about the user's activities. It exacerbates the current difficulties of multiple applications overwriting the default content handler for various media types, provides for no 'undo' mechanism for putting back pointers to local interpreters, etc. As these are intended to be permanent changes to the underlying systems and not bounded by interpretation within the browser, a web site is now allowed to affect the permanent operation of the receiver's system. While this might be thought of as no different from typical installation dialogs, installing new software on a system usually involves virus and malware scanning, checking digital signatures of the the installed code and so forth. After a new handler has been installed, the server of the handler is now part of an attack surface. Attempting to strengthen the mechanism for preventing malicious overwriting of legitimate handlers could merely encourage malicious preemptive registration of handlers. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 22 September 2012 15:54:03 UTC