Dear JIRA Administrator,

This was a discovery by an internal team, not an external report or a real incident in the wild. As you can see from the list of affected versions, this vulnerability existed for years. We do not have any indications of it ever having been exploited in the wild - it is a very complex issue. At the same time, a perfectly executed attack using this vulnerability would not leave any trace.

Regards,
Vitaly Osipov
Security Engineering

We have an onDemand service. Can you please tell me
1) how long this vulnerability existed in onDemand?
2) is there any way to determine if this vulnerability was actually exploited in onDemand?

matt.doar Each time Jira starts up the temporary folder that atlassian-bundled-plugins.zip is decompressed into is removed and the zip is decompressed again. So the extra files will be removed when you start Jira up after applying the new patch.

Vitaly, how do the updated patches remove the extra files? The atlassian-bundled-plugins.zip in the first patch will already have been decompressed, so won't the extra files also have been installed?

If we disable remote API calls, is the system still vulnerable ?

shchagin Thanks for noticing, these files should not be there. Our apologies, 3 patches contained these extra SDK parts.

if you have already installed patches for 4.4.5, 5.0.7 or 5.2.11, please re-download the appropriate "20140303" versions and re-apply them, this will remove the extra files. If you have not applied the patch yet, just download the package for your version and apply it as per instructions.

Patches for 6.0.8 and 5.1.8 have not changed.

Hi guys,

Could you please confirm that the following files are included by purpose into the patch for 5.2.11 inside the atlassian-bundled-plugins.zip:

 aui-qunit-plugin-0.11.jar
 functest-plugin-0.3.jar
 jira-func-test-plugin-5.2.11.jar
 jira-languages-5.2.11-en_AQ.jar
 jira-testkit-plugin-5.2-m19.jar
 pdkinstall-plugin-0.2.jar
 platform-ctk-plugin-2.17.0.jar

They seem to me as a part of SDK and they are not present in the original distribution.

Alex

So the problem exists even if anonymous access is disabled.
But can you give us any details about URL-patterns or POST-payloads that are used in the exploit so that we can have a really quick workaround using mod-rewrite or mod-security?

warmfusion you are correct.

Based on assumptions, given that the patch files include changes to jars that are either API or SPI components, it suggests the issue relates to a compromise on the API systems and so the vulnerability is not within the UI itself and can be exploited irrespective of anonymous view configuration.

Summary: I believe based on the patch contents that the issue is exploitable on any public system, even with anonymous access disabled.