Closing this issue as CONFDEV-9069 has now been fixed.

Ideally a whitelist approach would be used. However, for the moment the approach that JIRA took is being merged into confluence. That is, provide:
1. a default level that blacklists certain content-types and allow to be sent INLINE (Content-disposition: inline)
2. a secure level where all attachments are sent as downloads (Content-disposition: attachment)
3. an insecure level where attachments are sent INLINE (Content-disposition: inline)

The current 'default level' blacklist approach needs to be swapped for a whitelist approach so as to keep up with future browser download behaviour changes. However, as a start it will use a blacklist approach.

Thanks for the detailed information David. I'll pull down the master and have a review of the changes. Is there any reason why a whitelist approach wasn't taken for known good types to be inlined?

CVSS score: 6.5 => High severity

Exploitability Metrics

Impact Metrics

See https://extranet.atlassian.com/display/SECCOUNCIL/How+to+evaluate+vulnerability+severity+under+CVSS for details and http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2 for score calculator.

danh, git pull ?

danh Yes we are already aware of this issue. What isn't in the code you are auditing are changes which are now in master and a release version soon which swap the code to use a blacklist approach which I'll describe below:

Just a note before the approach is described:
Attachment download requests in confluence-core/confluence/src/java/com/atlassian/confluence/servlet/download/AttachmentDownload.java now have the following headers set on all download responses:
1. X-Content-Type-Options : nosniff
2. X-Download-Options : noopenq

Approach:

Given a content-type check if it is found within a blacklist('executableContentTypes') of content-types like this:
(note: the executableContentType come through as lower case)

    public boolean isExecutableContentType(final String contentType) {
        boolean isExecutableContentType = false;
        if (StringUtils.isBlank(contentType)) {
            return true;
        }

        for(String executableContentType : executableContentTypes) {
            if (contentType.toLowerCase(Locale.US).contains(executableContentType) ) {
                isExecutableContentType = true;
                break;
            }
        }
        return isExecutableContentType;
    }

then the download is sent with a Content-Disposition:attachment header. The current blacklist list appears as follows:

text/html text/html-sandboxed text/xhtml application/xhtml+xml \
  text/xml application/xml text/xml-external-parsed-entity application/xml-external-parsed-entity application/xml-dtd \
  application/x-shockwave-flash image/svg+xml image/svg-xml application/futuresplash application/x-cab video/x-flv \
  application/octet-stream

Adding SVG file used in testing. The sample is not malicious and will just pop an alert box.