Gerdt Brouwer added a comment - 12/Mar/2013 7:59 PM - edited Hi Dieter, We added to the config : <location /rpc> Order allow,deny Allow from 127.0.0.1 <ip svn> </location> $ 4.000,- per line saved

Dieter Greiner added a comment - 12/Mar/2013 6:14 AM Thank's Vitaly, this is enough information to write a filter to block the problematic requests.

William Crighton [CCC] added a comment - 12/Mar/2013 1:10 AM I tested the example I posted in a comment above ( https://jira.atlassian.com/browse/JRA-29786?focusedCommentId=449536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-449536 ) against a simple 'get issue info' perl soap call from inside my network and from outside my network - and it worked. I've modified the example adding logging as follows - again, these are Apache webserver rewrite commands being used when apache is 'fronting' JIRA using either mod_jk, mod_proxy_ajp, or just mod_proxy: <VirtualHost *:80> ServerName *.capitalcityconsultants.com ServerAlias jira.capitalcityconsultants.com jira Redirect / https: //jira.capitalcityconsultants.com/ ErrorLog logs/jira_nossl_error_log CustomLog logs/jira_nossl_access_log combinedio </VirtualHost> <VirtualHost *:443> ServerName *.capitalcityconsultants.com ServerAlias jira.capitalcityconsultants.com jira RewriteLog logs/jira-rewrite.log RewriteLogLevel 1 RewriteEngine on RewriteCond %{REMOTE_HOST} !^127\.0\.0\.1 RewriteCond %{REMOTE_HOST} !^172\.27\.1\. RewriteRule ^/(\?wsdl/.*) https: //jira.capitalcityconsultants.com/ [L] RewriteCond %{REMOTE_ADDR} !^127\.0\.0\.1 RewriteCond %{REMOTE_ADDR} !^172\.27\.1\. RewriteRule ^/(rpc/soap/.*) https: //jira.capitalcityconsultants.com/ [L] SSLProxyEngine on ProxyRequests Off ProxyPreserveHost On ProxyPass / ajp: //127.0.0.1:9103/ ProxyPassReverse / ajp: //127.0.0.1:9103/ Include /etc/httpd/conf.d/ccc_ssl_info ErrorLog logs/jira_error_log CustomLog logs/jira_access_log combinedio </VirtualHost> I didn't have any issues with getting the rewrites to work when using mod_jk or mod_proxy_ajp. I believe it has a lot to do with where in the file the different directives appear. After you setup your config and restart Apache just take a look at the new rewrite log file - it'll get big in a hurry, so you won't want to leave it at debug level 1 for long. Hope this helps some people. -wc

VitalyA added a comment - 12/Mar/2013 12:47 AM - edited Source code for the XML-RPC plugin is at https://svn.atlassian.com/svn/public/atlassian/rpc-jira-plugin/trunk/ , patches are more or less diffs between versions. Blocking on URL basis is not possible due to the nature of how XML-RPC works (it's all one URL, so it's either all or nothing). One way of blocking this issue without completely disabling SOAP is to drop any POST request to the API URL (/rpc/soap/jirasoapservice-v2) containing <attachmentNames.*> or </attachmentNames> tags in the body.

Steve Bishop added a comment - 11/Mar/2013 10:49 PM - edited I agree. I would like to see a workaround that doesn't include completely disabling the APIs. It would also be great to have specific patch files with source code in them.

Dieter Greiner added a comment - 11/Mar/2013 10:44 PM I really would like to know why we pay 16000 $ maintenance fees per year and don't get a fix for 4.4.5 ... At least couldn't you publish some technical details, maybe just the file upload call must be disabled. We can't disable the SoAP API completely!

Eric Dalgliesh added a comment - 04/Mar/2013 8:31 AM In case it helps, you should be able to download the source for the rpc plugin at https://svn.atlassian.com/svn/public/atlassian/rpc-jira-plugin/

Steve Bishop added a comment - 01/Mar/2013 11:54 PM I didn't see any source code in the patch, so I don't see how one could easily apply it to 4.X.

MattD added a comment - 25/Feb/2013 6:32 PM Looking at the contents of the patch it shouldn't be too hard to apply the same changes to JIRA 4.x. Just that it won't be an officially tested patch.

MattS added a comment - 25/Feb/2013 5:23 PM I had to recheck the details at https://confluence.atlassian.com/display/Support/Security+Patch+Policy but based on that page I would not expect 4.x to get a patch.