-
Bug
-
Resolution: Fixed
-
Highest (View bug fix roadmap)
-
8.6.0, 8.8.0, 8.5.5, 8.9.0, 8.10.0, 8.11.0
-
8.05
-
271
-
Severity 2 - Major
-
567
-
Summary
Affected versions of Atlassian Jira Server and Data Center allow remote, unauthenticated attackers to view custom field names and custom SLA names via an Information Disclosure vulnerability in the /secure/QueryComponent!Default.jspa endpoint.
Affected versions:
- version < 8.5.8
- 8.6.0 ≤ version < 8.11.1
Fixed versions:
- 8.5.8
- 8.11.1 and above, including 8.13.x
Note on fix
We've been unable to fully fix this issue due to short SLA and possible performance problems that fix could introduce. Please check the workaround section for mitigation steps.
Workaround - Fix Versions
To workaround this bug on Jira versions listed in "fixed in versions" above, one of the two techniques can be used:
- Add the dark feature "public.access.disabled" (see How to control anonymous user access in a public Jira instance)
- In the fix versions above, the endpoint will now return 401 for anonymous users.
- Add the newly added dark feature "com.atlassian.jira.plugin.issuenavigator.anonymousPreventCfData.enabled"
- 200 will be returned, however the output will filter out all custom fields from response only when not authenticated
The side effect of turning on "com.atlassian.jira.plugin.issuenavigator.anonymousPreventCfData.enabled" flag is that in basic mode of issue search (https://confluence.atlassian.com/jirasoftwareserver/basic-searching-939938708.html) there won't be any custom fields available for anonymous uses + there should be warning presented that "You’re not logged in, so you can’t use custom fields in basic search. Log in or switch to advanced search.".
Advanced mode should work fine (https://confluence.atlassian.com/jirasoftwareserver/advanced-searching-939938733.html).
Workaround - Non-fix versions
If you are running Jira that is below one of the "fixed in versions" above and should not be open to unauthenticated users, you may block the affected endpoint from anonymous users by using the URL rewrite system.
First, add the public.access.disabled dark feature as above. This blocks access to the Jira issue navigator when unauthenticated.
Then, on each node, block the QueryComponent endpoints:
- Edit the file JIRA_INSTALL/atlassian-jira/WEB-INF/urlrewrite.xml
- Insert a new rule, directly underneath the last </rule> line (but before the </urlrewrite> line):
<rule> <from>(?s)/QueryComponent!.*\.jspa</from> <condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition> <set type="status">403</set> <to>null</to> </rule> - Restart the node
If for whatever reason you have scripted basic authentication calls to these endpoints (EG, python/curl requests), they will all be blocked, authenticated or not.
- is related to
-
-
- Closed
-
-
-
- Closed
-
- is cloned by
-
MNSTR-4369 You do not have permission to view this issue
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[JRASERVER-71536] Sensitive data exposure via /secure/QueryComponent!Default.jspa endpoint - CVE-2020-14179
Hi everyone!
We have analyzed the issue, and this is how the endpoint behaves in currently supported versions (>= 9.4.0 LTS) and you can find our conclusions below.
Field visibility conditions
The following table illustrates how the field visibility and presence in the response is dependent on multiple factors:
| Field Context configuration | Instance configuration | Anonymous user | Logged-in user |
| CF without context assigned | All projects are private (no project on the instance is anonymously accessible) | Not visible | Not visible |
| CF without context assigned | Some projects are public (even one project on the instance is anonymously accessible) | Not visible | Not visible |
| CF with global context | All projects are private | Not visible | Visible |
| CF with global context | Some projects are public | Visible | Visible |
| CF with project context assigned only to non-public project | All projects are private | Not visible | Visible |
| CF with project context assigned only to non-public project | Some projects are public | Not visible | Visible |
| CF with project context assigned to public project | Some projects are public (no other option here) | Visible | Visible |
Project is public when it uses a permission scheme where Browse Projects permission is granted to 'Anyone on the web' group.
About the feature flags:
- public.access.disabled - works - FULLY DISABLES the endpoint in question for anonymous, but doesn’t affect logged-in users.
- com.atlassian.jira.plugin.issuenavigator.anonymousPreventCfData.enabled - has no effect since 8.14.0, 8.13.1, 8.5.10 when the newer fixes started to be implemented.
Related docs:
You can refer to https://confluence.atlassian.com/adminjiraserver/managing-project-permissions-938847145.html to read more about the project permissions or https://confluence.atlassian.com/adminjiraserver/configuring-custom-field-contexts-1047552717.html to check how to configure custom field contexts.
This affects a customer of ours as well. They are running Jira 9.12.7 and JSM 5.12.7
this is a public official reply:
Hello, @serkan_sezer , I see that we've delivered a fix for this CVE for a while now and we have no confirmation of sensitive information being disclosed through that vector.
One thing that I've see more than a couple times in the past weeks is when clients upgrade their Jira Software but their Jira Server Management is still not updated causing the Vulnerability check to trigger an alert.
If your team was able to reproduce any vulnerability, they can follow the Vulnerability Information steps https://www.atlassian.com/trust/security/vulnerability-information-report.
If you're still hesitating, it's better to lock down your private Jira instances by following the guide here:
- turn public sharing of dashboards and filters to OFF
- add public.access.disabled in site dark features /secure/SiteDarkFeatures!default.jspa
Please see Atlassian response about this security vulnerability. I have asked if my customer which has JSM 5.11.3 has effected. I found out that it is effected as well.
"We request you to see if you can see any data related to custom fields and custom field SLA names by accessing /JIRA BASE URL/secure/QueryComponent!Default.jspa end point.
Please open an InPrivate or Incognito browser window and hit this URL endpoint and see if you are able to view any data.
If you are able to view any data, you can apply steps mentioned in Workaround - Fix Versions section of the JRASERVER-71536."
Wow! I had to login to see this with my own eyes! A response from Atlassian more than 1 year later. And 4 years+ later from the original ticket creation date. Congratulations!
You should, maybe, change the data in the ticket, so it reflects the real world? Because still, after these 4 years I spoke about earlier, it states only version 8 is affected. How. Is. This. Possible?
I'm so happy you stopped supporting the Server version of this, because it gave us a way out, so thanks for that I guess.