790 bytes, text/plain
834 bytes, text/xml
547 bytes, patch
|Details | Diff | Splinter Review|
1.27 KB, text/plain
1.50 KB, text/plain
in bug 328851 Comment #5 bz wrote: "JS does still run when we exit print preview;" a provable testcase when js shouldn't run in print preview is print previewing a message. on today's suite trunk - js executes with luser's privileges with a little help from xbl abuse. local folder to be attached. copy the local folder in Mail/Local Folders/bugXXX open folder bugXXX and print preview the only message in it.
local copy of the xbl - intentionally not linked from bugzilla because of referrer problems
> a provable testcase when js shouldn't run in print preview is print > previewing a message. That's with JS disabled in mail in general, right?
(In reply to comment #3) > > a provable testcase when js shouldn't run in print preview is print > > previewing a message. > > That's with JS disabled in mail in general, right? > yes, js disabled in mail, default build - but latest suite trunk, doesn't work on 1.5. i am quite tempted to file a bug for removing the ui option of enabling plugins and js in mail - users don't js/plugins in mail. imho they even don't need html in email, but some chix are used to html.
So there are two issues here, more or less: 1) Print preview doesn't do a good job of preventing script 2) Mailnews opens a non-mail docshell (in terms of nsIDocShell::APP_TYPE_*), so the "script disabled in mailnews" pref is not applied to the print preview window. Same issue in Thunderbird, of course. Not sure what we should do with print preview, but mail should probably flag this window that it opens as APP_TYPE_MAIL....
I haven't had a chance to test this yet. Will try it later tonight. But this should set the app type on the print preview docshell.
Doesn't seem to help (though the code does run).
(In reply to comment #5) > Same issue in Thunderbird, of course. i am not seeing the problem on thunderbird - ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ version 1.6a1 (20060301) is this the latest trunk?
Hmm. I was testing a debug build locally. I'll retest tomorrow; all the builds are building right now.
Hmm. Yeah, now I don't see it in tbird. I do see it in SeaMonkey. But the difference is that tbird blocks the XBL load via content policy. What happens if you include the XBL in your message?
I wonder why the fix for bug 294307 didn't help here for SeaMonkey.
yes, the remote xbl seems loaded, phoning home
with a thunderbird cvs build from today, print previewing a message doesn't execute js for me.
Right. But does tbird even load the XBL? That is, is the XBL constructor not executing, or is the XBL not even loading?
(In reply to comment #10) > Hmm. Yeah, now I don't see it in tbird. I do see it in SeaMonkey. But the > difference is that tbird blocks the XBL load via content policy. i believe in *print preview* the remote content isn't blocked a very *wild guess* is that in tbird js is disabled in "browser", so the xbl doesn't fire. if you disable js in seamonkey navigator, print previewing a message doesn't execute js. >What happens > if you include the XBL in your message? > haven't succeeded in including XBL in the message so far - data uris dont't seem to work iirc. it would be interesting HTML/XUL + XBL in one file if you can do that. or you mean multipart message - haven't tried this yet.
(In reply to comment #10) > What happens > if you include the XBL in your message? > including XBL in a message isn't easy. tried multipart (cid:bla) and data:text/xml;, and got assertion "Binding load from a non-URL URI not allowed"
> a very *wild guess* is that in tbird js is disabled in "browser" Doesn't seem to be... If multipart mails require non-host URIs, then they won't work with XBL, no. I really really wonder what the difference here is between tbird and seamonkey. :(
thunderbird trunk and latest 1.5 also executes js when print previewing messages with attachments containing <html><script>
local folder for the bird
a variation of this caused memory corruption - Bug 330445 may be a duplicate
I can see this with SeaMonkey 1.0.1 when I use File -> Print (not Print preview)
SeaMonkey 1.0.2 is already released. Blocking request moved forward.
Flags: blocking-seamonkey1.0.2? → blocking-seamonkey1.0.3?
wonder if someone can step up to try and get this into seamonkey?
Neil, what can we do about this in SeaMonkey?
according to my tests this seems fixed. bclary, can you please verify?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
We should figure out when this stopped working; I'd really like to know what caused the behavior change here...
georgi: can you tell us in what build of what application you tested this as wfm?
thunderbird 188.8.131.52 and trunk
Thuis has been filed against _SeaMonkey_ though, so this also needs to be verified there, else we need another bug filed against SeaMonkey on this problem.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
seamonkey 1.1.8 and trunk seem safe. print preview + xbl caused problems in browser, so probably fixing browser fixed mail. bz: do you see js executed ?
Whiteboard: [fixed?] → [sg:investigate] [fixed?]
replacing |alert| with |throw| shows no signs of js in seamonkey according to my tests.
georgi: is this SeaMonkey 1.1.8 or trunk?
(In reply to comment #36) > georgi: is this SeaMonkey 1.1.8 or trunk? > as i wrote both trunk and 1.1.8 don't execute js for me
> bz: do you see js executed ? I have no idea; I don't have time to test this. What I do know is that there is a difference between fixing a security bug and making a specific testcase no longer work. The latter can happen for many reasons that leave the underlying bug unfixed. So we need to track this until we have a good idea of why the testcase stopped working and can then evaluate whether that's a real fix for this issue. A 1-day range for the behavior, for example, would help a lot... ;)
aha, will try a range tomorrow my time. on trunk the xbl isn't loaded at all and js console reports security error for loading the xbl - so this is part of the 'fix' on trunk. on branch the xbl is loaded, js isn't executed
for the testcase " Localfolder" (containing remote xbl) the fixing range for seamonkey trunk is: 20070612 20070613 the first date loads the xbl and executes js, the second one doesn't.
wild guess what fixed these: Bug #275315 --> set the correct app type on the docshell used for print preview. Bug 379959: Add checks to loadBindingDocument. r/sr=jst ^^^ can't see this
The loadBindingDocument thing would only prevent remote XBL; can't that testcase include the XBL inline?
I thought someone already said that XBL can only be loaded from URLs, not URIs.
(In reply to comment #43) > The loadBindingDocument thing would only prevent remote XBL; can't that > testcase include the XBL inline? > i tried to include the xbl inline in a message but it doesn't work for me. data uris don't work and referencing multipart message doesn't work for me.
> data uris don't work They should on trunk...
is there any point finding the fixing range on branch?
i am not sure it is possible to place inline xbl in mail. data: uris seem to work only with content-type text/xml or application/xhtml and mail doesn't display these inline.
Could someone verify that the issue is fixed? I'm clearing the blocking requests due to being either bogus or not making sense to block on something that seems to be fixed. Please re-request blocking status for current releases if you can verify the bug still existing or resolve if you can verify it's really really fixed.
So.. the testcase became WFM when we stopped loading XBL from different origins on trunk. So in other words, the real problem is likely to still be present, and just needs to have the XBL included in the message. I tried using a message with an XML type, but we don't seem to show those inline... yet. If we ever start showing XHTML inline, we'll likely be screwed again. Comment 48 is wrong, as far as I can tell. data: URIs of XML type can be embedded in an HTML document. Someone needs to sit down and actually try to break this instead of pretending the problem doesn't exist.
>I tried using a >message with an XML type, but we don't seem to show those inline... yet. If we >ever start showing XHTML inline, we'll likely be screwed again. inline xhtml/xml will bring a lot of exploit vectors and probably even more active content >Comment 48 is wrong, as far as I can tell. data: URIs of XML type can be >embedded in an HTML document. i will retest. at the time of writing comment 48 data: xbl didn't work for me *in mail*.
as of 20080822 i can't include xbl in data uri in mail (both thunderbird and seamonkey). i believe the testcases are correct.
imo more real threats than this "print preview" may come from editor: 1. <iframe src="data:application/xhtml+xml;, ...." allows arbitrary xhtml/svg in editor - hit via reply/forward inline 2. Bug 371976 <iframe src="host/flash.swf" - execution of at least flash in seamonkey. if remote content is shown, may be hit from just previewing
One bug per problem, please. Can you post the data: testcases you had that didn't load the XBL?
<div style="-moz-binding: url(data:text/xml,%3cbindings%20xmlns%3d%27http%3a%2f% 2fwww.mozilla.org%2fxbl%27%3e%20%3cbinding%20id%3d%27r%27%3e%20%3ccontent%3e%20% 3cchildren%2f%3esome%20anonymous%20text%20%3c%2fcontent%3e%20%3cimplementation%3 e%20%3cconstructor%3e%20alert%28123%29%3b%20%3c%2fconstructor%3e%20%3c%2fimpleme ntation%3e%20%3c%2fbinding%3e%20%3c%2fbindings%3e#r)"> div2 </div>
Attachment #335040 - Attachment mime type: application/octet-stream → text/plain
So, do we still have a case that allows this bug to be experienced? If not, it probably should be taken off release blocking nominations.
> So, do we still have a case that allows this bug to be experienced? seamonkey trunk and 2.0b2 refuse to load the xbl so they seem safe
seamonkey 1.1.18 refuses to open the xbl too.
(In reply to comment #58) > seamonkey 1.1.18 refuses to open the xbl too. OK, thanks, then this is definitely not blocking 2.0 :) Probably it is actually even INVALID or WONTFIX now as I don't see much work being put into 1.1.x any more, I'd tend to INVALID as I'd feel nervous about WONTFIX being interpreted as trunk not fixing it.
Flags: blocking-seamonkey2.0? → blocking-seamonkey2.0-
Oh, I missed comment #58 - does that mean it's FIXED by some other bug, actually? or is this an underlying case we are papering over with a different fix and so it should stay open for theoretical reasons? In any case, canceling old blocking requests that don't apply any more, looks like we at least don't need to block anything on this.
> does that mean it's FIXED by some other bug almost sure yes. it used to work at the time of filing.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.