819251 - self-xss Vulnerability on ci.mozilla.org

Status: RESOLVED FIXED

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

Description

[atulkumar hariba shedage]

Attachment: final

myself atul,
found another cross site scripting vulnerability on your subdomain
here's report
domain : mozilla.org
infected subdomain : ci.mozilla.org
tested browser : mozilla,chrome,IE
vulnerability : DOM XSS
proof : check attachment or go with description

Description :

step 1) goto https://ci.mozilla.org/

step 2) in search type "><img src=x onerror=prompt(navigator.userAgent);>

step 3) vector will get execute

let me is it valid bug for bounty or not

Thank You,

Comment 1

[Reed Loden [:reed]]

I can confirm this on https://ci.jenkins-ci.org/, so marking as such and assigning to Kohsuke Kawaguchi. I'll also be filing this upstream as well.

Comment 2

[Reed Loden [:reed]]

Issue reported upstream to Jenkins:
https://issues.jenkins-ci.org/browse/SECURITY-46

Comment 3

[Reed Loden [:reed]]

Atul, how would you like to be credited in any potential advisory that Jenkins releases?

Comment 4

[atulkumar hariba shedage]

Thanks For Confirmation

i would like to be credited by my name
as 
Atulkumar Hariba Shedage

btw any bounty for these issue?

Comment 5

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

(In reply to atulkumar hariba shedage from comment #4)
> Thanks For Confirmation
> 
> i would like to be credited by my name
> as 
> Atulkumar Hariba Shedage
> 
> btw any bounty for these issue?

This site is not officially in our list of eligible sites. This means we
have to decide if your bug is worth making an exception and potentially
setting a precedent.

We do appreciate learning about bugs in all of our sites. We publish a
list of eligible sites for people who are only interested in bounties
and we hope that can help reduce the frustration of wasting time in
unfruitful areas.
http://www.mozilla.org/security/bug-bounty-faq-webapp.html#eligible-bugs

Comment 6

[Daniel Veditz [:dveditz]]

Fox2mike: this site appears to take users LDAP login -- does anyone actually log in? At the very least an XSS in this site could steal that access.

In the past the externally accessible ci.mozilla.org could kick off builds and push them to servers but we were supposed to have stopped that practice, making the site purely infomational about site status (due to concerns about relying on Jenkins security). Is that still the case?

Comment 7

[Shyam Mani [:fox2mike]]

Yes. All the logins to the site are LDAP based. Webops are now in charge of this service, I'll CC them on this bug.

Comment 8

[Jake Maul [:jakem]]

No Mozilla sites auto-deploy from Jenkins... I don't recall when, if ever, that any sites did. One site does deploy from Jenkins, but not automatically- it's a manual process that merely fetches a generated tarball from ci.mozilla.org.

I don't have access to the upstream bug report... is there a workaround or patch that can be deployed, or an ETA when one will be available? In other words, is there anything immediately actionable here for us (Mozilla/WebOps)?

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Shyam Mani [:fox2mike] from comment #7)
> Yes. All the logins to the site are LDAP based. Webops are now in charge of
> this service, I'll CC them on this bug.

"LDAP-based" says how the server authenticates but not how it's presented on the client side. The site has a login form at https://ci.mozilla.org/login -- is that what's used? If so then an XSS on this site can potentially steal LDAP credentials from Mozilla personnel. That alone, no matter how unprivileged this particular site may be, makes this a bad bug. (Using HTTP auth would make such an attack harder.) Another victory for all-your-eggs-in-one-basket LDAP auth.

We do appear to use HTTPOnly cookies so the XSS can't steal the session cookie, but the LDAP credentials are a bigger prize anyway. Could get those by convincing a password manager to replay saved passwords into a hidden form, or simply "phish" for it (but on the legit site!) by telling the user the session timed out and they need to re-enter them in a form created by the attacker.

(In reply to Jake Maul [:jakem] from comment #8)
> No Mozilla sites auto-deploy from Jenkins... I don't recall when, if ever,
> that any sites did. One site does deploy from Jenkins, but not
> automatically- it's a manual process that merely fetches a generated tarball
> from ci.mozilla.org.

I may have chosen my words poorly (especially "auto"). Why is there an LDAP login? is it to see secret stuff that random web visitors aren't supposed to see, or can some logged-in users do stuff that affects what is built and deployed to any of our servers?

The site I was told used ci.m.o. before was Socorro.

Whichever site it is, is the process of fetching the tarball controlled from the Jenkins end or is it a pull initiated on the other site's end (or from some 3rd server)? If the process is initiated from ci.m.o. then an XSS on this site has value to an attacker apart from the LDAP login stealing mentioned above. Even if it's initiated from a different server, if the build is configured from ci.m.o there may be options that could be set to make the installation vulnerable. At the very least perhaps building from an older source revision that contains a known/fixed vulnerability.

> I don't have access to the upstream bug report... is there a workaround or
> patch that can be deployed, or an ETA when one will be available?

Reed: any answer for the above?

> in other words, is there anything immediately actionable here for
> us (Mozilla/WebOps)?

You could throw the whole site behind LDAP http auth and control the access to the server that way, or put it on the intranet and require VPN to access. I'm guessing those won't fly.

You could make the public site strictly report-only (which I thought was the fix the last time we had ci.m.o security issues) and create an internal jenkins for anything that actually requires a login to perform.

Comment 10

[Jake Maul [:jakem]]

(In reply to Daniel Veditz [:dveditz] from comment #9)
> (In reply to Shyam Mani [:fox2mike] from comment #7)
> > Yes. All the logins to the site are LDAP based. Webops are now in charge of
> > this service, I'll CC them on this bug.
> 
> "LDAP-based" says how the server authenticates but not how it's presented on
> the client side. The site has a login form at https://ci.mozilla.org/login
> -- is that what's used?

Yes.

> If so then an XSS on this site can potentially steal
> LDAP credentials from Mozilla personnel. That alone, no matter how
> unprivileged this particular site may be, makes this a bad bug. (Using HTTP
> auth would make such an attack harder.)

Might be feasible, dunno offhand.

> Another victory for
> all-your-eggs-in-one-basket LDAP auth.

If you have a better centralized auth system that doesn't have this problem, I'm sure folks would love to hear about it. :)

> We do appear to use HTTPOnly cookies so the XSS can't steal the session
> cookie, but the LDAP credentials are a bigger prize anyway. Could get those
> by convincing a password manager to replay saved passwords into a hidden
> form, or simply "phish" for it (but on the legit site!) by telling the user
> the session timed out and they need to re-enter them in a form created by
> the attacker.
> 
> (In reply to Jake Maul [:jakem] from comment #8)
> > No Mozilla sites auto-deploy from Jenkins... I don't recall when, if ever,
> > that any sites did. One site does deploy from Jenkins, but not
> > automatically- it's a manual process that merely fetches a generated tarball
> > from ci.mozilla.org.
> 
> I may have chosen my words poorly (especially "auto"). Why is there an LDAP
> login? is it to see secret stuff that random web visitors aren't supposed to
> see, or can some logged-in users do stuff that affects what is built and
> deployed to any of our servers?

It's mainly for administrative control over what's in Jenkins, I believe. It's not merely a reporting interface, but also a configuration one. Having an account (with the right privileges tied to it) gives you the ability to create new tests/projects, change settings, etc.

> The site I was told used ci.m.o. before was Socorro.

Yep. It's a manual process, but uses a jenkins-built tarball.

> Whichever site it is, is the process of fetching the tarball controlled from
> the Jenkins end or is it a pull initiated on the other site's end (or from
> some 3rd server)?

Initiated by fetching the content from Jenkins... *not* pushed by Jenkins. I believe it's just a simple wget, but I could be wrong. In any case, it's definitely invoked by running a shell script on a different server, and not from within Jenkins.

> > in other words, is there anything immediately actionable here for
> > us (Mozilla/WebOps)?
> 
> You could throw the whole site behind LDAP http auth and control the access
> to the server that way, or put it on the intranet and require VPN to access.
> I'm guessing those won't fly.

Don't know offhand. I agree- either seems likely to cause a bit of a stir.

> You could make the public site strictly report-only (which I thought was the
> fix the last time we had ci.m.o security issues) and create an internal
> jenkins for anything that actually requires a login to perform.

Don't know offhand how that could be done, but it would also complicate the setup. I can't easily say for certain how much would be involved here. As a snap judgement, I'd guess that simply layering on HTTP Auth would be easier.

Comment 11

[Shyam Mani [:fox2mike]]

Daniel, if you need any specific answers, feel free to let me know. I think Jake has covered all of it.

It's public because that's how we roll. It's auth based because we don't want anyone and everyone to be able to trigger builds and install plugins and reboot jenkins. It's LDAP because that's an easy way to restrict access to the company and hence trusted people vs having to hand a password off to people.

Comment 12

[Reed Loden [:reed]]

Proposed patch from upstream (not yet reviewed or committed):

diff --git a/war/src/main/webapp/scripts/hudson-behavior.js b/war/src/main/webapp/scripts/hudson-behavior.js
index 518c5b8..69de248 100644
--- a/war/src/main/webapp/scripts/hudson-behavior.js
+++ b/war/src/main/webapp/scripts/hudson-behavior.js
@@ -1647,7 +1647,7 @@ function createSearchBox(searchURL) {
     function updatePos() {
         function max(a,b) { if(a>b) return a; else return b; }
 
-        sizer.innerHTML = box.value;
+        sizer.innerHTML = box.value.escapeHTML();
         var w = max(sizer.offsetWidth,minW.offsetWidth);
         box.style.width =
         comp.style.width =

Comment 13

[Daniel Veditz [:dveditz]]

(In reply to Shyam Mani [:fox2mike] from comment #11)
> It's public because that's how we roll. It's auth based because we don't
> want anyone and everyone to be able to trigger builds and install plugins
> and reboot jenkins.

Sure.

> It's LDAP because that's an easy way to restrict access to the company
> and hence trusted people vs having to hand a password off to people.

I'm not complaining about LDAP so much as the risks of putting a form in a web page. HTTP Auth over SSL is immune to XSS. Forms can get hacked or phished. Persona is another way to go.

If the site itself is a high value target then this is a minor blip, but with a site like ci.m.o the LDAP login form is practically the main target.

This particular bug appears to be a self-xss -- I don't see any way to get a payload delivered to a victim. (We did fix an earlier bug about search results, but don't currently know of a way.) Does not qualify for a bug bounty.

Comment 14

[atulkumar hariba shedage]

Thanks you sir,
it's my 2nd bad luck for bounty,
But i continued my research last night, and was thinking  how if we force the user to execute vector on there own machine (as it's self xss)

i was gone through some techniques and found that the URL (site) https://ci.mozilla.org/
is vulnerable for clickjacking attack.
as site loaded in iframe,

to explain these attack in best way i made one code drag and drop
which we can add code in hidden field and execute that on client side

my code

<html>
<body>
<span draggable="true" ondragstart="event.dataTransfer.setData('text/plain', '<img src=a.png onerror=prompt(navigator.userAgent);>');dragIt(this, event)"><h1>DRAG ME!!!</h1></span>
<iframe ondragenter="return dragEnter(event)" ondrop="return dragDrop(event)" ondragover="return dragOver(event)" sandbox="allow-scripts allow-forms" src="https://ci.mozilla.org/"style="width:100%;height:100%;opacity:0.5"></iframe>
</body>
</html>

i set opacity to 0.5

i attached one image file plz check it
tested on mozilla lattest version (browser)
in honestly these clickjacking issue just execute vector , but if it comes to generate cookie from iframe it wont work,

atleast you can patch these clickjacking issue by adding iframe option

thank you for all response :)

Comment 15

[atulkumar hariba shedage]

Attachment: clickjacking new

clickjacking

Comment 16

[Reed Loden [:reed]]

This was resolved upstream in Jenkins 1.502 and Jenkins LTS 1.480.3.

https://github.com/jenkinsci/jenkins/commit/f8d2a0ba6c2e261f48287bdd95bd7a2d7a8d2d0e
https://github.com/jenkinsci/jenkins/commit/4c52ddfe14cd75b66f03eda9e0b2004e9d5735d7

Comment 17

[Reed Loden [:reed]]

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-02-16

Comment 18

[atulkumar hariba shedage]

Really osm to see it's fixed ,
as no bounty atleast give me acknowledge :(

Comment 19

[Reed Loden [:reed]]

(In reply to atulkumar hariba shedage from comment #18)
> Really osm to see it's fixed ,
> as no bounty atleast give me acknowledge :(

I agree.

Kohsuke, why do you not include acknowledgement of the reporters in your security advisories? It's the least you can do for people who report security issues responsibly. :/

Comment 20

[atulkumar hariba shedage]

any update?

Comment 22

[David Chan [:dchan]]

According to https://ci.mozilla.org/api/?
We are still on v1.480.2

I don't think this issue is resolved unless we cherrypicked the patches

Comment 23

[Reed Loden [:reed]]

The upstream issue is fixed, which means this issue is fixed (as the code has been committed). Please file a separate server-ops bug to get the Mozilla version upgraded.

Comment 24

[Daniel Veditz [:dveditz]]

(In reply to Reed Loden [:reed] from comment #23)
> The upstream issue is fixed, which means this issue is fixed

Huh? Does that mean we can take all the "Site X is running vulnerable version of Upstream Y" bugs and immediately close them since the fix exists, just not deployed on our servers?

This was a bug saying Mozilla's CI server is vulnerable, and shouldn't be fixed until mozilla's server is not vulnerable (it can "depend on" a server push bug if necessary). Presumably an upstream bug was filed that tracked the upstream fix; this is not the Jenkins Github issues database.

Comment 25

[Reed Loden [:reed]]

Please stop reopening this bug. If you need a bug to reopen, go reopen bug 799802 or bug 845473. It has never been policy to keep a code bug open after a fix has been committed.

Comment 26

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

I don't think this is fixed, we had a new, reproducable report of this to sec@ today:
From: Muhammad Waqar <[e-mail]>
To: Mozilla Security <[e-mail]>
Subject: RE: Vulnerability Report.
Date: Mon, 8 Apr 2013 18:32:06 +0500
-----//-----
Hi Curtis,

Thank you for your email and the payload is still executing there please check it again place a vector in a search bar 

#"><img src=x onerror=prompt(/DiscoveredByMuhammadWaqar/);> and press enter you can see that its still working i have created a video Proof of concept video and uploaded on my dropbox account you can see it copy and paste the link in your browser to see via online or download it.

Dropbox Video Link below:

https://www.dropbox.com/s/9qcwfwsll2lyrbf/Mozilla%20POC%20.wmv

Regards,
Muhammad Waqar
C)ISSO,C)PTE,CEH

Comment 27

[Reed Loden [:reed]]

See comment #25. Please stop reopening this bug.