User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Build Identifier: If bugzilla.mozilla.org runs into in internal error it dumps out a notice to send the requested url to an admin. This is done using a line of javascript: document.write("<p>URL: " + document.location + "</p>") Since Internet Explorer and some other browsers do not force proper URL encoding you can easily force an error and inject arbitrary javascript code: https://bugzilla.mozilla.org/attachment.cgi? id=&action=force_internal_error<script>alert(document.cookie)</script> Bugzilla does not understand the action parameter, raises an internal error and this leads to an XSS. This can be used to steal the session cookie or fake content on the website. Mozilla/Firefox users seem to be not vulnerable since the browser automaticly converts < into %3C before sending the request. Reproducible: Always Steps to Reproduce: Just open the link in Internet Explorer or create a page like this: <script language="javascript" type="text/javascript"> location = 'https://bugzilla.mozilla.org/attachment.cgi? id=&action=force_internal_error<script>alert(document.cookie)<\/script>' </script>

-> Bugzilla

Here's the link, unbroken, for reference: https://bugzilla.mozilla.org/attachment.cgi?id=&action=force_internal_error<script>alert(document.cookie)</script> And Landfill links for testing: http://landfill.bugzilla.org/bugzilla-tip/attachment.cgi?id=&action=force_internal_error<script>alert(document.cookie)</script> http://landfill.bugzilla.org/bugzilla-2.18-branch/attachment.cgi?id=&action=force_internal_error<script>alert(document.cookie)</script> http://landfill.bugzilla.org/bugzilla-2.16-branch/attachment.cgi?id=&action=force_internal_error<script>alert(document.cookie)</script>

Good catch, Michael. This was, I believe, my mistake. :-( Gerv

To fix this we have two options: A -> ditch the URL thing. B -> implement HTML filtering in Javascript. Any preference towards one or another? I can upload a patch that implements option A :-)

Option 3 is to take a short cut and use escape(), which means the URL will be mangled but also both safe and easily decodable. E.g. http://bugzilla.mozilla.org/enter_bug.cgi?<script>alert('foo');</script> -> http%3A%2F%2Fbugzilla.mozilla.org%2Fenter_bug.cgi%3F%3Cscript%3Ealert('foo')%3B%3C%2Fscript%3E Gerv

Comment on attachment 168286 [details] [diff] [review] v1 - option C escape() is not UTF-8 safe and is deprecated for that reason. Use encodeURI() instead.

Comment on attachment 168288 [details] [diff] [review] v1 - option A If we go this route, we need to also ask the user to include the URL from the URL bar in their email.

encodeURI requires IE 5.5 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jsmthfencodeuri.asp) and I'm fairly sure it's not supported in Netscape 4. Given that it's not absolutely totally vital that it's lossless, and encode() works everywhere and correctly for 99.9% of cases, isn't that the right choice for the 2.18 branch? Gerv

escape() is not UTF-8 safe and encodeURI requires IE 5.5. Why not escaping < and > only using their equivalent %3C and %3E respectively? I think there is no need to escape the whole URL.

If we did that, we would just use &lt; and &gt; and &amp, I think. But yes, that's another option. Gerv

I found 3 files having document.location in a JS script: Error.pm line 121 code-error.html.tmpl line 259 quicksearch.js line 56 I think we should take care of all of them. I tried a simple document.location.replace(/</g,"%3C").replace(/>/g,"%3E"); but this does not work as "<" in the URL seems to induce some strange behavior. :(

On next tuesday this vulnerability will be made public with 170 other flaws as part of a general paper on cross-site scripting. There will be no detailed description, only a proof-of-concept URL. Just to let you know beforehand.

This has been allocated CVE name CAN-2004-1061. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1061 This is currently not visible since the flaw is not yet public. Please include this link in the future security announcement.

(In reply to comment #13) > I tried a simple > document.location.replace(/</g,"%3C").replace(/>/g,"%3E"); > but this does not work as "<" in the URL seems to induce some strange behavior. :( What kind of strange behavior?

The problem is that he did document.location.replace(), which is a function which redirects the browser, not document.location.href.replace(), which will substitute characters in the URL ;-) Patch coming right up. Gerv

pfff... only missing .href ! :( I thought I could fix my first security bug... Well, later maybe... ;)

This patches the instances in code-error.html.tmpl and Error.pm. The use of document.location.href in quicksearch.js doesn't print the location to the page and so is not a problem. I've taken the approach of using HTML entities so the page still renders the exact URL that the user used. On Linux, Konqueror is a good browser for testing this fix, because like IE it doesn't enforce correct URL encoding. Gerv

vladd: I just realised I took this bug without thinking. Please don't be offended :-) Gerv

does this patch apply cleanly to all three branches? /me doubts it works in 2.16, since 2.16 didn't have Error.pm

Untested backport to 2.16.7, which hopefully applies to the branch. Different placement of </p> (on next line), and slightly different indentation (document.location.href should be on the same level as the quotes, I'd say).

Comment on attachment 168868 [details] [diff] [review] 2.16 backport (use patch -p1) r=gerv by inspection. Gerv

The following went out on 2004/12/23: Cross-Site Scripting - an industry-wide problem =============================================== In early december i started a series of tests to find Cross-Site Scripting (XSS) vulnerabilities. It quickly turned out that the majority of all major websites suffer some kind of XSS. This is a disclosure of 175 vulnerabilities at once. Enjoy the ride... Test scenario ============= A site was considered affected if it is possible to inject a javascript into the output page by making a browser GET or POST request to the webserver. As a proof-of-concept the script "alert(document.cookie)" got used. All tests were made on a fully patched WinXP SP2 machine and Internet Explorer 6. Most of the proof-of-concept links in this report will not work using another browser, mainly because in many cases i used javascript in styles which isn't supported by browsers like Firefox and because Firefox automaticly applies character encoding to a URL. I was just too lazy to test each issue cross-browser, so this doesn't mean automaticly that Internet Explorer is more vulnerable to XSS. Impact ====== In many cases XSS is reduced to the attack of stealing session cookies, but XSS can be used to do a lot more things. Using DOM manipulation you can change the target of a login form or fake one, change download links or simply insert your own content into a website. As part of mass-mailings this can be used for login data phishing, spreading of malware or distribution of false news that seem to come from a trustworthy source (which is an intresting option for daytraders on penny stocks for example). Don't forget that the injected script is running in the security context of the affected site. If you know who you are attacking and that the victim has the affected site in a special trusted zone it can be possible to execute "not safe for scripting" ActiveX controls - giving you more or less total control. In intranets and for extranet web applications this is a not so uncommon configuration. For sure XSS is nothing compared to a remote buffer overflow. But only because this "worst case scenario" is happening quite often these days, it does not mean XSS is not a security issue. XSS flaws are easy to find and spammers are always searching for new stuff. Finally for some sites on the list dedicated to security a XSS flaw is just an embarrassing thing ;) Affected sites ============== This list is reduced to the second-level domain for readability and posting size. This isn't always fair since sometimes a sub-domain is indepentend from the SLD. Please download the complete list of proof-of-concept links from http://www.mikx.de/xss.php. All webmasters were informed by an email and/or their website feedback forms during december, to give them a fair chance to react. Some of them replied really quick and patched the issue in a few hours, others (sadly a lot) never replied. If you are responsible for one of the affected sites and you have not been informed or are not able to reproduce the issue, please don't hesitate to contact me. The sites in the tests were picked at random from international and german major websites and/or sites related to security/computers. I just tested what came to my head - so there is no "hidden message": about.com, activestate.com, adobe.com, altavista.com, amazon.com, amd.com, annoyances.org, aol.com, apache.org, apple.com , archive.org, arcor.de, ask.com, ati.com, bahn.de, bitdefender.de, blizzard.com, blogdex.net, blogger.com, bloogz.com, ca.com, ccc.de, cdu.de, chip.de, ciao.de, cert.org, chillingeffects.org, cnn.com, comdirect.de, consors.de, csialliance.org, csu.de, dell.com, daypop.com, divx.com, dooyoo.de, doubleclick.com, download.com, easycredit.de, ebay.com, etrade.com, evite.com, excite.com, fedex.com, fimatex.de, flexwiki.com, fool.com, free-av.de, freshmeat.net, fsf.org, fujitsu.com, gamestar.de, gm.com, gmx.net, gnu.org, go.com, golem.de, google.com, groupee.com, gruene-partei.de, guenstiger.de, heise.de, hosting.com, hp.com, ibm.com, icq.com, idealo.de, imagemagick.org, infineon.com, informationsecurityireland.com, infospace.com, intel.com, itaa.org, izb.de, jamba.de , juno.com, kde.org, kelkoo.de, kerio.com, liberale.de, linspire.com, looksmart.com, lufthansa.com, lycos.com, macromedia.com, mandrakesoft.com, mayflower.de, mcafee.com, meetup.com, messagelabs.com, metacrawler.com, metadot.com, microsoft.com, mlb.com, mnogosearch.org, modblog.com, modssl.org, mozilla.org, mozillazine.org, msdn.com, msn.com, msnbc.com, nasa.gov, nationalgeographic.com, nba.com, netiq.com, nfl.com, netflix.com, netscape.com, nokia.com, novell.com, nytimes.com, onlinekosten.de, opencores.org, openssl.org, opera.com, oracle.com, paypal.com, pc-magazin.de, pcpowerplay.de, pcwelt.de, phpcenter.de, pmwiki.org, privacy.org, pro7.de, ptb.de, postgresql.org, quoka.de, reactos.com, real.com, redhat.com, redvsblue.com, riaa.com, rtl.de, ryanair.com, sans.org, sbroker.de, securityfocus.com, securityspace.com, shutterfly.com, slashdot.org, snocap.com, sony.com, sourceforge.net, sparkasse.de, spd.de, spreadfirefox.com, squid-cache.org, sqlite.org, staysafeonline.com, stern.de, strato.de, sun.com, suse.de, technorati.com, telekombusiness.de, theonion.com, tiscali.com, tomshardware.com, uci.edu , ups.com , upside.de, us-cert.gov, validome.org, varbusiness.com, vasoftware.com, viruslist.com, w3.org, web.de, worldofwarcraft.com, wsj.com, xoom.com, yahoo.com, yopi.de, zonelabs.com References ========== It turned out that in some cases third party software used on the websites are suffering a bug. Here the Common Vulnerabilities and Exposures (cve.mitre.org) names: CAN-2004-1059 mnogosearch (as used at www.redhat.com) CAN-2004-1061 bugzilla (as used at bugzilla.mozilla.org bug #272620) CAN-2004-1062 viewcvs (as used at cvs.apache.org) CAN-2004-1146 cvstrac (as used at cvs.openssl.org) http://www.slashcode.com/article.pl?sid=04/12/15/1540200 http://www.mnogosearch.com/winhistory.html Credits ======= I woud like to thank a few people for helping me out through the tests and working on fixing the issues as quickly as possible: Christoph "Locke" Wehrmann (for making me addicted to XSS) Mark J Cox (Red Hat Security Response Team) Daniel Bachfeld (heisec) Jamie McCarthy and Chris Nandor (slashcode) Alexander Barkov (mnogosearch) Microsoft Security Response Center Google Security Team Bugzilla Team Everybody who responded to my report mail :) Contact ======= Michael Krax <mikx@mikx.de> http://www.mikx.de/ Happy Holidays! mikx

Despite having a security fix available on 2004-12-16 for all 3 branches, we failed to do a release between then and the time when the security was made public, which was 7 days later. I modified that status whiteboard of this bug in order to indicate that someone needs to do an analysis of what happened and where we failed to release a security patch to the public in due time. If nobody else volunteers I'll investigate the issue when I'll find some free time.

Comment on attachment 168807 [details] [diff] [review] Patch for 2.18 and 2.19.1 (use patch -p0) Removing unneeded review.

Indeed. We suck. However, XSS is not arbitrary database manipulation, and if someone does get XSSed using this hole, they'll get an error message from Bugzilla they didn't expect, along with a big red suspicious-looking URL. I say we just put the afterburners on and release 2.18 proper, and 2.16.whatever, ASAP. Gerv

(In reply to comment #27) > However, XSS is not arbitrary database manipulation, and if > someone does get XSSed using this hole, they'll get an error message from > Bugzilla they didn't expect, along with a big red suspicious-looking URL. XSS can't be used to manipulate data server side (only indirect by e.g. stealing a session cookie width administrative rights) but the client output is totally under the attackers control: https://bugzilla.mozilla.org/attachment.cgi? id=&action=force_internal_error<script>s=String.fromCharCode(32);document.write ("<div"+s+"style='position:absolute;top:85px;left:0px;padding:30px;background- color:white;width:101%;height:100%;text-align:center;font-size:30px;font- family:arial;'>MOZILLA.ORG"+s+"GIVES"+s+"UP<br><br>USE"+s+"INTERNET"+s+"EXPLORER "+s+"INSTEAD</div>")</script> You could also include a way longer script from another webserver to fake whatever you want.

Michael: I am aware of what's possible with XSS. But you must admit that this is in a different league to e.g. "any Bugzilla user can trash the database". Please don't think I'm belittling this vulnerability. I wrote the code in our test suite which tests our templates for possible XSS vulnerabilities. I am taking this seriously. I hope "ASAP" will mean "in the next couple of days". I've already triaged the 2.18 buglist and reviewed all the patches I can. We have one outstanding bug of any size - bug 108870 - and I'm pushing to get that fixed. Gerv

(In reply to comment #29) > But you must admit that this is > in a different league to e.g. "any Bugzilla user can trash the database". Agreed, it's a minor security issue. Wasn't meant to offend you ;) I just get a lot of emails doubting that XSS is a securtiy issue at all these days...

(In reply to comment #25) > Despite having a security fix available on 2004-12-16 for all 3 branches, we > failed to do a release between then and the time when the security was made > public, which was 7 days later. What happened is pretty simple. We're SO FREAKING CLOSE to releasing a final 2.18 that releasing a 2.18rc4 just seemed stupid. In hindsight, since nobody had time to patch/review the last 2.18 blockers during that time period, we should have done it anyway, but we didn't. I did propose just making the patch available with the advisory instead of doing a full-scale release, but I got poopooed on that idea in IRC. That doesn't excuse it though, I should have ran with it anyway. Removing the security flag since this is now publicly disclosed. You may proceed with checkins, whether we're ready to release or not. The only reason to delay checkins is to prevent premature disclosure, and it's too late for that.

Checked in on trunk, 2.18 branch and 2.16 branch. Checking in template/en/default/global/code-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/code-error.html.tmpl,v <-- code-error.html.tmpl new revision: 1.43; previous revision: 1.42 done Checking in Bugzilla/Error.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Error.pm,v <-- Error.pm new revision: 1.9; previous revision: 1.8 done Checking in template/en/default/global/code-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/code-error.html.tmpl,v <-- code-error.html.tmpl new revision: 1.39.2.3; previous revision: 1.39.2.2 done Checking in Bugzilla/Error.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Error.pm,v <-- Error.pm new revision: 1.4.2.1; previous revision: 1.4 done Checking in CGI.pl; /cvsroot/mozilla/webtools/bugzilla/CGI.pl,v <-- CGI.pl new revision: 1.153.2.8; previous revision: 1.153.2.7 done Checking in template/en/default/global/code-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/code-error.html.tmpl,v <-- code-error.html.tmpl new revision: 1.4.2.2; previous revision: 1.4.2.1 done Gerv

Also of note is that I had a hard drive failure on my primary workstation the day before this was disclosed, and had limited access to email for 3 days before I got the workstation fixed. Life sucks sometimes.