779491 - Reflective XSS on https://wiki.mozilla.org

Status: RESOLVED WONTFIX

(Websites :: wiki.mozilla.org, defect)

Description

[Christian]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

There is a reflective XSS on https://wiki.mozilla.org.

Request to reproduce:

GET /Special:Search?search=999"onmousemove="alert(1) HTTP/1.1
Host: wiki.mozilla.org

Response (relevant part):

  <div id="breadcrumbs">
                    <a href="https://wiki.mozilla.org">Home</a>&nbsp;&raquo;&nbsp;<a href="https://wiki.mozilla.org/Special:Search?search=999"onmousemove="alert(1)"> Search: 999&quot;onmousemove=&quot;alert(1)</a>                </div>
                <h3 id="siteSub">From MozillaWiki</h3>
                <div id="contentSub"></div>

Comment 1

[David Chan [:dchan]]

Christian: I see the output properly escaped as " Is this the correct link

https://wiki.mozilla.org/Special:Search?search=999"onmousemove="alert(1)

Comment 3

[Reed Loden [:reed]]

This code is terrible...

http://viewvc.svn.mozilla.org/vc/projects/wikimo/trunk/skins/gmo.php?view=markup#l317

I can confirm this using `curl`.

I haven't looked super-carefully yet, but perhaps wenzel already fixed it in r100350 (bug 714540)... Really hard to tell.

Comment 4

[Christian]

I can confirm the issue is still existing at the time of writing.

Comment 5

[Daniel Veditz [:dveditz]]

you confirm it using curl, or do you actually see this in any modern browser? Browsers ought to be escaping the " in the request as %22 which is then how it's returned in about 9 different links. One of those, the logout link, looks like it would have escaped the quote correctly but the others may not have (will have to look at the curl output).

IIRC we've had other XSS bugs filed against wikimo (or media wiki generally, which is an upstream project) that only actually worked in curl and not browsers.

Still, we can't assume that future browsers will be brilliantly written and/or follow the specs so media wiki ought to be escaping the output regardless.

Comment 6

[Daniel Veditz [:dveditz]]

I'm rating this sec-low on the assumption that other current browsers aren't dumb, but we should probably check older IE at least to be sure.

Comment 7

[Christian]

I reproduced using curl. But I would follow your last statement, plus one might be able to design auto-submitting forms to that destination that encode these chars so that they actually lead to execution in a browser. Fact is, the application is vulnerable in the sense that it does not encode output properly in this case. So I would always recommend edit the code accordingly.

Btw, the response extract I provided should help to identify the spot. It is right below   <div id="breadcrumbs">.

Comment 8

[Christian]

Daniel: sec-low is fine with me if you think that is reasonable, but keep in mind that there are various ways to issue a browser redirect. I'm pretty sure a versed attacker would be able to encode everything so that it actually executes, I don't have the expertise (tried...) or the time to come up with a working browser poc though.

Comment 9

[Fred Wenzel [:wenzel]]

FWIW, IT should be able to tell if the revision from comment 3 was actually deployed. If not, I suggest deploying it, then double-checking if this bug persists.

Comment 10

[Raymond Forbes[:rforbes]]

ok, we are going to non-qual this as we just can't come up with a working exploit.  If anybody can come up with a proof of concept of this working in the future, we will be happy to qualify it as a bug to receive a bounty.

Comment 11

[Christian]

Attachment: showing js execution in browser

Just attached a video showing js execution due to this vulnerability in the browser. I've used Burp Suite pro for constructing an auto-submitting html form to the vulnerable location.

Admittedly, I do not yet understand why browsers behave like this, but I think it shows the possibility for an exploit.

Comment 12

[Al Billings [:abillings - ex-MoCo]]

(In reply to Christian from comment #11)

> Admittedly, I do not yet understand why browsers behave like this, but I
> think it shows the possibility for an exploit.

We need to see an exploit though. We can't see a working exploit, which is why this is non-qualified for a bounty.

Comment 13

[Matt Fuller :mfuller]

I have not checked this specifically for XSS, but regardless there should be more filtering happening than what actually is.

Here is output of a script I wrote to check common escaping issues: http://pastebin.mozilla.org/1863410

As you can see, quotes are not properly escaped in multiple locations and a > symbol is not escaped in occurrence 6.

Comment 14

[Christie Koehler [:ckoehler]]

Near as I can tell, this is gmo-skin specific and low-priority in terms of security. Due to limited resources, we're not addressing non-critical issues on deprecated themes. 

I suggest we close at as WONTFIX, unless there is a strong reason not to.

Comment 15

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Christie Koehler [:ckoehler] from comment #14)
> Near as I can tell, this is gmo-skin specific and low-priority in terms of
> security. Due to limited resources, we're not addressing non-critical issues
> on deprecated themes. 
> 
> I suggest we close at as WONTFIX, unless there is a strong reason not to.

I concur.