copy_from in api v1 allows network port scan

[Tom Patzig]

copy_from allows to create Images with an url like http://localhost:22
The remote content gets copied unverified in the defined glance store.

E.g. after downloading the image with copy_from url http://localhost:22, you see the OpenSSH banner.

This is a security issue, as it allows users to do network "scans" for open ports and it copies remote (potentially malicious) content unverified to your configured glance store.

glance api v1 is still the default in horizon.

[Morgan Fainberg (mdrnstm)]

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.

[Brian Rosmaita (brian-rosmaita)]

Yep, copy_from is dangerous, that's why it's not in the v2 API and one reason why the v1 API will be deprecated in Newton.

As far as malicious content goes, it does make it easier for an end user to be tricked (they just need to know the URL) and Glance will go get it for them. But if a cloud allows end users to upload image data, the end user can simply download from the URL and then upload the payload. Thus I don't see it as being much different from the current situation.

The port scanner is an interesting case as it can expose information about what ports are in use on the server running Glance. I don't know whether it could reveal info that couldn't be discovered by other means. Someone else will have to answer that.

[Morgan Fainberg (mdrnstm)]

@Brian,

I think the port scan issue is that it allows a (more) masked port scan since the scan would come from glance. At the very least it could be utilized to scan resources that are not available externally because glance may talk on internal interfaces to other cloud-systems. This may expose information about what to attack once access to the internal networks are breached.

Secondarily it could be used to proxy-scan other hosts that are not part of the current cloud deployment. This could be used as a means to mask the real origin of the scan.

Could the info be found via other means? Yes, in some cases.

[Brian Rosmaita (brian-rosmaita)]

@Morgan,

Thanks for the additional info on the port scan issue.

My opinion is that this is a "won't fix" as a bug, since v1 is going to be deprecated and the functionality isn't present in v2. But that's just my opinion, we'll have to see what others think.

[Tom Patzig (tom-patzig)]

Was v1 already deprecated for Liberty & Mitaka If not than this might be a valid security bug for this stable releases.

If v1 is deprecated, than this is a horizon bug, which does only support v1. There is a blueprint open https://blueprints.launchpad.net/horizon/+spec/horizon-glance-v2
But until this gets implemented a horizon config option, which disables the copy_from URL input form, might be very helpful to address this issue.

[Brian Rosmaita (brian-rosmaita)]

Tom, you are right, the deprecation of v1 won't happen until Newton, so this will be a problem in the stable releases for a few cycles.

A horizon option to disable copy_from sounds like a good idea to me.

On the Glance side, there is an existing "upload_image" policy that blocks copy_from -- but it also blocks any other functionality for uploading image data, and it affects both the v1 and v2 APIs.

[Tristan Cacqueray (tristan-cacqueray)]

It seems like this bug can't be fixed with a non breaking stable branch fix. Perhaps it can be covered by the eventual OSSN about glance image creation ?

How about adding a "src_store" blacklist option to prevent connections to localhost and management networks ?

[Tom Patzig (tom-patzig)]

What about a "copy_from" policy to forbid this feature in glance v1?

[Tom Patzig (tom-patzig)]

Ahh there is a copy_from policy for glance - which allows to restrict this action to certain roles, like admin. I think this is sufficient to circumvent.

[Brian Rosmaita (brian-rosmaita)]

@tom-patzig: you are correct, don't know how I missed that. Yes, an existing solution for this is to restrict the copy_from policy to admins or trusted users.

[Brian Rosmaita (brian-rosmaita)]

And I should mention, I tested this in devstack. Setting the policy to:

    "copy_from": "role:admin"

allowed my admin user to use copy-from with v1, whereas my demo user got a 403.

[Tristan Cacqueray (tristan-cacqueray)]

I've switched the OSSA task to Opinion and added ossg-coresec until we figure out how to coordinate this disclosure with a Security Note.

[Travis McPeak (travis-mcpeak)]

Yep, this seems like a pretty clear-cut SSRF type issue. Since Glance typically sits on a privileged network in many deployments an attacker could use this to enumerate internal network details.

Agree embargoed note is the right thing to do to give deployers a chance to flip the switch/validate the switch is already flipped.

+OSSN

[Jeremy Stanley (fungi)]

The VMT is being asked questions about this report by a vendor servicing the organization who reported it. Is there any benefit in continuing to keep this under embargo? Is the planned OSSN nearly ready, or should we go ahead and let that process continue in public at this point?

[Ian Cordasco (icordasc)]

I'm not sure where Luke or Travis are in writing up an OSSN, but I'd caution against mentioning this part of the original bug report:

> it copies remote (potentially malicious) content unverified to your configured glance store.

Glance regularly deals in potentially malicious and unverified content. If any user can upload image data than all of that data could be malicious or unverified. Unless your Nova compute nodes, however, can run any type of virtualization the actual effect of that malicious content is dubious. The image data is never displayed in Horizon, so there's no XSS or other attacks possible there. The image data isn't excecuted on download by Glance client on any of the hosts or on a user's machine. For it to be executed, the user would have to take those steps directly and if they know Glance is the *image* service, I doubt they'd try to execute an image. So, like a separate issue we had reported, I'm unsure what people's threat model is around this.

[Ian Cordasco (icordasc)]

As to whether or not to keep this under embargo, I'd vote it's pointless. There is no fix. And the OSSN might be written faster without the embargo.

[Brian Rosmaita (brian-rosmaita)]

Agree with Ian. We should focus on the port-scanner aspect of this report.

An operator can restrict copy-from to privileged users by setting the copy_from policy appropriately. We recommend that this be done in deployments where the copy-from functionality could be used as a port scanner as described in the bug.

[Tristan Cacqueray (tristan-cacqueray)]

I agree with the last comments, if OSSG is fine with this course of actions, lets open this bug report.

[Luke Hinds (lhinds)]

@Tristian, fine by me to open this.

[Jeremy Stanley (fungi)]

Opening as agreed.