Closed Bug 84545 Opened 23 years ago Closed 23 years ago

Review message pane DOM for "wiretap" exploits

Categories

(Core :: Security, defect, P2)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.4

People

(Reporter: security-bugs, Assigned: security-bugs)

References

(Depends on 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file)

New mailnews security prefs
1.58 KB, text/plain
Details 
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.
Keywords: nsBranch
Group: netscapeconfidential?
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+
Depends on: 86799
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
r=harishd
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
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: ckritzer → bsharma
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.
Group: netscapeconfidential?
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
Depends on: 152701
Depends on: 67702, 309228, 309258, 309263
Keywords: meta
Depends on: 309267
Depends on: 309276
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: