Review message pane DOM for "wiretap" exploits

VERIFIED FIXED in mozilla0.9.4

Status

()

P2
normal
VERIFIED FIXED
17 years ago
13 years ago

People

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

Tracking

(Depends on: 1 bug, {meta})

Trunk
mozilla0.9.4
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
(Assignee)

Comment 1

17 years ago
From Jesse:
HTMLAnchorElement.toString should be noAccess for mail messages because
link.toString() returns the URL of the link.

Comment 2

17 years ago
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.

Comment 3

17 years ago
DocumentType.baseURI should be noAccess for mail, since it gives the URL of a 
page.

Comment 4

17 years ago
It looks like all HTMLElements also have baseURI, and maybe all Nodes.
All Node's *should* have a baseURI.

Comment 6

17 years ago
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.

Comment 8

17 years ago
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.
(Assignee)

Updated

17 years ago
Priority: -- → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
(Assignee)

Comment 9

17 years ago
Adding nsBranch keyword as these bugs need to get into RTM.
Keywords: nsBranch
(Assignee)

Updated

17 years ago
Group: netscapeconfidential?
(Assignee)

Comment 10

17 years ago
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+
(Assignee)

Updated

17 years ago
Depends on: 86799
(Assignee)

Comment 12

17 years ago
Created attachment 47087 [details]
New mailnews security prefs
(Assignee)

Comment 13

17 years ago
Here's one more:

pref("capability.policy.mailnews.*.getNamedItem", "noAccess");

Comment 14

17 years ago
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

Comment 15

17 years ago
r=harishd

Comment 16

17 years ago
MStoltz - This is getting reviewed. Does this mean we have a fixinhand?

Comment 17

17 years ago
Is so, please mark the Status Whiteboard as such.
(Assignee)

Comment 18

17 years ago
verbal sr=jst on this one; he contributed to the patch.

Comment 19

17 years ago
a=asa on behalf of drivers.
(Assignee)

Comment 20

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
QA Contact: ckritzer → bsharma

Comment 21

17 years ago
Bindu, can you verify this one?

Comment 22

17 years ago
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
(Assignee)

Comment 23

17 years ago
Removing NS_Confidential flag.
Group: netscapeconfidential?

Comment 24

16 years ago
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

Updated

16 years ago
Depends on: 152701

Updated

13 years ago
Depends on: 67702, 309228, 309258, 309263
Keywords: meta

Updated

13 years ago
Depends on: 309267

Updated

13 years ago
Depends on: 309276
You need to log in before you can comment on or make changes to this bug.