Anonymous user can download public image through Swift

[Feodor Tersin]

When Glance uses Swift as backend, and Swift uses delay_auth_decision feature (for temporary urls, for example), anyone can download public images anonymously from Swift by direct url.

Steps to reproduce:
1 Set
    delay_auth_decision = 1
in Swift's proxy-server.conf.
Set
    default_store = swift
    swift_store_multi_tenant = True
    swift_store_create_container_on_put = True
in Glance's glance-api.conf.

2 Create a public image.
    glance image-create --name fake_image --file <some_text_file_name> --is-public True
You may use a text file to reproduce the error for descriptive reasons.
Use the got image id at the next step.

3 Download created image by curl.
    curl <swift_endpoint>/glance_<image_id>/<image_id>
See your file in the output.
If swift_store_container in your glance-api.conf is not 'glance', use appropriate prefix in the command above.

Glance set read ACL to '.r:*,.rlistings' for all public images. Thus since anyone has access into Swift (by delay_auth_decision parameter), anyone can download a public image.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the report, the OSSA task is set to incomplete pending additional detail from swift-coresec.

[Tristan Cacqueray (tristan-cacqueray)]

Oups, I meant glance-coresec, both group have access to this report now to help confirm and diagnose.

[clayg (clay-gerrard)]

So those acls sure do indicate public (i.e. anonymous, i.e. you point your web-browser at the url, i.e. available to the internet) access to the entire container.

But umm... is that not intention of "public" images?

[Feodor Tersin (ftersin)]

I believe we have 3 categories of users: cloud admins, cloud users, and cloud service users.
Cloud admins tune the cloud.
Cloud users launch own special services in the cloud.
Cloud service users don't know that they work with a cloud. They work with provided services.

As i understand public images are intended for all cloud users to start instances with certain features. So they should be accessable only by cloud users. Anonymous access should be restricted. Because an image is not a part of cloud service data. But it's internal cloud data.

[clayg (clay-gerrard)]

Is there a group or role that all cloud service users are a member of which can be used to authorize to those requests which have been authenticated to have that membership?

Do the service users themselves *need* access to this images or are the requests always made on their behalf through a proxy service (i.e. glance).

Has there been any archeology done on this? Did the original implementer of those public acl's mis-understand these implications or is this a well know, not terribly harmful/dangerous, yet in some deployments undesirable behavior?

If all cloud users already have access to the data - isn't already more or less "public" should they chose to share it?

[Feodor Tersin (ftersin)]

Cloud service users are not known to keystone. They are regular users of web sites and other services which are launched in instances. So they don't have any cloud authorization property.

One should explicity request an image from Swift to get it. Moreover, there is no legal way to get the image url for cloud service users. But if he knows it, he can download the image.

I don't see any special comments in https://github.com/openstack/glance/commit/1f68b21de8b8a3366eb08fe1fa74ae7db2ac72b4 which added .r:*.

Of course, any cloud user can download a public image, and share it to all of the world. But it will be obvious action of a particular cloud user. Now the problem exists without any cloud user action (except compromising the image url).

[clayg (clay-gerrard)]

ok, i'm lost then.

It sounds like public images have always been public and no-one even bothered to comment on how obvious it was what was ment by PuB-LICK.

Is this then a feature request to restrict anonymous storage of images to authorized users - cause I'm quickly getting lost into the use-case and I don't even think I understand what that means.

Perhaps this would be more familiar ground to a glance dev. I'll bow out. Maybe ttx can and try to suss out if there is a security issue here. If Glance dev's need any help from the swift side let us know; just trying to be helpful - sorry if I muddied the waters.

[Feodor Tersin (ftersin)]

For a private cloud, public images should be public inside the cloud only.

In this case an image can be proprietary and should be not accessible from outside of the cloud.

[Jeremy Stanley (fungi)]

At best I think this is a feature request, and one we would almost certainly not backport to existing stable releases because it would imply a definite behavior change. As such we should make this public (not even public security) and tag it as a security hardening measure as well as possibly an existing but perhaps not well known behavior which the OSSG may want to cover in future updates to the security manual or a security note.

Adding OSSG core security reviewers for additional input.

I don't think this is something the VMT could issue an advisory about. Does anyone object?

[Stuart McLaren (stuart-mclaren)]

This is a real problem in my opinion.

One possible cause of confusion is that 'public' means something slightly different in glance than in swift.

In Swift a public object is accessible to truly anybody (as long as you can connect to the network the swift endpoint is on). You do not need to supply any credentials whatsoever to access the object.
A simple 'curl http://swift/path' is enough.

In Glance a public image is accessible to other users only (after a successful authentication with valid credentials); it is not accessible by anonymous downloaders.

This bug allows for the following scenario (in multi-tenant mode only):

1) public image (123) is made available by the cloud admin

2) a user creates her own snapshot (456)

3) by looking at the path to her own image (456), and the owner id of (123), the swift URL for the public image can be inferred

4) the image URL for 123 can be made known

5) anybody can access the image anonymously, without any credentials.

So, the admin's intention is for the image to be available to a potentially small set of users with valid accounts, with accesses potentially billed or rate limited in some way, but it is actually not restricted to that set of users.

This is not possible, for example, using the single tenant swift backend or the filesystem backend.

I'm not sure a simple fix is possible however, this is just how the multi-tenant behaviour works.

In future, this update to the keystone middleware https://review.openstack.org/#/c/108384/
can be used to only allow accesses to these images via the glance api rather than directly to swift.

[Robert Clark (robert-clark)]

+1 to Stuarts points.

I'd also like to point out that that private clouds are rarely contained entirely within private networks - it's incredibly common for private clouds to expose consumable assets externally.

[Jeremy Stanley (fungi)]

I don't disagree at all with these points, merely don't see how we can fix this for existing releases other than to document proper configuration which will allow deployers/operators to take appropriate action if the current behavior is not their desired behavior.

For the master branch, this should almost certainly be tightened up or at least made more obvious in the UI and configuration, but we shouldn't need an embargo or vulnerability advisory for that.

[Thierry Carrez (ttx)]

Yes, this falls in the "feature has potential security consequences" bucket. It can be fixed/improved in future versions, but is not really backport material (since you would be changing behavior that a lot of people may rely on). It feels like it falls in the "improve in future versions, maybe document confusing state in OSSN" category.

[Thierry Carrez (ttx)]

OK, so unless someone complains we'll make this one public on Thursday, and ask OSSG if they are interested in issuing aa

[Thierry Carrez (ttx)]

aaaa. an OSSN :)

[Mark Washenberger (markwash)]

FWIW direct url was intended for use on private networks, for lack of a better authz mechanism.

[Stuart McLaren (stuart-mclaren)]

A potential (partial) fix:

https://review.openstack.org/#/c/130200/

[Nathan Kinder (nkinder)]

This was published as OSSN-0025:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0025

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/130200
Committed: https://git.openstack.org/cgit/openstack/glance_store/commit/?id=69f801c3497c768a10fa33aac42951f1e29c977b
Submitter: Jenkins
Branch: master

commit 69f801c3497c768a10fa33aac42951f1e29c977b
Author: Stuart McLaren <email address hidden>
Date: Wed Oct 22 12:06:53 2014 +0000

    Fix public image ACL in multi-tenant Swift mode

    Currently the ACL to public Swift images is '.r:*'. This means that
    anonymous users who have not authenticated may be able to access the
    data of a public Swift image when multi-tenant mode is enabled.

    Change to use the cross-tenant '*:*' ACL which requires an authenticated
    user for access.

    Note: This does not address authenticated users being able to download
    public image data directly from Swift (potentially bypassing Glance's
    'download_image' policy).

    Change-Id: I1fa3297908ca4be517419e9460f056a09aa98ef0
    Addresses: OSSN 0025 (https://review.openstack.org/#/c/117928/)
    Closes-bug: #1354512

[Erno Kuvaja (jokke)]

Fix committed to glance-store, aiming bug to that as well.

[Louis Taylor (kragniz)]

This was released in glance_store 0.1.10.