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

[John Dickinson]

The WWW-Authenticate header value (returned on a 401 response) includes user-supplied strings to indicate the proper auth realm. However, Swift un-quotes the URL and then sets the value in the response. This means that a URL can be constructed that includes new HTML content at the hoster's own domain.

For example:

http://saio:8080/v1/AUTH_infra%0A%0A%3Cb%3EHello%20World%3Cp%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3EYou%20should%20not%20see%20this%3Cp%20style%3D%22display%3A%20hidden%22%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E%3Cbr%3E

The fix is to ensure the www-authenticate value is quoted

[Jeremy Stanley (fungi)]

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

[John Dickinson (notmyname)]

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).

[Thierry Carrez (ttx)]

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

[John Dickinson (notmyname)]

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

[Tristan Cacqueray (tristan-cacqueray)]

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

[John Dickinson (notmyname)]

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

[Tristan Cacqueray (tristan-cacqueray)]

@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.

[John Dickinson (notmyname)]

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.

[John Dickinson (notmyname)]

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.

[John Dickinson (notmyname)]

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.

[Tristan Cacqueray (tristan-cacqueray)]

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 ?

[John Dickinson (notmyname)]

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.

[John Dickinson (notmyname)]

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.)

[Peter Portante (peter-a-portante)]

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

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

[Thierry Carrez (ttx)]

@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.

[John Dickinson (notmyname)]

Attached is a patch against master that includes a functional test

[John Dickinson (notmyname)]

attached is a patch against icehouse

[John Dickinson (notmyname)]

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.

[Tristan Cacqueray (tristan-cacqueray)]

@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.

[Tristan Cacqueray (tristan-cacqueray)]

@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.

[Thierry Carrez (ttx)]

Impact desc #2 looks good.

The icehouse patch looks weird and way too big :)

[John Dickinson (notmyname)]

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

[John Dickinson (notmyname)]

against current master (abab39972f5261a93b986432b640e17f9008d12c)

[John Dickinson (notmyname)]

patch against icehouse (6946240c757d2ecc2e66f5054c5172b110084c89)

[John Dickinson (notmyname)]

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.

[Alistair Coles (alistair-coles)]

Reviewed patch against master (#24), +2

[Peter Portante (peter-a-portante)]

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

[Tristan Cacqueray (tristan-cacqueray)]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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