JIRA 4.3 : JIRA Security Advisory 2008-08-26
This page last changed on Sep 14, 2010 by ggaskell.
In this advisory:
Security vulnerabilitiesXSS vulnerability in serving HTML attachments with the text/html MIME typeSeverityAtlassian rates this vulnerability as HIGH, according to the scale published in the JIRA Security documentation. This scale allows us to rank a vulnerability as critical, high, moderate or low. Risk AssessmentWe have identified and addressed a security vulnerability which may affect JIRA instances in a public environment. This is an XSS (cross-site scripting) vulnerability in JIRA's service of HTML attachments (or other active content, such as Javascript, Flash, etc) with the text/html MIME type, which potentially allows a malicious user (attacker) to insert their own HTML tags or script into an action.
Atlassian recommends that you upgrade to JIRA 3.13 to fix the vulnerabilities described below. You can read more about XSS attacks at cgisecurity, CERT and other places on the web. Risk MitigationIf you judge it necessary, you can disable attachments or restrict public access (i.e. anonymous access and public signup) to your JIRA system until you have applied the necessary patch or upgrade. For even tighter control, you could restrict JIRA access to trusted groups only. VulnerabilityAny malicious script contained in an HTML attachment of with the text/html MIME type will be run as JIRA serves the attachment, i.e. when an admin or user clicks on the uploaded HTML attachment. FixThe fix is to add an administration option to force all attachments in JIRA to be downloaded rather than displayed inline. Administrators can choose from the following:
Read the documentation for further details on configuring this setting. This issue has been fixed in JIRA 3.13 only. There are no patches available for previous versions of JIRA, for this fix.
MailHandlers may create an infinite loop if the monitored mailbox receives notifications from the same instance of JIRASeverityAtlassian rates this vulnerability as MEDIUM, according to the scale published in the JIRA Security documentation. This scale allows us to rank a vulnerability as critical, high, moderate or low. Risk AssessmentWe have identified and fixed a security flaw which may affect JIRA instances in a public environment. This flaw means that mailhandlers can potentially cause infinite loops if the monitored mailbox receives notifications from the same JIRA instance. Atlassian recommends that you upgrade to JIRA 3.13 to fix the vulnerability described below. Risk MitigationIf you judge it necessary, you can disable disable your mail servers or disable public access (i.e. anonymous access and public signup) to your JIRA system until you have applied the necessary patch or upgrade. VulnerabilityUser sends an email to a JIRA mailbox, where the From and To address are the same, e.g. if an email is sent to a mailbox monitored by JIRA with a 'From' email address identical to the mailbox address it is being sent to, then JIRA will pick up the email again and start an infinite loop for that issue. FixThe fix is to add a header to the outgoing email that contains a special JIRA "fingerprint" (X-JIRA-FINGERPRINT) that is unique to the JIRA instance. This issue has been fixed in JIRA 3.13 only. There are no patches available for previous versions of JIRA, for this fix. Directory listings are enabled on Tomcat by defaultSeverityAtlassian rates this vulnerability as LOW, according to the scale published in the JIRA Security documentation. This scale allows us to rank a vulnerability as critical, high, moderate or low. Risk AssessmentWe have identified and addressed a security flaw which may affect JIRA instances in a public environment. This flaw means that directory listings on the Tomcat application server are public by default. Atlassian recommends that you upgrade to JIRA 3.13 to fix the vulnerability described below. Alternatively, you can manually disable the directory listing (via the <TOMCAT_HOME>/conf/web.xml file in Tomcat directory), which will force JIRA to throw HTTP 404 errors appropriately. Risk MitigationIf you judge it necessary, you can disable public access (i.e. anonymous access and public signup) to your JIRA system until you have applied the necessary patch or upgrade. VulnerabilityUsers can browse the directory listing on the Tomcat application server, e.g. /images/. Please note, the information accessible by the user is already readily available to the user, or can be obtained by downloading JIRA. The webapp directories do not contain any user content. FixThe fix is to disable directory listings in Tomcat. Please refer to JRA-11634 for details. The directory listings are disabled by default in Tomcat 5.5.26. This version is bundled with the latest version of JIRA. This issue has been fixed in JIRA 3.13 for JIRA Standalone and for the sample Tomcat (i.e. versions 4.1, 5.0, 5.5 and 6.0) configuration files shipped with JIRA WAR/EAR. There are no patches available for previous versions of JIRA, for this fix. Filters/Search Requests can be modified by URL HackingSeverityAtlassian rates this vulnerability as MODERATE, according to the scale published in the JIRA Security documentation. This scale allows us to rank a vulnerability as critical, high, moderate or low. Risk AssessmentWe have identified and addressed a security flaw which may affect JIRA instances in a public environment. This flaw means that issue filters can be modified by hacking the URL, regardless of permissions on the filter. Atlassian recommends that you upgrade to JIRA 3.13 to fix the vulnerability described below. Risk MitigationIf you judge it necessary, you can disable public access (i.e. anonymous access and public signup) to your JIRA system until you have applied the necessary patch or upgrade. VulnerabilityUsers can run an issue filter, which they do not have access to, by entering the appropriate URL (although the filter will not return any issues that the user does not have permission to see). By the same means, users can edit a filter, rename a filter and access share and column selection. Filter deletion cannot be actioned purely by the URL, as it requires interaction with the user interface (which enforces permissions). FixThe fix is to revise the issue filter functionality as part of the Shareable Filters feature, so that URL hacks are no longer valid. This issue has been fixed in JIRA 3.13 only. There are no patches available for previous versions of JIRA, for this fix. 'Manage Project Role Membership for Project' page can be viewed publiclySeverityAtlassian rates this vulnerability as LOW, according to the scale published in the JIRA Security documentation. This scale allows us to rank a vulnerability as critical, high, moderate or low. Risk AssessmentWe have identified and addressed a security flaw which may affect JIRA instances in a public environment. This flaw means that the 'Manage Project Role Membership for Project' page can be viewed by users who are not logged in. Users cannot view any project role members or modify project roles. Atlassian recommends that you upgrade to JIRA 3.13 to fix the vulnerability described below. Risk MitigationIf you judge it necessary, you can disable public access (i.e. anonymous access and public signup) to your JIRA system until you have applied the necessary patch or upgrade. VulnerabilityUsers, who are not logged in, can manually enter the URL for the 'Manage Project Role Membership for Project' to access the page. Project role members will not be visible, nor will the user be able to modify project roles. The only new information available to the user will be the project name. FixThe fix is to prompt the user with the appropriate page for unauthorised access, if they are not logged in. This issue has been fixed in JIRA 3.13 only. There are no patches available for previous versions of JIRA, for this fix. Please let us know what you think of the format of this security advisory and the information we have provided. |
![]() |
Document generated by Confluence on Mar 27, 2011 18:48 |