CSV Injection Possible in Compute Usage History

Bug #1842749 reported by Adam Harwell on 2019-09-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Adam Harwell
OpenStack Security Advisory

Bug Description

Many spreadsheet programs, such as Excel, LibreOffice, and OpenOffice, will parse and treat cells with special metacharacters as formulas. These programs can open comma-separated values (CSV) files and treat them as spreadsheets. If an attacker can influence the contents
of CSV file, then that can allow the attacker to inject code that will execute when someone opens the CSV file through a spreadsheet program.
In the Compute Overview panel in Horizon, there is a section titled “Usage Summary.” This section has a feature for downloading a CSV document of that usage summary. The contents of the CSV document include the name of the instances and other points of data such as its current state or how many resources it consumes.
An attacker could create an instance with a malicious name beginning with an equals sign (=) or at sign (‘@’). These are both recognized in Excel as metacharacters for a formula. The attacker can create an instance name that includes a payload that will execute code such as:

=cmd|' /C calc'!A0

This payload opens the calculator program when the resulting CSV is opened on a Windows machine with Microsoft Excel. An attacker could easily substitute this payload with another that runs any arbitrary shell commands.

Reproduction Steps:

1. Access an OpenStack project, navigate to the Instances section.
2. Create an instance with the following name:
=cmd|' /C calc'!A0
3. Navigate to the Overview section.
4. Refresh the page until the new instance shows up in the Usage list.
5. Click the button titled “DOWNLOAD CSV SUMMARY.”
6. Observe the generated CSV file.

description: updated
Jeremy Stanley (fungi) wrote :

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

Changed in ossa:
status: New → Incomplete
description: updated
Adam Harwell (adam-harwell) wrote :

Fix for this is up for review: https://review.opendev.org/#/c/679161/

Jeremy Stanley (fungi) wrote :

In that case there's no point in maintaining an embargo on the report, so I have switched it to Public Security.

description: updated
information type: Private Security → Public Security
Akihiro Motoki (amotoki) wrote :

This could happen.

CSV report is available in three places:
- (a) Project->Compute->Overview
- (b) Admin->Overview
- (c) Identity->Project->View Usage

In case of (a), a tenant user retrieves its usage based on its servers. It could happen when a tenant user secret is stolen by an attacker.
In case of (b), admin would be affected. It happens when some tenant secret or admin secret is stolen.
In case of (c), same as (b).

Changed in horizon:
importance: Undecided → High
assignee: nobody → Adam Harwell (adam-harwell)
status: New → In Progress
Matthias Runge (mrunge) wrote :

I am unclear why this has been treated as security issue in Horizon and as a Horizon issue at all.

A security issue in Horizon would either reveal credentials or would allow to get access to functions, the user is not allowed. None of that is the case here.

In this case, the issue happens in the end users operating system. Following that logic, you'd also need to patch text editors to forbid to write the given sequences described at the top.

In my point of view, the real issue needs fixing is the handling of the csv files in end users systems to not allow actions to be launched from spreadsheets.

Adam Harwell (adam-harwell) wrote :

@Matthias: I don't necessarily disagree with you -- this isn't even *really* my bug, I'm just acting as a liaison for my internal security team, since they don't have any visibility to upstream.

But, this is an issue that Horizon *can* easily fix, and I believe there is precedent (in a general sense) for taking steps to mitigate a possible security risk that could stem from something in our control. If we know that it is common for editors to badly handle CSV files, we can at least do our part to generate them in a way that's (hopefully?) more safe.

Matthias Runge (mrunge) wrote :

I disagree. Horizon can not fix issues in current Spreadsheets programs.

Adam, if you can, please invite your internal security team here. Maybe they can point out, how the underlying problem is solved here.

Jeremy Stanley (fungi) wrote :

To be clear, this is not yet being treated as a vulnerability. The OpenStack VMT triaged it because it was flagged by the original reporter as a possible vulnerability in Horizon, so Horizon's core security reviewers were asked to make a determination there. The OpenStack Security Advisory bugtask is still marked Incomplete until there is some consensus that this 1. represents an actual security risk in OpenStack software, 2. has a practical exploit scenario where an attacker could leverage it to accomplish something they're not supposed to be able to do, and 3. can be fixed or mitigated thoroughly in all currently supported stable branches of OpenStack source code.

I tend to agree that if users configure their browsers to pass arbitrary files built from untrusted data to dangerous local applications on their systems, it's not Horizon's job to know every possible way that could happen and provide built-in workarounds. The question for the Horizon developers is whether they want to do that anyway, or whether we should simply caution users about these risks somewhere.

Adam Harwell (adam-harwell) wrote :

My question is -- does it matter what we decide here? What really matters is, if people are willing to merge the patch that is already up to fix this issue. If so, then who cares if we mark this as a vuln or not? I don't, at least, so go ahead and mark it as not a vuln, and merge the patch! lol

I think in general, if we know we can protect people from a possible exploit by just *doing proper quoting* and it's *built in to the CSV library*, we may as well do it as it's basically minimum effort. Thoughts?

Jeremy Stanley (fungi) wrote :

The only substantive differences for treating this as a tracked vulnerability are that it will require backporting to all supported stable branches, after which the OpenStack VMT will request a CVE assignment from MITRE and publish a security advisory about it to relevant public mailing lists as well as on the https://security.openstack.org/ Web site. The project's maintainers may also want a corresponding release note added, and may decide to request urgent stable point releases to include it.

Adam Harwell (adam-harwell) wrote :

Then honestly, my vote is DON'T treat it as a real vulnerability in Horizon, but still merge the patch into Train, if you'd be so kind. :D

Nick Tait (nickthetait) wrote :

Based upon my reading, this seems like the responsibility of your OS, antivirus, or the CVS interpreter application. So I support a VMT rating of class D or E. That being said, I support merging the proposed fix (just to master branch) as it improves the security posture of OpenStack.

Jeremy Stanley (fungi) wrote :

Thanks for the feedback everyone. We'll classify it as a security hardening opportunity in that case, no advisory needed.

Changed in ossa:
status: Incomplete → Won't Fix
information type: Public Security → Public
tags: added: security

Reviewed: https://review.opendev.org/679161
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=70629916fe32df61018fd122711e6b036b53c811
Submitter: Zuul
Branch: master

commit 70629916fe32df61018fd122711e6b036b53c811
Author: Adam Harwell <email address hidden>
Date: Wed Aug 28 16:59:06 2019 -0700

    Use quoting for CSV Writing

    An attacker could create an instance with a malicious name beginning
    with an equals sign (=) or at sign (‘@’).
    These are both recognized in Excel as metacharacters for a formula. The
    attacker can create an instance name that includes a payload that will
    execute code such as:
    =cmd|' /C calc'!A0
    This payload opens the calculator program when the resulting CSV is
    opened on a Windows machine with Microsoft Excel. An attacker could
    easily substitute this payload with another that runs any arbitrary
    shell commands.

    Quote the CSV output so this is no longer a possibility.

    Closes-Bug: #1842749
    Change-Id: I937fa2a14bb483d87f057b3e8be219ecdc9363eb

Changed in horizon:
status: In Progress → Fix Released

This issue was fixed in the openstack/horizon 17.0.0 release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers