956414 - DOM XSS @ secure.pub.build.mozilla.org

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Haris]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)

Steps to reproduce:

DOM XSS @ secure.pub.build.mozilla.org

DOM XSS
https://secure.pub.build.mozilla.org/builddata/reports/slave_health/slave.html

Script code from document.location query part was executed via DOM manipulation by innerHTML or outerHTML properties.

Mercurial repository found
Mercurial files found at : /builddata/reports/slave_health/.hg/requires



Actual results:

DOM XSS
https://secure.pub.build.mozilla.org/builddata/reports/slave_health/slave.html

Script code from document.location query part was executed via DOM manipulation by innerHTML or outerHTML properties.

Mercurial repository found
Mercurial files found at : /builddata/reports/slave_health/.hg/requires

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

assigned to dchan for verif

Comment 2

[David Chan [:dchan]]

class, type and name are pulled from the URL then inserted into jQuery .html() calls. This results in the DOM XSS as reported in comment 0. There are multiple unsafe DOM manipulations which need to be fixed.

See URL for alerts
https://secure.pub.build.mozilla.org/builddata/reports/slave_health/slave.html?class=%27%3E%3Cscript%3Ealert%283%29%3C/script%3E%3Ca&name=%3Cscript%3Ealert%282%29%3C/script%3E&type=%3Cscript%3Ealert%281%29%3C/script%3E

Comment 3

[Haris]

David,
Is this bug qualified for the bug bounty reward ?
Has anyone reported this before me ?

Comment 4

[Haris]

Adding another DOM XSS + Reflected XSS
It is a same CMS but another SubDomain.

https://bugzilla.mozilla.org/show_bug.cgi?id=956476

Comment 6

[Justin Wood (:Callek)]

moving to releng since this is a release engineering managed CMS -- also throwing CC list and needinfo ala Bug 956476

Comment 7

[Haris]

How much is the reward for this bug ?

Comment 8

[Simon Bennetts [:psiinon]]

This is determined by the bug bounty committee which meets regularly.
As you reported it you will be notified of the committee's decision via this bug.

Comment 9

[Chris Cooper [:coop] (he/him)]

https://hg.mozilla.org/users/coop_mozilla.com/slave_health/rev/ef89de66e684

Comment 10

[David Chan [:dchan]]

The encoder appears to do something funky when encountering single quotes.

https://secure.pub.build.mozilla.org/builddata/reports/slave_health/slave.html?class=%27abcd&name=%27efgh&type=%27ijkl

The resulting source contains the following elements
<a href="./slavetype.html?class=" abcd&type="ijkl">'ijkl</a></div>
<div id="bugicon"><span id="" efgh'="">

vs without single quote
<a href="./slavetype.html?class=abcd&amp;type=ijkl">ijkl</a>
<span id="efgh">

Note how abcd and efgh turn into attributes. It appears that HTML entities such as ", >, <, and = are encoded properly. This prevents something similar to
class == 'onmouseover=alert(1)
from working in the both cases.

I believe changing all the HTML string generation in the JS to use double-quotes instead of single quotes for values /should/ fix it. However I'm unfamiliar with this particular jquery library.

At present, the fix appears to solve the immediate threat of DOM XSS

Comment 11

[Haris]

So is this vulnerability eligible for money reward ?

Comment 12

[Haris]

Any information on reward ?
Last anwser was month ago.

Comment 13

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Haris from comment #12)
> Any information on reward ?
> Last anwser was month ago.

Haris, please don't set unnecessary flags or comments to the bug and please be patient as we do our work.

This bug is going to have to work it's way through the process. This site is not officially in our list of eligible sites. If the bug is extraordinary we sometimes offer bounties for interesting bugs which are outside of normal policy. Once an issue is confirmed it's up to the development team that is responsible for that site to prioritize the work. We won't normally make a bounty decision until the bug is fixed by that team. Depending on the work load for that team and work prioritization this can take a considerable amount of time.

Comment 14

[Haris]

Sorry for spam again, it is been 1 month since last info and 3 months since reporting, just wondering will there be any reward.

Regards

Comment 15

[Daniel Veditz [:dveditz]]

Coop: does comment 9 mean this bug is fixed? Was that check-in deployed? I'm going to assign this to you if you don't mind at least to check the status of this bug.

What does this system do? If an attacker used this XSS on a privileged user (are there any) could it steal private information, destroy things, make changes to our systems? Or are these read-only systems?

Comment 16

[Chris Cooper [:coop] (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #15)
> Coop: does comment 9 mean this bug is fixed? Was that check-in deployed? I'm
> going to assign this to you if you don't mind at least to check the status
> of this bug.
> 
> What does this system do? If an attacker used this XSS on a privileged user
> (are there any) could it steal private information, destroy things, make
> changes to our systems? Or are these read-only systems?

Yes, the fix was landed and deployed in early January. Sorry that wasn't clear.

The slave heath tool displays information about the status of build/test slaves in the releng environment. Releng and sheriffs need to be connected to the VPN *and* have LDAP access to the build network in order for any useful information to appear, i.e. the data sources/APIs the tool pulls from have access control in place. If an attacker gained access, they would simply see *more* data about the slaves: job history, reboot history, etc. This is all data that already appears on TBPL and elsewhere, just aggregated. The tool is also read-only; we don't affect or change the data at all using it.

Comment 17

[Haris]

Any info about reward ?

Comment 18

[Haris]

Info ?

Comment 19

[Daniel Veditz [:dveditz]]

Sorry, it was unclear that this was fixed and that triggers the bounty consideration. I do not understand the reluctance of the engineer to mark the bug fixed or to remain assigned.

(In reply to Chris Cooper [:coop] from comment #16)
> Releng and sheriffs need to be connected
> to the VPN *and* have LDAP access to the build network in order for any
> useful information to appear, i.e. the data sources/APIs the tool pulls from
> have access control in place.

Assume a targeted attacker knows who the sheriffs and releng folks are (not exactly private) and would attempt to attack them specifically.

> If an attacker gained access, they would
> simply see *more* data about the slaves: job history, reboot history, etc.
> This is all data that already appears on TBPL and elsewhere, just
> aggregated. The tool is also read-only; we don't affect or change the data
> at all using it.

If it's so benign why is it behind the VPN barrier?

For an authenticated user there appear to be "reboot" and "shutdown buildbot" buttons. Those would be annoying at least, though relatively minor.

Comment 20

[Ed Morley [:emorley]]

(In reply to Chris Cooper [:coop] from comment #16)
> Releng and sheriffs need to be connected
> to the VPN *and* have LDAP access to the build network in order for any
> useful information to appear

This isn't correct, I only need to authenticate using my LDAP credentials to see the additional machine stats & use the reboot/shutdown feature. VPN access is only required to access the buildbot masters themselves (or more specifically for the slave health page: to follow the links from the job result squares to the raw log on the master).

Comment 21

[Ed Morley [:emorley]]

Note it's also faily common for me to have accessed secure.pub.build.mozilla.org earlier in the day (via using the retrigger job functionality in TBPL), so I would likely not need to authenticate again upon clicking a slave_health page link.

That said, the attacks possible are pretty much only DOS afaict (reboot, shutdown, retriggering/cancelling build/test automation jobs via another service on secure.pub.build.mozilla.org).

Comment 22

[Chris Cooper [:coop] (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #19)
> (In reply to Chris Cooper [:coop] from comment #16)
> > Releng and sheriffs need to be connected
> > to the VPN *and* have LDAP access to the build network in order for any
> > useful information to appear, i.e. the data sources/APIs the tool pulls from
> > have access control in place.
> 
> Assume a targeted attacker knows who the sheriffs and releng folks are (not
> exactly private) and would attempt to attack them specifically.
> 
> > If an attacker gained access, they would
> > simply see *more* data about the slaves: job history, reboot history, etc.
> > This is all data that already appears on TBPL and elsewhere, just
> > aggregated. The tool is also read-only; we don't affect or change the data
> > at all using it.
> 
> If it's so benign why is it behind the VPN barrier?
> 
> For an authenticated user there appear to be "reboot" and "shutdown
> buildbot" buttons. Those would be annoying at least, though relatively minor.

Now that the reboot and shutdown actions have been added to slaveapi, this is less benign than before.

If the attacker already has LDAP access, they could be much more disruptive going after the slaveapi interface directly rather than this web layer that implements only a subset of its functions. An attacker could quite easily reboot and/or shutdown the entire pool of slaves.

Comment 23

[Daniel Veditz [:dveditz]]

This site is not on the list of sites eligible for a bounty, and since the maximum damage is denial of service (which is also normally not eligible) this bug does not meet the bar for a site exception.