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

Status: RESOLVED FIXED

(SeaMonkey :: Security, defect)

Description

[Yassine ABOUKIR]

Attachment: 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.

Comment 1

[Daniel Veditz [:dveditz] back January 5, 2026]

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.

Comment 2

[Yassine ABOUKIR]

Hi, a web application would sanitize the onclick handler but wouldn't expect javascript to be executed via an image.

Comment 3

[Frank-Rainer Grahl (:frg)]

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

Comment 4

[benl]

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

Comment 5

[Frank-Rainer Grahl (:frg)]

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.

Comment 6

[Frank-Rainer Grahl (:frg)]

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

Comment 7

[Philip Chee]

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.

Comment 8

[Philip Chee]

Attachment: HTML Test case

Comment 9

[Daniel Veditz [:dveditz] back January 5, 2026]

Don't see any good reason to hide this bug after over a year being public.

Comment 10

[Tony Mechelynck [:tonymec]]

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.

Comment 11

[Yassine ABOUKIR]

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.

Comment 12

[Daniel Veditz [:dveditz] back January 5, 2026]

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

Comment 13

[Frank-Rainer Grahl (:frg)]

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.

Comment 14

[bblack]

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.

Comment 15

[bblack]

... and line 894 from this patch: https://bugzilla.mozilla.org/attachment.cgi?id=225478

Comment 16

[bblack]

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.

Comment 17

[Tony Mechelynck [:tonymec]]

(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.

Comment 18

[Frank-Rainer Grahl (:frg)]

Attachment: 1234651-medianoscripts.patch

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.

Comment 19

[Ian Neal]

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

Comment 20

[Frank-Rainer Grahl (:frg)]

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.

Comment 21

[Ian Neal]

(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

Comment 22

[Frank-Rainer Grahl (:frg)]

Attachment: 1234651-medianoscripts-52.patch

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.

Comment 23

[Ian Neal]

Comment on attachment 9070809 [details] [diff] [review]
1234651-medianoscripts-52.patch

a=me

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/276536b6d831
Check view targets for possible unsafe content. r=IanN

Comment 25

[Frank-Rainer Grahl (:frg)]

Target 2.49.5
https://hg.mozilla.org/releases/comm-esr52/rev/32ca9eea4f9bcdc7c0ab7b95c4a3358f6ef8d33a

https://hg.mozilla.org/releases/comm-esr60/rev/ee0685ffa4a060f17bb51b054e52d49f60ef7abd

Comment 26

[Yassine ABOUKIR]

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

Comment 27

[Frank-Rainer Grahl (:frg)]

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?

Comment 28

[Ian Neal]

(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.

Comment 29

[Dmitry Butskoy (:buc)]

Clicking "View Image" on a Canvas (which probably the same time is a frame) produces an error:

Error: TypeError: Argument 1 is not valid for any of the 1-argument overloads of URL.createObjectURL.
Source File: chrome://communicator/content/nsContextMenu.js
Line: 1127

The problem is
let blobUrl = URL.createObjectURL(this.target);
because the argument must be this.target.toBlob(), rather then just this.target .
(And toBlob() canvas method is async).

Note, the correspond Fx part has toBlob()

Comment 30

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.4-view_media_canvas.patch

preliminary patch which fixes the issue on known test cases.

Comment 31

[Frank-Rainer Grahl (:frg)]

Dmitry could you open a new bug and attach the patch to it. Looks ok but I need to do some tests and would like to have it seperated.

Comment 32

[Dmitry Butskoy (:buc)]

See bug #1667600 for canvas issue

Comment 33

[Yassine ABOUKIR]

Hi - apologies for the little nudge! I was wondering if it would be possible to request a CVE for this security issue?

Comment 34

[Frank-Rainer Grahl (:frg)]

I was wondering if it would be possible to request a CVE for this security issue?
We talked about it yesterday. We know it was not handled in time but think given the even older underlying bugs and the now completely obsolete 2.49.5 release that it makes little sense now to create a new CVE. Basically yesterdays news.

Comment 35

[Yassine ABOUKIR]

Sounds good! Please update this ticket with the appropriate CVE ID when it's assigned. Thanks!