[OSSA 2014-020] www-authenticate value isn't quoted (CVE-2014-3497)

How far back (to which Swift release and/or integrated OpenStack release) is this vulnerability present?

The patch introducing the www-authenticate header landed right after Havana was cut. This means it only affects OpenStack Icehouse (Swift 1.11.0 - 1.13.1).

We will need to backport this to Icehouse (Swift 1.13.1).

Looks like a valid issue (cross-site content ?), although exploitation requires clicking on a rather suspicious untrusted link.

Credit for discovering and reporting this bug in the CVE should go to the "Globo.com Security Team".

@notmyname ok noted. Maybe they want to credit an individual as well ? We usually do "reporter-name (company)"

We asked and that's the response that was given.

@notmyname Isn't Swift 1.11.0 (havana) still supported ? I think we'll need patch for this version as well.

Also testing the url in the bug description didn't reveal any assets, only remote code execution in browser context from swift server, and Swift does not use cookies or CSRF tokens.
I assumed a more complex attack, where the extra parameter would be happened to a valid Swift URL.
Please advice if this description is not complete.

Here is impact description #1:

Title: XSS in Swift requests through WWW-Authenticate parameter
Reporter: Globo.com Security Team
Products: Swift
Versions: 1.11.0 to 1.13.1

Description:
Globo.com Security Team reported a vulnerability in Swift requests parameter escaping. By tricking a Swift user into clicking a malicious URL, a remote attacker may trigger an XSS out of the Swift domain, resulting in potential assets stealing like authentication tokens. All Swift setups are affected.

Tristan, the www-authenticate header was merged into Swift after the Havana release (Swift 1.10.0) was cut. Therefore Havana Swift isn't vulnerable to this.

Tristan,

To be clear, there is no privilege elevation with this bug. It is only something that eg could be used for phishing. This does not allow any sensitive server-side data to be revealed by Swift.

I don't think the proposed CVE description is correct. This is only triggered on a 401 response and doesn't reveal any sensitive information like tokens. However it could be used to display arbitrary[*] data on someone else's domain. For example, by tricking a user into clicking a malicious link, an attacker may be able to create a web page that looks like a billing page for the given domain. First level checking (that it's at the right domain) wouldn't reveal anything amiss. Granted, there are a lot of assumptions for this to take place, some of which have not yet been demonstrated.

[*] the caveat to "arbitrary" is that the crafted HTML would need to not contain a "/". Which means that it might only work if javascript from the same relative URL would need to be loaded. Which means that it's probably only possible to be maliciously exploited if the deployer is using the domain_remap middleware. This is just speculation though, and has not yet been demonstrated. But if that is the case, then it's not too different from just storing a web page as a Swift object and getting a user to load that.

Hmm...maybe this isn't as big of deal as I thought.

Indeed, appending the malicious code to a valid URL doesn't seems to work as it contains a "/".

Then the real impact would be remote code execution executed in victim browser, appearing from the swift server.
I don't think we need to make a list of the bad things that could happen at that point (e.g., local network exploitation)

@VMT am I missing something here ?

Tristan, is that any difference from simply having an account on the cluster and storing a malicious page there? Right now, the only difference I can see so far is that with this bug one can load some HTML on the response without having an account on the cluster. Storing and getting a user to load malicious code in Swift isn't a bug in Swift (any more that it is a bug in a hard drive to allow for storing viruses).

I'm leaning to changing my opinion and saying that this isn't a security bug.

OK, nevermind. This is a security issue. I have been playing with this locally, and the difference with this issue is that new headers can be set (or existing headers duplicated). This means that eg a Content-Encoding: gzip header can be sent, and maybe if that's crafted carefully enough, it can lead to getting around the "/" issue I mentioned above.

Yes I think this is a security issue, however a low severity one. (Please show me how I'm wrong on the severity.)

FWIW: I tested the patch, and that looks fine to me.

It might be nice to have a functional test for this as well. :)

@Tristan: I think we just need to say that this allows to inject data in Swift response while still appearing to come from the Swift server, potentially leading to a XSS vulnerability. No need to get too specific on what that would exactly allow.

Attached is a patch against master that includes a functional test

attached is a patch against icehouse

Note that with the upcoming storage policy release, we need to quickly approve these patches or fix them. As in by the end of the week.

If you approve, please leave your approval comments here in LP. If you don't approve, please say so and do the normal review comments (or your improved patch) here in the comments.

@notmyname and ttx, thanks for your observations!
Oh I didn't knew about this storage policy release, and the remaining time won't allow us to process this properly. I mean we need Impact description approval, CVE requests, patches approval, stakeholders advance notification and final proper advisory with fixes pushed to gerrit. This won't happen before early next week at best...

In the mean time, here is impact description #2:

Title: XSS in Swift requests through WWW-Authenticate header
Reporter: Globo.com Security Team
Products: Swift
Versions: 1.11.0 to 1.13.1

Description:
Globo.com Security Team reported a vulnerability in Swift requests' parameters escaping. By tricking a Swift user into clicking a malicious URL, a remote attacker may inject data in Swift response while still appearing to come from the Swift server, potentially leading to a XSS vulnerability. All Swift setups are affected.

@notmyname, we could also make that bug public as it turns out to be kind of low-impact, so we are not sure there is much value in embargoing.

Then you could just push fixes to gerrit, and we'll process this in parallel.

Impact desc #2 looks good.

The icehouse patch looks weird and way too big :)

ttx, yup. looks like I had diff'd against master or something. thanks for catching that.

against current master (abab39972f5261a93b986432b640e17f9008d12c)

patch against icehouse (6946240c757d2ecc2e66f5054c5172b110084c89)

proposed impact description #3:

Title: XSS in Swift requests through WWW-Authenticate header
Reporter: Globo.com Security Team
Products: Swift
Versions: 1.11.0 to 1.13.1

Description:
Globo.com Security Team reported a vulnerability in Swift's header value escaping. By tricking a Swift user into clicking a malicious URL, a remote attacker may inject data in Swift response while still appearing to come from the Swift server, potentially leading to other client-side vulnerabilities. All Swift setups from version 1.11.0 to 1.13.1 are affected.

Reviewed patch against master (#24), +2

Also reviewed patch against master (#24), +2

Thank you all!

@notmyname, there is no need to put versions number in the actual description. Here, is impact description #4:

Title: XSS in Swift requests through WWW-Authenticate header
Reporter: Globo.com Security Team
Products: Swift
Versions: 1.11.0 to 1.13.1

Description:
Globo.com Security Team reported a vulnerability in Swift's header value escaping. By tricking a Swift user into clicking a malicious URL, a remote attacker may inject data in Swift response while still appearing to come from the Swift server, potentially leading to other client-side vulnerabilities. All Swift setups are affected.

Fix proposed to branch: master
Review: https://review.openstack.org/101031

Change abandoned by John Dickinson (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/101033
Reason: dup

Reviewed: https://review.openstack.org/101031
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=e00da6cabc10b28b55cd1f0d128751f33437fa9e
Submitter: Jenkins
Branch: master

commit e00da6cabc10b28b55cd1f0d128751f33437fa9e
Author: John Dickinson <email address hidden>
Date: Fri Jun 6 11:46:41 2014 -0700

    properly quote www-authenticate header value

    HTTP header values should be quoted. Since the WWW-Authenticate
    header value contains user-supplied strings, it's important to
    ensure it's properly quoted to ensure the integrity of the protocol.

    Previous to this patch, the URL was unquoted and then the unquoted
    value was returned in the header. This patch re-quotes the value
    when it is set on the response.

    This is filed as CVS-2014-3497

    Fixes bug 1327414

    Change-Id: If8bd8842f2ce821756e9b4461a18a8ac8d42fb8c

Reviewed: https://review.openstack.org/101032
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=b223322ed1ef44f61490f820240aa01f1047ae2e
Submitter: Jenkins
Branch: stable/icehouse

commit b223322ed1ef44f61490f820240aa01f1047ae2e
Author: John Dickinson <email address hidden>
Date: Fri Jun 6 11:46:41 2014 -0700

    properly quote www-authenticate header value

    HTTP header values should be quoted. Since the WWW-Authenticate
    header value contains user-supplied strings, it's important to
    ensure it's properly quoted to ensure the integrity of the protocol.

    Previous to this patch, the URL was unquoted and then the unquoted
    value was returned in the header. This patch re-quotes the value
    when it is set on the response.

    This is filed as CVS-2014-3497

    Fixes bug 1327414

    Change-Id: If8bd8842f2ce821756e9b4461a18a8ac8d42fb8c