Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-71536

Sensitive data exposure via /secure/QueryComponent!Default.jspa endpoint - CVE-2020-14179

      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:

      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:

      1. Edit the file JIRA_INSTALL/atlassian-jira/WEB-INF/urlrewrite.xml
      2. 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>
        
      3. 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.

            [JRASERVER-71536] Sensitive data exposure via /secure/QueryComponent!Default.jspa endpoint - CVE-2020-14179

            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. 

            Jurgen de Bruijne added a comment - 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. 

            Filip Nowak added a comment - - edited

            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.

             

            Filip Nowak added a comment - - edited 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.  

            Do you have a plan to full fix ?

            Gonchik Tsymzhitov added a comment - Do you have a plan to full fix ?

            Affects 9.4.14

            Rob Shannon added a comment - Affects 9.4.14

            This affects a customer of ours as well. They are running Jira 9.12.7 and JSM 5.12.7

            Amr Hamza (Legacy) added a comment - This affects a customer of ours as well. They are running Jira 9.12.7 and JSM 5.12.7

            https://community.atlassian.com/t5/Jira-questions/Is-the-CVE-2020-14179-issue-still-present/qaq-p/2040859

             

            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:

            https://confluence.atlassian.com/jirakb/how-to-control-anonymous-user-access-in-a-public-jira-instance-975031479.html

            • turn public sharing of dashboards and filters to OFF
            • add public.access.disabled  in site dark features /secure/SiteDarkFeatures!default.jspa

             

            Savvas Radevic added a comment - https://community.atlassian.com/t5/Jira-questions/Is-the-CVE-2020-14179-issue-still-present/qaq-p/2040859   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: https://confluence.atlassian.com/jirakb/how-to-control-anonymous-user-access-in-a-public-jira-instance-975031479.html turn public sharing of dashboards and filters to OFF add public.access.disabled   in site dark features /secure/SiteDarkFeatures!default.jspa  

            This also affects 9.12.x LTS

            Savvas Radevic added a comment - This also affects 9.12.x LTS

            Fabian Dreweskracht added a comment - - edited

            Jira Software V9.4.18 also affected.

            Fabian Dreweskracht added a comment - - edited Jira Software V9.4.18 also affected.

            "Cloud also affected since 01/2023"
            Yikes.

            Austin Hardy added a comment - "Cloud also affected since 01/2023" Yikes.

            Gulsum Kurtar added a comment - - edited

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

            Gulsum Kurtar added a comment - - edited 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 ."

              Unassigned Unassigned
              security-metrics-bot Security Metrics Bot
              Affected customers:
              12 This affects my team
              Watchers:
              109 Start watching this issue

                Created:
                Updated:
                Resolved: