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

Bug #1327414 reported by John Dickinson
270
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Critical
John Dickinson
Icehouse
Undecided
Unassigned
OpenStack Security Advisory
Medium
Tristan Cacqueray

Bug Description

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

Revision history for this message
John Dickinson (notmyname) wrote :
Revision history for this message
Jeremy Stanley (fungi) wrote :

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

Changed in ossa:
status: New → Incomplete
importance: Undecided → Critical
Revision history for this message
John Dickinson (notmyname) wrote :

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

Revision history for this message
Thierry Carrez (ttx) wrote :

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

Changed in ossa:
importance: Critical → Medium
status: Incomplete → Confirmed
Revision history for this message
John Dickinson (notmyname) wrote :

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

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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

Revision history for this message
John Dickinson (notmyname) wrote :

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

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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

Revision history for this message
John Dickinson (notmyname) wrote :

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.

Revision history for this message
John Dickinson (notmyname) wrote :

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.

Revision history for this message
John Dickinson (notmyname) wrote :

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.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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 ?

Revision history for this message
John Dickinson (notmyname) wrote :

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.

Revision history for this message
John Dickinson (notmyname) wrote :

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

Revision history for this message
Peter Portante (peter-a-portante) wrote :

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

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

Revision history for this message
Thierry Carrez (ttx) wrote :

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

Revision history for this message
John Dickinson (notmyname) wrote :

Attached is a patch against master that includes a functional test

Revision history for this message
John Dickinson (notmyname) wrote :

attached is a patch against icehouse

Revision history for this message
John Dickinson (notmyname) wrote :

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.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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

Revision history for this message
Thierry Carrez (ttx) wrote :

Impact desc #2 looks good.

The icehouse patch looks weird and way too big :)

Changed in ossa:
status: Confirmed → Triaged
Revision history for this message
John Dickinson (notmyname) wrote :

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

Revision history for this message
John Dickinson (notmyname) wrote :

against current master (abab39972f5261a93b986432b640e17f9008d12c)

Revision history for this message
John Dickinson (notmyname) wrote :

patch against icehouse (6946240c757d2ecc2e66f5054c5172b110084c89)

Revision history for this message
John Dickinson (notmyname) wrote :

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.

Revision history for this message
Alistair Coles (alistair-coles) wrote :

Reviewed patch against master (#24), +2

Revision history for this message
Peter Portante (peter-a-portante) wrote :

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

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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.

summary: - www-authenticate value isn't quoted
+ www-authenticate value isn't quoted (CVE-2014-3497)
information type: Private Security → Public
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (master)

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

Changed in swift:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on swift (stable/icehouse)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

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

Changed in swift:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/icehouse)

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

Thierry Carrez (ttx)
information type: Public → Public Security
Changed in ossa:
status: Triaged → In Progress
Changed in ossa:
status: In Progress → Fix Committed
summary: - www-authenticate value isn't quoted (CVE-2014-3497)
+ [OSSA 2014-020] www-authenticate value isn't quoted (CVE-2014-3497)
Changed in ossa:
assignee: nobody → Tristan Cacqueray (tristan-cacqueray)
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in swift:
status: Fix Committed → Fix Released
milestone: none → 2.0.0
NMarcos (nelsonmarcos)
description: updated
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers