XSS vulnerability in internal error messages

RESOLVED FIXED in Bugzilla 2.16



15 years ago
7 years ago


(Reporter: mikx, Assigned: gerv)


Bugzilla 2.16
Bug Flags:
approval +
blocking2.20 +
approval2.18 +
blocking2.18 +
approval2.16 +
blocking2.16.8 +


(Whiteboard: [ready for 2.16.8] [ready for 2.18] [ready for 2.20rc1])


(2 attachments, 2 obsolete attachments)

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:


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?
-> Bugzilla
Assignee: mozilla.webmaster → justdave
Group: security → webtools-security
Component: webmaster@mozilla.org → Bugzilla-General
Product: mozilla.org → Bugzilla
QA Contact: daniel.bugmail → mattyt-bugzilla
Version: other → 2.10
Here's the link, unbroken, for reference:

And Landfill links for testing:
Flags: blocking2.20+
Flags: blocking2.18+
Flags: blocking2.16.8+
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.16
Version: 2.10 → 2.17.6
Good catch, Michael. This was, I believe, my mistake. :-(

Ever confirmed: true
Whiteboard: bug awaiting patch
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.


Summary: XSS Vulnerability in Internal Error Messages → XSS vulnerability in internal error messages
Posted patch v1 - option C (obsolete) — Splinter Review
Assignee: justdave → vladd
Whiteboard: bug awaiting patch → patch awaiting review
Attachment #168286 - Flags: review?(gerv)
Posted patch v1 - option A (obsolete) — Splinter Review
Attachment #168288 - Flags: review?(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()
Attachment #168286 - Flags: review?(gerv) → review-
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.
Attachment #168288 - Flags: review?(gerv) → review-
encodeURI requires IE 5.5
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?

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.
Whiteboard: patch awaiting review → bug awaiting patch
If we did that, we would just use &lt; and &gt; and &amp, I think. But yes,
that's another option. 

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


This is currently not visible since the flaw is not yet public. Please include
this link in the future security announcement.
Priority: -- → P1
(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.

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.

Assignee: vladd → gerv
Attachment #168286 - Attachment is obsolete: true
Attachment #168288 - Attachment is obsolete: true
Attachment #168807 - Flags: review?(justdave)
vladd: I just realised I took this bug without thinking. Please don't be
offended :-)

Flags: approval?
Flags: approval2.18?
Flags: approval2.16?
Whiteboard: bug awaiting patch → patch awaiting review
Attachment #168807 - Flags: review?(myk)
Attachment #168807 - Flags: review?(justdave)
Attachment #168807 - Flags: review+
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).
Attachment #168868 - Flags: review?
Comment on attachment 168868 [details] [diff] [review]
2.16 backport (use patch -p1)

r=gerv by inspection.

Attachment #168868 - Flags: review? → review+
Whiteboard: patch awaiting review → [ready for 2.16.8] [ready for 2.18] [ready for 2.20rc1]
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.


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

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


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)

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)



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 :)


Michael Krax <mikx@mikx.de>

Happy Holidays!
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.
Whiteboard: [ready for 2.16.8] [ready for 2.18] [ready for 2.20rc1] → [ready for 2.16.8] [ready for 2.18] [ready for 2.20rc1] [BZ-security management analysis needed]
Comment on attachment 168807 [details] [diff] [review]
Patch for 2.18 and 2.19.1 (use patch -p0)

Removing unneeded review.
Attachment #168807 - Flags: review?(myk)
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.

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


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.

(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.
Group: webtools-security
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval2.16?
Flags: approval2.16+
Flags: approval+
Whiteboard: [ready for 2.16.8] [ready for 2.18] [ready for 2.20rc1] [BZ-security management analysis needed] → [ready for 2.16.8] [ready for 2.18] [ready for 2.20rc1]
Checked in on trunk, 2.18 branch and 2.16 branch.

Checking in template/en/default/global/code-error.html.tmpl;
 <--  code-error.html.tmpl
new revision: 1.43; previous revision: 1.42
Checking in Bugzilla/Error.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Error.pm,v  <--  Error.pm
new revision: 1.9; previous revision: 1.8

Checking in template/en/default/global/code-error.html.tmpl;
 <--  code-error.html.tmpl
new revision:; previous revision:
Checking in Bugzilla/Error.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Error.pm,v  <--  Error.pm
new revision:; previous revision: 1.4

Checking in CGI.pl;
/cvsroot/mozilla/webtools/bugzilla/CGI.pl,v  <--  CGI.pl
new revision:; previous revision:
Checking in template/en/default/global/code-error.html.tmpl;
 <--  code-error.html.tmpl
new revision:; previous revision:

Closed: 15 years ago
Resolution: --- → FIXED
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.
Attachment #168868 - Attachment description: 2.16 backport → 2.16 backport (use patch -p1)
Attachment #168807 - Attachment description: Patch v.1 - Option D ;-) → Patch for 2.18 and 2.19.1 (use patch -p0)
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.