272620 - XSS vulnerability in internal error messages

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect, P1)

Description

[Michael Krax]

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>

Comment 1

[Asa Dotzler [:asa]]

-> Bugzilla

Comment 2

[Dave Miller [:justdave]]

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>

Comment 3

[Gervase Markham [:gerv]]

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

Gerv

Comment 4

[Vlad Dascalu]

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

Comment 5

[Gervase Markham [:gerv]]

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 6

[Vlad Dascalu]

Attachment: v1 - option C

Comment 7

[Vlad Dascalu]

Attachment: v1 - option A

Comment 8

[Dave Miller [:justdave]]

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 9

[Dave Miller [:justdave]]

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.

Comment 10

[Gervase Markham [:gerv]]

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

Comment 11

[Frédéric Buclin]

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.

Comment 12

[Gervase Markham [:gerv]]

If we did that, we would just use < and > and &amp, I think. But yes,
that's another option. 

Gerv

Comment 13

[Frédéric Buclin]

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

Comment 14

[Michael Krax]

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.

Comment 15

[David Lawrence [:dkl]]

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.

Comment 16

[Dave Miller [:justdave]]

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

Comment 17

[Gervase Markham [:gerv]]

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

Comment 18

[Frédéric Buclin]

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

Comment 19

[Gervase Markham [:gerv]]

Attachment: Patch for 2.18 and 2.19.1 (use patch -p0)

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

Comment 20

[Gervase Markham [:gerv]]

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

Gerv

Comment 21

[Dave Miller [:justdave]]

does this patch apply cleanly to all three branches?

/me doubts it works in 2.16, since 2.16 didn't have Error.pm

Comment 22

[Marc Schumann [:Wurblzap]]

Attachment: 2.16 backport (use patch -p1)

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 23

[Gervase Markham [:gerv]]

Comment on attachment 168868 [details] [diff] [review]
2.16 backport (use patch -p1)

r=gerv by inspection.

Gerv

Comment 24

[Vlad Dascalu]

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 <[e-mail]>
http://www.mikx.de/


Happy Holidays!
mikx

Comment 25

[Vlad Dascalu]

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 26

[Gervase Markham [:gerv]]

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

Removing unneeded review.

Comment 27

[Gervase Markham [:gerv]]

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

Comment 28

[Michael Krax]

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

Comment 29

[Gervase Markham [:gerv]]

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

Comment 30

[Michael Krax]

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

Comment 31

[Dave Miller [:justdave]]

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

Comment 32

[Gervase Markham [:gerv]]

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

Comment 33

[Dave Miller [:justdave]]

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.

Comment 35

[vicrtim]

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

ok