Last Comment Bug 275312 - Print engine allows JavaScript execution
: Print engine allows JavaScript execution
Status: VERIFIED FIXED
: fixed1.8.0.14, verified1.8.1.8
Product: MailNews Core
Classification: Components
Component: Printing (show other bugs)
: Trunk
: All All
: -- critical with 1 vote (vote)
: ---
Assigned To: Henrik Skupin (:whimboo)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-19 16:28 PST by Arve Bersvendsen
Modified: 2008-07-31 04:30 PDT (History)
14 users (show)
dveditz: blocking1.8.1.8+
dveditz: blocking1.8.0.14+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
HTML source for test case (146 bytes, text/html)
2004-12-19 16:32 PST, Arve Bersvendsen
no flags Details
Patch v1: Set correct APP_TYPE (913 bytes, patch)
2007-07-10 15:03 PDT, Henrik Skupin (:whimboo)
mnyromyr: review+
mscott: superreview+
dveditz: approval1.8.1.8+
dveditz: approval1.8.0.14+
Details | Diff | Splinter Review

Description Arve Bersvendsen 2004-12-19 16:28:35 PST
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
Comment 1 Arve Bersvendsen 2004-12-19 16:32:19 PST
Created attachment 169142 [details]
HTML source for test case
Comment 2 Lasse Marøen 2004-12-20 08:24:54 PST
Confirmed, TB 1.0 winXP
Comment 3 Ilja Sekler 2005-10-06 00:49:59 PDT
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 Ilja Sekler 2006-02-08 02:42:32 PST
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?
Comment 5 Henrik Skupin (:whimboo) 2007-07-07 06:36:05 PDT
WFM with latest versions of Thunderbird from 1.8.0 and 1.8.1 branches.

Is this still an issue for SeaMonkey? 
Comment 6 Robert Kaiser 2007-07-07 06:59:26 PDT
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 Robert Kaiser 2007-07-07 07:02:19 PDT
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.
Comment 8 Henrik Skupin (:whimboo) 2007-07-07 07:37:25 PDT
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 Robert Kaiser 2007-07-07 07:48:53 PDT
My SeaMonkey build from 1.8 branch also shows the bug (all my testing is Linux).
Comment 10 Ilja Sekler 2007-07-07 07:54:28 PDT
(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.
Comment 11 Henrik Skupin (:whimboo) 2007-07-07 07:58:56 PDT
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.

Comment 12 Scott MacGregor 2007-07-10 13:52:43 PDT
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

Comment 13 Henrik Skupin (:whimboo) 2007-07-10 15:03:37 PDT
Created attachment 271740 [details] [diff] [review]
Patch v1: Set correct APP_TYPE

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.
Comment 14 Scott MacGregor 2007-07-10 15:45:45 PDT
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.
Comment 15 Henrik Skupin (:whimboo) 2007-07-11 14:37:25 PDT
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.
Comment 16 Karsten Düsterloh 2007-07-11 14:41:51 PDT
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...)
Comment 17 Scott MacGregor 2007-07-11 15:29:29 PDT
cool! I think this patch is ready for the trunk. I'll land it for Henrik. Thanks Henrik!
Comment 18 Henrik Skupin (:whimboo) 2007-07-14 08:01:33 PDT
Verified with version 3.0a1pre (2007071403).
Comment 19 Henrik Skupin (:whimboo) 2007-07-14 08:02:46 PDT
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?
Comment 20 Henrik Skupin (:whimboo) 2007-08-06 13:56:11 PDT
Comment on attachment 271740 [details] [diff] [review]
Patch v1: Set correct APP_TYPE

Asking approval accordingly to blocking flags.
Comment 21 Daniel Veditz [:dveditz] 2007-08-21 14:54:05 PDT
Comment on attachment 271740 [details] [diff] [review]
Patch v1: Set correct APP_TYPE

approved for 1.8.1.7, a=dveditz for release-drivers
Comment 22 Karsten Düsterloh 2007-08-22 09:44:10 PDT
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.
Comment 23 Carsten Book [:Tomcat] - PTO-back Sept 4th 2007-08-30 11:43:17 PDT
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

Note You need to log in before you can comment on or make changes to this bug.