Closed Bug 103787 Opened 24 years ago Closed 24 years ago

pemission denied when using innerHTML in mail message (due to 'wiretap' fix)

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: pieter, Assigned: security-bugs)

Details

The following mail message: <HTML><HEAD></HEAD> <SCRIPT language="JavaScript"> alert(document.body.innerHTML); </SCRIPT> </BODY></HTML> results in nothing displayed and the following error being logged to the Javascript Console: Error: uncaught exception: Permission denied to get property HTMLBodyElement.innerHTML In the browser this script runs correctly. Something in the mail window seems to be restricting access to innerHTML.
-> Security General (I hope this is correct)
Component: Mail Window Front End → Security: General
Product: MailNews → Browser
reassign for real. From all.js pref("capability.policy.mailnews.*.innerHTML.get", "noAccess"); Looks like this is a purposeful security measure (which I believe is correct -- this is to prevent web-bugs from reading your mail).
Assignee: sspitzer → mstoltz
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → bsharma
Boris is correct - this is intentional. Mail messages cannot read innerHTML, this is to prevent the 'email wiretapping exploit' whereby an attacker can eavesdrop on an email sent by you to a third party. If you need to access innerHTML from a mail message, open all.js and delete the line Boris mentioned above, but bear in mind this will leave you vulnerable to the exploit.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Thanks for the quick replies! Is there any chance of stopping the exploit some other way and re-enabling internal access to the source from script? I am out of my depth here but it seems to me that web-bugs can exploit even very simple HTML without scripting in e-mail, e.g. using an IMG tag with some data sent to a server, thus allowing the server to at least detect that an e-mail message was received, and when it was viewed. Might all such exploits be better stopped by running the e-mail in a sandbox which prohibits access to any URI outside the local machine? (Perhaps optionally using a popup message allowing user to decide whether to permit the access or not.) It is a shame that innerHTML (and I think nodeValue when nodeType==3) are disabled to stop the exploit. There's something I want to do which I don't think can be done without one of these methods...
Pieter, Thanks for your comments. We thought about this for a long time, and we couldn't come up with any other way of preventing this exploit short of disabling JS in mail completely. The 'wiretapping' exploit is a worse than a web bug, since it allows a third party to find out not just when the message was received, but what it contains. I don't think it's possible to prevent an HTML page with JS activated from communicating information back to its home server. There's simply too many ways to do it. A 'sandbox which prohibits access to any URI outside the local machine' would also have to block images and any other content included in a mail message by reference, and that seems more drastic a step than blocking innerHTML and a few other properties. I appreciate that this is inconvenient for you, but we honestly couldn't find any other way to stop the exploit. If I hear of another way, or if enough people complain about this restriction, I will remove it. If the application you're developing is for an enterprise setting, you can delete the line mentioned above from all.js to remove this restriction in the browsers that use your application. This reopens the exploit, but that may be a risk you're willing to take. I don't think our competition has addressed this issue at all, so you'd be no worse off by turning off the restriction than you would by using a different HTML/JS-enabled mail client.
Thanks Mitchell, Sad, but I understand. I've been trying to find a reasonable solution to this for the past couple of days with no success. A customized build with a modified all.js file isn't an option in my case. I did come across an old builtin function called "taint" which might have done the trick. But I can guess why it was dropped - horrifically complicated (perhaps impossible) to implement throughout and to avoid loopholes. I guess another possibility would be an attribute somewhere (in style? but this isn't really a CSS issue) which says something like "-moz-secure:no", explicitly giving permission to access some of the content. Seems much too drastic and patchy for such a specific issue. Personally I would vote for always opening email in a sandbox. IMO linking content from an email (v.s. embedding the content) is a bad thing. When content is linked the communication cost is the same when the email is read once. Cost can be higher if it is read more than once. The email can't be viewed properly offline. If the email is saved for longterm reference some of the content may disappear due to removal from a server. (Or even worse, content might change! Not good in an archived email.) And I don't like the idea of links which can fire counters or whatnot at the other end just because I opened the email. The only links to non-embedded content should, I think, be those invoked by user interaction, e.g. clickable links. But having said all that, I expect there are people who would disagree...
Marking verified WontFix as per above developer comments.
Status: RESOLVED → VERIFIED
Summary: pemission denied when using innerHTML → pemission denied when using innerHTML in mail message (due to 'wiretap' fix)
You need to log in before you can comment on or make changes to this bug.