Closed Bug 275312 Opened 20 years ago Closed 17 years ago

Print engine allows JavaScript execution

Categories

(MailNews Core :: Printing, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: arve.bersvendsen, Assigned: whimboo)

Details

(Keywords: fixed1.8.0.14, verified1.8.1.8)

Attachments

(2 files)

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
Confirmed, TB 1.0 winXP
Status: UNCONFIRMED → NEW
Component: General → Mail Window Front End
Ever confirmed: true
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".
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?
QA Contact: front-end
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
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.
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.
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.
Flags: blocking-thunderbird3?
Keywords: qawanted
Version: unspecified → Trunk
My SeaMonkey build from 1.8 branch also shows the bug (all my testing is Linux).
(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.
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?
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

Flags: blocking1.8.1.6?
Flags: blocking1.8.1.5?
Flags: blocking-thunderbird2?
Assignee: nobody → hskupin
Keywords: qawanted
Hardware: PC → All
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 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+
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 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+
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
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird2?
Keywords: checkin-needed
Verified with version 3.0a1pre (2007071403).
Status: RESOLVED → VERIFIED
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?
Flags: blocking1.8.1.7?
Flags: blocking1.8.1.7+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Flags: blocking1.8.0.13+ → blocking1.8.0.14+
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 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+
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.
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
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: