Closed Bug 103787 Opened 23 years ago Closed 23 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: 23 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.