We've had a series of exploits involving DOM properties that should not be accessible form a mail message. We need to go through the message pane DOM and make sure we've eliminated all of the ways to get at the URL of the message or any other properties that reveal information about the user's system configuration.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
From Jesse: HTMLAnchorElement.toString should be noAccess for mail messages because link.toString() returns the URL of the link.
XULDocument.location should be noAccess for mail so an attacker can't get around the HTMLDocument.location=noAccess restriction by sending a XUL document instead. (Do we also need to worry about XML documents? Other types of documents?) CSSStyleSheet.href should be noAccess for mail until bug 74281 is fixed.
DocumentType.baseURI should be noAccess for mail, since it gives the URL of a page.
It looks like all HTMLElements also have baseURI, and maybe all Nodes.
All Node's *should* have a baseURI.
Ok, so we need to find some way to block a mail message from getting the baseURI of any Node.
Yup, this sucks more and more the more we think about it.
I filed bug 86799 for making it easier to do things like "block a mail message from getting the baseURI of any Node" using configurable security policies. Right now, we'd need a line in all.js for each subclass of Node.
Priority: -- → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Adding nsBranch keyword as these bugs need to get into RTM.
Target is now 0.9.4, Priority P2.
Priority: P1 → P2
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Security, what can I say? nsbranch+
Keywords: nsBranch → nsbranch+
Here's one more: pref("capability.policy.mailnews.*.getNamedItem", "noAccess");
The getNamedItem problem is really bug 95735, but that should work as a temporary fix. I think blocking access to getNamedItem just for the NamedNodeMap class (instead of for *) would be sufficient.
Depends on: 95735
MStoltz - This is getting reviewed. Does this mean we have a fixinhand?
Is so, please mark the Status Whiteboard as such.
verbal sr=jst on this one; he contributed to the patch.
a=asa on behalf of drivers.
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Bindu, can you verify this one?
Verified on 2001-10-10-branch build on WinNT Following test does not write the link url in the messages window. <html> <head> <title>Bug 84545</title> </head> <body> <h4>Test case to test the HTMLAnchorElement.toString</h4> <p><a id="thelink" style="color: red" href="http://www.mozilla.org/">www.mozilla.org</a></p> <script> thelink = document.getElementById("thelink"); document.write (thelink.toString()); </script> </body> </html>
Status: RESOLVED → VERIFIED
Removing NS_Confidential flag.
See also: bug 90728 mailto: link treats body= as HTML (fixed?) bug 103787 pemission denied when using innerHTML in mail message (invalid)
Depends on: 66938
Summary: Review message pane DOM for exploits → Review message pane DOM for "wiretap" exploits
You need to log in before you can comment on or make changes to this bug.