16521 - Scripts in mail messages run from wrong origins

Status: VERIFIED DUPLICATE of bug 16672

(MailNews Core :: Security, defect, P3)

Description

[Norris Boyd]

Subject:
             Re: structure of XUL document containing message
        Date:
             Fri, 15 Oct 1999 10:39:33 -0700
       From:
             [e-mail] (Norris Boyd)
 Organization:
             Netscape Communications
         To:
             Rich Pizzarro <[e-mail]>
         CC:
             [e-mail]
  References:
             1 , 2




Thanks for the very descriptive answer. That helps a lot.

I tried a test with a script embedded inside a mail message and unfortunately
the script executes with the file: origin of the temp
file rather than the imap: or mailbox: origin. In the HTML model, scripts
execute with the origin of the enclosing document. This
is why the chrome scripts execute with imap: or mailbox: origins, and why
scripts in mail messages execute from file: origins.
Both are bad.

I'll open a bug on this and paste all this text into it.

I don't yet have a good idea of how to make this work. Thanks for your help and
I'm sure I'll have more questions later.

--Norris

Rich Pizzarro wrote:

  Hi Norris,
  Looks like you've got a pretty good handle on what is going on with
  mail display, but just to make sure, let me summarize what is going
  on when a message is displayed:

  When you select a message in the thread pane, you are actually firing
  a URL which is:

      - IMAP://  - for IMAP mail messages
      - mailbox:// - for local/POP mail messages

  The data is retrieved by the IMAP or Mailbox protocol handler and
  when the content type of message/rfc822 is encountered, the MIME
  stream converter is instantiated. libmime (as is affectionately known)
  starts reading the stream and parsing the RFC822 mail message.
  Since this is a display operation, libmime generates a XUL document
  for message display. This used to be an HTML document (in 4.x) but
  we need the UI capabilities of XUL for things like the attachment menus,
  etc...

  The top of this XUL document pulls in the following 2 JavaScript files:

                  chrome://messenger/content/attach.js
                  chrome://messenger/content/mime.js

  These will be used for saving attachments, toggling long address lists,
  etc... NOTE: there is also the ability for externally registered XPCOM
  objects to add included JavaScript to the header of the XUL document.
  These modules (which is native code running on the machine) will have the
  ability to insert output next to each persons address...an example would
  be "Click to Call" functionality. The click to call module could setup the
  link information to make a voice call and insert a pretty button next to
  each name that would allow for the user to click and make a voice call.
  For an example of this, see "mozilla/mailnews/mime/abstatus"  This
  example just puts an address book icon next to each name.

  Now, this is the interesting part and should be where we can keep mail
  messages in a "sandbox". All of what is described above is generated
  for the HEADERS of an RFC822 message. When the body of the message
  is encountered, a new temporary HTML file is written to disk and the following
  line is added to the XUL document:

  <html:iframe id="mail-body-frame" type="content-primary"
  src="file:///C|/TEMP/nsMimeBody.html" border="0" scrolling="auto" resize="yes"
  width="100%" flex="1"/>

  The contents of the mail message are not included in the XUL document, other
  than through this link. (Note, the name is random so you can't count on that,
but
  the ID of this IFRAME is not) Hopefully, we can control this IFRAME and
anything
  included within it to lock down security.

  You asked about the 4.x capability of turning off JavaScript. Well, would it
  be possible to turn off the JavaScript running in the IFRAME described above,
  but leaving the header JavaScript active. We have to leave that active,
otherwise
  users won't be able to save attachments, add people to their address book,
etc...

  Well, I hope this sheds some light on what we are doing, and hopefully, we'll
  be able to come up with a solution that is safe yet functional.

  - Rich

  Norris Boyd wrote:

  > Hi, I'm working on security for SeaMonkey and am trying to understand
  > how the XUL document containing messages is structured. The reason I
  > care is that I want to make sure that any JavaScript embedded in the
  > HTML of the message doesn't have any special privileges, while
  > JavaScript that you embed has all the privileges it needs to get its job
  > done. I'm copying Georgi Guniski, who's also working to find any
  > security holes in SeaMonkey.
  >
  > >From what I can tell by looking at nsMimeXULEmitter.cpp, the document is
  > generated dynamically and contains at least two JavaScript files,
  > attach.js and mime.js. (Are there others?) These scripts need special
  > privileges to execute because they access the XPConnect Components
  > object, which will soon be restricted from access by anything but
  > scripts loaded from chrome. When running with the XPConnect checks
  > enabled, I get security violations from attach.js because my code
  > currently computes it as being loaded from an imap: URI.
  >
  > Now I see in XULContentSinkImpl::DoneLoadingScript that there is
  > sink->mCurrentScriptURL which is "chrome://messenger/content/attach.js".
  > I could use the fact that this is a chrome URI and propagate principals
  > down to JavaScript so that this script is privileged. However, I'm
  > concerned that then scripts in mail messages or in web documents could
  > then reference chrome scripts and get access to privileged access.
  >
  > We don't have this problem for web documents because there is a XUL
  > document for the chrome and a HTML document for the web content. Is
  > there any way we could structure mail messages similarly so that chrome
  > scripts aren't mixed in with untrusted JavaScript?
  >
  > Also, 4.x has a pref for disabling JavaScript in email messages only. I
  > noticed that IMAP mail is loaded from the imap: protocol. What is POP
  > mail loaded from? Would it make sense to disable execution of JavaScript
  > from these protocols if the user doesn't wish to execute JavaScript in
  > mail?
  >
  > Thanks,
  > Norris

  --

  Rich Pizzarro
  [e-mail]
  AIM Nickname: RHPizzarro
  http://people.netscape.com/rhp

Comment 1

[Norris Boyd]

Subject:
            Re: [Fwd: [Fwd: structure of XUL document containing message]]
       Date:
            Fri, 15 Oct 1999 11:28:26 -0700
      From:
            [e-mail] (David Hyatt)
        To:
            Norris Boyd <[e-mail]>
 References:
            1




Sandboxing is based off an attribute...

<html:iframe/> is not sandboxed

<html:iframe type="content"/> and <html:iframe type="content-primary"/> are.

layout/html/document/src/nsFrameFrame.cpp is where the sandboxing is set up on
the nsWebShell.

If you plan to muck around with this sandboxing code, let me know.  I'll want to
review changes.

Dave

Norris Boyd wrote:

  Is it the case that  HTML frames contained inside chrome containers can't
reach outside their frame? Is that the mechanism
  by which web content is embedded in the XUL chrome for the browser?

  Thanks,
  Norris

Comment 2

[Norris Boyd]

Guninski's bug has an exploit and is thus verifiable. Closing this bug in favor
of his.

*** This bug has been marked as a duplicate of 16672 ***

Comment 3

[leger]

Bulk moving all MailNews Security bugs to new Security: General component.  The 
previous Security component for MailNews will be deleted.