Closed
Bug 275312
Opened 20 years ago
Closed 17 years ago
Print engine allows JavaScript execution
Categories
(MailNews Core :: Printing, defect)
MailNews Core
Printing
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: arve.bersvendsen, Assigned: whimboo)
Details
(Keywords: fixed1.8.0.14, verified1.8.1.8)
Attachments
(2 files)
146 bytes,
text/html
|
Details | |
913 bytes,
patch
|
mnyromyr
:
review+
mscott
:
superreview+
dveditz
:
approval1.8.1.8+
dveditz
:
approval1.8.0.14+
|
Details | Diff | Splinter Review |
User-Agent: Opera/7.60 (Windows NT 5.1; U; en) Build Identifier: When you attempt printing an HTML e-mail that contains JavaScript, JavaScript is executed immediatly when print preview is called. Reproducible: Always Steps to Reproduce: 1. Compose e-mail using text/html, containing JavaScript: <html> <head> <title>Test</title> <script type="text/javascript"> alert("Javascript alert"); </script> </head> <body><p>Test</p> </body> Attachment decoded: untitled-1.htm </html> 2. Receive mail in Thunderbird 3. Print the mail, or invoke the print preview Actual Results: A JavaScript alert, saying "JavaScript alert" is displayed Expected Results: The browser should have ignored the JavaScript
Reporter | ||
Comment 1•20 years ago
|
||
Comment 2•20 years ago
|
||
Confirmed, TB 1.0 winXP
Status: UNCONFIRMED → NEW
Component: General → Mail Window Front End
Ever confirmed: true
Comment 3•19 years ago
|
||
Confirmed, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051003 SeaMonkey/1.1a, but only if View -> Message Body As -> Original HTML is set. Not Windows- and Thunderbird-only. Suggest changing "OS: Windows XP" to "OS: All".
Comment 4•19 years ago
|
||
Does the bug allow now system or user account compomise in connection with http://www.mozilla.org/security/announce/mfsa2006-05.html at least for Thunderbird 1.0.7 and 1.5?
Updated•17 years ago
|
QA Contact: front-end
Assignee | ||
Comment 5•17 years ago
|
||
WFM with latest versions of Thunderbird from 1.8.0 and 1.8.1 branches. Is this still an issue for SeaMonkey?
Assignee: mscott → nobody
Component: Mail Window Front End → MailNews: Printing
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: front-end → printing
Comment 6•17 years ago
|
||
If I turn on JavaScript for MailNews, which defaults to off, then the alert is displayed in SeaMonkey trunk. When having JS off (default), it's not displayed. It also isn't displayed when viewing HTML messages as plain text, even not if it's an inline-displayed HTML attachment. I'm not sure this is a bug, it sounds like expected behavior to me.
Comment 7•17 years ago
|
||
Argh, ok, I completely misread this, blame last night. Yes, print preview shows the alert in SeaMonkey trunk even with JS disabled for MailNews. This looks really wrong.
Assignee | ||
Comment 8•17 years ago
|
||
Strange. I can only see this for my trunk debug build of Thunderbird under Linux. I cannot see this for Thunderbird 2.0.0.4 under Windows and Mac OS X. Even my debug trunk build under Mac OS X doesn't pop-up the javascript alert. I can't say anything for 1.8.0 or 1.8 branch builds under Linux. Anyone who could test the branch releases under Linux? This could be a security issue. Dunno why this bug was unattended for such a long period.
Comment 9•17 years ago
|
||
My SeaMonkey build from 1.8 branch also shows the bug (all my testing is Linux).
Comment 10•17 years ago
|
||
(In reply to comment #5) > WFM with latest versions of Thunderbird from 1.8.0 and 1.8.1 branches. Can still easily reproduce the bug with Thunderbird 2.0.0.5pre (Windows/20070706) with default JS settings, if the "original HTML" view for message body is active. When javascript.enabled is set to 'false' (default: 'true'), the alert isn't displayed, though.
Assignee | ||
Comment 11•17 years ago
|
||
Ok, I've done more tests. I can reproduce this security issue with 1.5.0.12 and 2.0.0.4 und Linux. Both branches are affected and execute javascript.
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Comment 12•17 years ago
|
||
this might be as easy as making sure we set the mail app type (APP_TYPE_MAIL) on the root docshell for the print engine in nsMsgPrintEngine.cpp
Updated•17 years ago
|
Flags: blocking1.8.1.6?
Flags: blocking1.8.1.5?
Flags: blocking-thunderbird2?
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 13•17 years ago
|
||
I hope that's the right way. It's the first time that I made a C++ patch. After compiling I cannot see the javascript alert anymore.
Attachment #271740 -
Flags: superreview?(mscott)
Attachment #271740 -
Flags: review?(mnyromyr)
Comment 14•17 years ago
|
||
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE This patch fixes it for me too. One thing to watch out for, I think this might start pushing print preview through the mail content policy manager. There might be issues with remote images and if you've allowed remote images for a message and then try to print preview, do those images load or are they blocked? Could be worth poking around at.
Attachment #271740 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 15•17 years ago
|
||
Scott, I cannot see any issue with remote images. I created a HTML message and saved it as draft. Opening the draft shows me an empty rectangle with the broken image sign. Opening the print preview the image isn't shown. Ok, that's like expected. After that I loaded the image for this message. It's visible inside the body. Opening once again the print preview shows me the image. No blocking of allowed remote images happens.
Status: NEW → ASSIGNED
Comment 16•17 years ago
|
||
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE Yeah, looks good. I did some testing with global and message specific remote content blocking and found that these settings are indeed honored by print preview now! (As are those for View HTML As...)
Attachment #271740 -
Flags: review?(mnyromyr) → review+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Comment 17•17 years ago
|
||
cool! I think this patch is ready for the trunk. I'll land it for Henrik. Thanks Henrik!
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 18•17 years ago
|
||
Verified with version 3.0a1pre (2007071403).
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 19•17 years ago
|
||
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE This patch will stop Javascript execution for printing and print preview. Perhaps a security related issue?
Attachment #271740 -
Flags: approval1.8.1.6?
Updated•17 years ago
|
Flags: blocking1.8.1.7?
Flags: blocking1.8.1.7+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Updated•17 years ago
|
Flags: blocking1.8.0.13+ → blocking1.8.0.14+
Assignee | ||
Comment 20•17 years ago
|
||
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE Asking approval accordingly to blocking flags.
Attachment #271740 -
Flags: approval1.8.0.14?
Comment 21•17 years ago
|
||
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE approved for 1.8.1.7, a=dveditz for release-drivers
Attachment #271740 -
Flags: approval1.8.1.7?
Attachment #271740 -
Flags: approval1.8.1.7+
Attachment #271740 -
Flags: approval1.8.0.14?
Attachment #271740 -
Flags: approval1.8.0.14+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Comment 22•17 years ago
|
||
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE Landed on MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH.
Updated•17 years ago
|
Comment 23•17 years ago
|
||
verified fixed 1.8.1.7 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.7pre) Gecko/20070828 Thunderbird/2.0.0.7pre Mnenhy/0.7.5.666 ID:2007082804 - no javascript execution/warning on testcase Adding verified keyword
Keywords: fixed1.8.1.7 → verified1.8.1.7
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•