ʎʇıןıqɐɹǝuןnʌ SSX pǝɹoʇS

RESOLVED FIXED in seamonkey2.66

Status

defect
RESOLVED FIXED
4 years ago
2 months ago

People

(Reporter: yaaboukir, Assigned: frg)

Tracking

Trunk
seamonkey2.66

SeaMonkey Tracking Flags

(seamonkey2.48 wontfix, seamonkey2.49esr fixed, seamonkey2.51 wontfix, seamonkey2.53 affected, seamonkey2.57esr fixed, seamonkey2.63 wontfix)

Details

Attachments

(4 attachments)

Posted image PoC.png
Hi,

SeaMonkey is vulnerable to a stored XSS. An image with javascript url will be executed in the context of the target website when the user clicks to view the image.

Proof Of Concept: See attached screenshot
---------------------
Let's suppose an attacker adds an image to a page : <img src="Javascript:alert(document.cookie)">
Once the victim clicks to view the image, the malicious JS code is executed.

E.g : http://www.yassineaboukir.com/untitled.html "Click to view the image".

I have tested this in lastest Mozilla firefox, but luckily it is not reproducible.

Kind regards.
you haven't stored any XSS in _seamonkey_, it's code on the page. You could also just add an onclick handler to the image and that would work in all browsers.
Group: core-security-release
Hi, a web application would sanitize the onclick handler but wouldn't expect javascript to be executed via an image.
I can not reproduce it using a recent Windows build. The broken icon will just show and no additional Window if I click on it. Popups and javascript allowed.

Tested with todays private en-US builds:

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0 SeaMonkey/2.41
Build identifier: 20160123174750

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 SeaMonkey/2.43a1
Build identifier: 20160123205240

Please try again when 2.40 arrives.

FRG
I don't really understand if it's bad or not, but in Seamonkey 2.44a1 if you go to the webpage in the original post, http://www.yassineaboukir.com/untitled.html , and right-click on the broken image icon, a context menu will show up, and if you click on "view image" you will bring up the same dialog box (but in English for me) as in the original commenter's attached screenshot.

It appears to have executed the javascript.

Is that bad? I'm just saying the dialog box that appears is the same as in the commenter's screenshot.

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 SeaMonkey/2.44a1
I can reproduce it with the right mouseclick. I won't call it a big security problem right now because if a site can exectue js code bad things can happen at any time. But Firefox behaves differently here so this is a bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I forgot: private en-US x64 build

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48
In Firefox I get:
Mon Jan 23 2017 03:57:31
Error: uncaught exception: Load of javascript:alert(document.location) from http://www.yassineaboukir.com/untitled.html denied.
Flags: needinfo?(philip.chee)
Posted file HTML Test case
Summary: Stored XSS vulnerability → ʎʇıןıqɐɹǝuןnʌ SSX pǝɹoʇS
Group: core-security-release
Don't see any good reason to hide this bug after over a year being public.
Group: core-security-release
Originally filed for 2.43
Reproducible in 2.44 according to comment #4.
Reproducible in 2.48 according to comment #5 and #6.
In 2.51a1 "Right-click → View image" on the image placeholder gives me an alert with the URL and an [ OK ] button. IIUC this means I reproduced the bug.

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a1" 
ID:20170224003001 en-US 
c-c:27b56804b7e3fde261ad910b1866e78736621442 
m-c:69d2cf007cdc13cf2bd33370b1732d4f969fd9af

Happens on WOW64 (W32 app running on W64 Windows OS) according to comment #4.
I just reproduced it in Linux64.
OS: Unspecified → All
Hardware: Unspecified → All
Whiteboard: [seamonkey-2.43-affected] [seamonkey-2.44-affected]
Version: SeaMonkey 2.43 Branch → Trunk

Hi,

I am surprised this issue is still reproducible in the latest Seamonkey (Tested on 2.49.4 for OS X). This should definitely be remediated as it's not happening in Firefox for instance. As a matter of fact, it was reported as a security vulnerability and was fixed, see https://www.mozilla.org/en-US/security/advisories/mfsa2006-34/

Regards.

Flags: needinfo?(dveditz)
Flags: needinfo?(antoine.mechelynck)

I'm not involved with seamonkey so untagging myself, but I wonder if the project is dead? No release since July 2018 and that one didn't even autoupdate people on older versions: https://www.seamonkey-project.org/news

Flags: needinfo?(dveditz)

but I wonder if the project is dead?

Not it is not but basically any support by Mozilla has ended and we just need to build our own infrastructure. Ripping parts out of Gecko on short or no notice without adequate replacements doesn't help too.

Unofficial builds of the next versions are here:

http://www.wg9s.com/

Building an official 2.49.5 as an interim has just started.

I still consider this a minor security problem because if you are able to execute js you can do bad things anyway and anyone not using a basic script and ad blocker theses days is way more vulnerable. Nevertheless it should be fixed. I will look into it when I find some time.

Flags: needinfo?(frgrahl)

I think this patch

https://bugzilla.mozilla.org/attachment.cgi?id=214302

must be in this file: nsContextMenu.js (946, 989)
but I'm not quite sure.

It looks like the patches have been taken from these bugs to SM
Bug 329468 - Show Only This Frame XSS (FF, TB, Suite)
Bug 329521 - View Image xss
Bug 329583 - Sidebar View Image xss
except that the changes that had to be ported from browser.js to nsContextMenu.js.

(In reply to Yassine ABOUKIR from comment #11)

Hi,

I am surprised this issue is still reproducible in the latest Seamonkey
(Tested on 2.49.4 for OS X). This should definitely be remediated as it's
not happening in Firefox for instance. As a matter of fact, it was reported
as a security vulnerability and was fixed, see
https://www.mozilla.org/en-US/security/advisories/mfsa2006-34/

Regards.

I don't see which info I'm asked for.

Flags: needinfo?(antoine.mechelynck)
Flags: needinfo?(philip.chee)
Flags: needinfo?(frgrahl)
Whiteboard: [seamonkey-2.43-affected] [seamonkey-2.44-affected]

This should take care of it. Tested with 2.53 including viewing images form a blog via rss.

Cleans up the functions too and removes some ancient OpenTopWin calls.

These were the last 3 callers of ALLOW_CHROME.

Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Attachment #9069233 - Flags: review?(iann_bugzilla)
Attachment #9069233 - Flags: approval-comm-esr60?
Comment on attachment 9069233 [details] [diff] [review]
1234651-medianoscripts.patch

>+++ b/suite/base/content/nsContextMenu.js

>+  viewMedia(e) {
>+    let doc = this.target.ownerDocument;
Could use referrerURI = this.target.ownerDocument.documentURIObject;

>+    let systemPrincipal = Services.scriptSecurityManager.getSystemPrincipal();
This is only used within the first part of the if statement, could be moved into there (though 80 char limit means reformat/change of variable name).

>+    let where = whereToOpenLink(e);
>+    if (this.onCanvas) {
>+      let blobUrl = URL.createObjectURL(this.target);
>+      openUILinkIn(blobUrl, where,
>+                   { referrerURI: doc.documentURIObject,
>+                     triggeringPrincipal: systemPrincipal,
>+                   });
>+    } else {
>+      urlSecurityCheck(this.mediaURL,
>+                       this.target.nodePrincipal,
>+                       Ci.nsIScriptSecurityManager.DISALLOW_SCRIPT);
>+      openUILinkIn(this.mediaURL, where,
>+                   { referrerURI: doc.documentURIObject,
>+                     triggeringPrincipal: this.target.nodePrincipal,
>+                   });


>+  viewBGImage(e) {
>+    urlSecurityCheck(this.bgImageURL,
>+                     this.target.nodePrincipal,
>+                     Ci.nsIScriptSecurityManager.DISALLOW_SCRIPT);
>+
>+    let doc = this.target.ownerDocument;
Could use referrerURI = this.target.ownerDocument.documentURIObject;

>+    let where = whereToOpenLink(e);
>+    openUILinkIn(this.bgImageURL, where,
>+                 { referrerURI: doc.documentURIObject,
>+                   triggeringPrincipal: this.target.nodePrincipal,
>+                 });

r/a=me with those addressed/answered
Attachment #9069233 - Flags: review?(iann_bugzilla)
Attachment #9069233 - Flags: review+
Attachment #9069233 - Flags: approval-comm-esr60?
Attachment #9069233 - Flags: approval-comm-esr60+

Could use referrerURI = this.target.ownerDocument.documentURIObject;

I am always a bit uneasy about these long assignments. If one is null or undefined and errors pop up only now and then they are a bit harder to track down. this.target.ownerDocument should always be definied but who knows. documentURIObject might not be.

  • let systemPrincipal = Services.scriptSecurityManager.getSystemPrincipal();

Moved and reformatted. I will let this bake a few days in Bills 2.53. Let me know here or over irc if I can keep the first assignment split.

(In reply to Frank-Rainer Grahl (:frg) from comment #20)

Could use referrerURI = this.target.ownerDocument.documentURIObject;

I am always a bit uneasy about these long assignments. If one is null or undefined and errors pop up only now and then they are a bit harder to track down. this.target.ownerDocument should always be definied but who knows. documentURIObject might not be.

  • let systemPrincipal = Services.scriptSecurityManager.getSystemPrincipal();

Moved and reformatted. I will let this bake a few days in Bills 2.53. Let me know here or over irc if I can keep the first assignment split.

Happy to leave it as doc and doc.documentURIObject

Poor mans 2.49.5 version. Testcase no longer shows the message box and logs athe expected exception.
Viewing for- and back-ground images and videos via the menu still works.

Attachment #9070809 - Flags: approval-comm-esr52?
Comment on attachment 9070809 [details] [diff] [review]
1234651-medianoscripts-52.patch

a=me
Attachment #9070809 - Flags: approval-comm-esr52? → approval-comm-esr52+

Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/276536b6d831
Check view targets for possible unsafe content. r=IanN

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED

Awesome work! Can we request a CVE for this one?

Awesome work! Can we request a CVE for this one?
I will look into it for the 2.49.5 release. IanN did you by chance did this previously for another item?

Flags: needinfo?(iann_bugzilla)

(In reply to Frank-Rainer Grahl (:frg) from comment #27)

Awesome work! Can we request a CVE for this one?
I will look into it for the 2.49.5 release. IanN did you by chance did this previously for another item?
No, never done for another item. The ALLOW_CHROME was probably meant to fix the original issue, from 2006, but the reasons seem to be lost in the mists of time. If this does properly fix it, then we could possibly use that CVE.

Flags: needinfo?(iann_bugzilla)
You need to log in before you can comment on or make changes to this bug.