[Yahoo-eng-team] [Bug 1842149] [NEW] TLS ciphers/protocols are not configurable for console proxies
Public bug reported: Description === The console proxies (VNC, SPICE, etc) currently don't allow the allowed TLS ciphers and protocol versions to be configurable. This results in the defaults being used from the underlying system (or even compiled defaults in OpenSSL), which may not be secure enough for many deployments. For example, many commonly used distributions have compiled-in OpenSSL library defaults that allow things like SSLv3 and TLSv1.0 due to backwards compatibility concerns. This is often fine, as applications are expected to override the defaults if they want to be more secure, but we can't do that currently in nova. Steps to reproduce == - Deploy nova and configure the VNC proxy with TLS by setting the 'cert' and 'key' options in the '[vnc]' section. - Utilize a tool such as nmap, 'openssl s_client', or an approach like https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-cipher- suites-a-particular-website-offers to scan the VNC proxy port for the allowed TLS ciphers and protocols. Here is an few examples of these methods: $ openssl s_client -ssl3 -connect 192.168.24.26:6080 CONNECTED(0003) ...snipped for brevity... --- SSL handshake has read 1816 bytes and written 298 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : SSLv3 Cipher: ECDHE-RSA-AES256-SHA Session-ID: F81B02A16309AACDF3019EA808A952C97E902D5A1BDA26CB47468B546B33BDC6 Session-ID-ctx: Master-Key: FA2990F148ACBAE3697B3D88E71BFAF7739642D844178C7AE220BC42B5EA67CA5A4ACD79824123C83FC7DAC4D848417C Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1567199209 Timeout : 7200 (sec) Verify return code: 0 (ok) --- ...snipped for brevity... $ nmap --script +ssl-enum-ciphers -p 6080 192.168.24.26 Starting Nmap 6.40 ( http://nmap.org ) at 2019-08-30 20:47 UTC Nmap scan report for overcloud-controller-0.ooo.test (192.168.24.26) Host is up (0.00010s latency). PORT STATE SERVICE 6080/tcp open unknown | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: strong Expected result === Insecure protocols such as SSLv3 and TLS1.0 should not succeed for connections via 'openssl s_client', and insecure ciphers should not be listed, or it should be possible to disable ciphers/protocols such as there for the console proxies. We utilize websockify underneath our console proxies, which added support for allowed ciphers and protocol versions to be configurable as of version 0.9.0. If we update the websockify version we require, the TLS cipher and protocol settings could be conf
[Yahoo-eng-team] [Bug 1523646] Re: Nova/Cinder Key Manager for Barbican Uses Stale Cache
This issue has been published as OSSN-0063 on the mailing lists and
wiki:
https://wiki.openstack.org/wiki/OSSN/OSSN-0063
** Changed in: ossn
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1523646
Title:
Nova/Cinder Key Manager for Barbican Uses Stale Cache
Status in castellan:
Fix Released
Status in Cinder:
Fix Released
Status in Cinder liberty series:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) liberty series:
Fix Committed
Status in OpenStack Security Notes:
Fix Released
Bug description:
The Key Manger for Barbican, implemented in Nova and Cinder, caches a value
of barbican_client to save extra
calls to Keystone for authentication. However, the cached value of
barbican_client is only valid for the current
context. A check needs to be made to ensure the context has not changed
before using the saved value.
The symptoms for using a stale cache value include getting the following
error message when creating
an encrypted volume.
From CLI:
---
openstack volume create --size 1 --type LUKS encrypted_volume
The server has either erred or is incapable of performing the requested
operation. (HTTP 500) (Request-ID: req-aea6be92-020e-41ed-ba88-44a1f5235ab0)
In cinder.log
---
2015-12-03 09:09:03.648 TRACE cinder.volume.api Traceback (most recent call
last):
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py",
line 82, in _exe
cute_task
2015-12-03 09:09:03.648 TRACE cinder.volume.api result =
task.execute(**arguments)
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/opt/stack/cinder/cinder/volume/flows/api/create_volume.py", line 409, in
execute
2015-12-03 09:09:03.648 TRACE cinder.volume.api source_volume)
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/opt/stack/cinder/cinder/volume/flows/api/create_volume.py", line 338, in
_get_encryption_key_
id
2015-12-03 09:09:03.648 TRACE cinder.volume.api encryption_key_id =
key_manager.create_key(context)
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/opt/stack/cinder/cinder/keymgr/barbican.py", line 147, in create_key
2015-12-03 09:09:03.648 TRACE cinder.volume.api LOG.exception(_LE("Error
creating key."))
….
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 502, in post
2015-12-03 09:09:03.648 TRACE cinder.volume.api return self.request(url,
'POST', **kwargs)
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/usr/lib/python2.7/site-packages/keystoneclient/utils.py", line 337, in inner
2015-12-03 09:09:03.648 TRACE cinder.volume.api return func(*args,
**kwargs)
2015-12-03 09:09:03.648 TRACE cinder.volume.api File
"/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 402, in
request
2015-12-03 09:09:03.648 TRACE cinder.volume.api raise
exceptions.from_response(resp, method, url)
2015-12-03 09:09:03.648 TRACE cinder.volume.api Unauthorized: The request you
have made requires authentication. (Disable debug mode to suppress these
details.) (HTTP 401) (Request-ID: req-d2c52e0b-c16d-43ec-a7a0-763f1270)
To manage notifications about this bug go to:
https://bugs.launchpad.net/castellan/+bug/1523646/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1493448] Re: All operations are perfomed with admin priveleges when 'use_user_token' is False
This has been published as OSSN-0060: https://wiki.openstack.org/wiki/OSSN/OSSN-0060 ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1493448 Title: All operations are perfomed with admin priveleges when 'use_user_token' is False Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +--+--+ | Property | Value| +--+--+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.00 | | deleted | False| | deleted_at | None | | disk_format | qcow2| | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public| False| | min_disk | 0| | min_ram | 0| | name | private | | owner| e1cec705e33b4dfaaece11b623f3c680 | | protected| False| | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.00 | | virtual_size | None | +--+--+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--+-+-+--+--++ | ID | Name| Disk Format | Container Format | Size | Status | +--+-+-+--+--++ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--+-+-+--+--++ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--+-+-+--+--++ | ID | Name| Disk Format | Container Format | Size | Status | +--+-+-+--+--++ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | ak
[Yahoo-eng-team] [Bug 1490804] Re: PKI Token Revocation Bypass (CVE-2015-7546)
This issue has been published as OSSN-0062: https://wiki.openstack.org/wiki/OSSN/OSSN-0062 ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1490804 Title: PKI Token Revocation Bypass (CVE-2015-7546) Status in django-openstack-auth: Invalid Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Won't Fix Bug description: A keystone token which has been revoked can still be used by manipulating particular byte fields within the token. When a Keystone token is revoked it is added to the revoked list which stores the exact token value. Any API will look at the token to see whether or not it should accept a token. By changing a single byte within the token, the revocation can be bypassed. see the testing script [1]. It is suggested that the revocation should be changed to only check the token's inner ID. [1] http://paste.openstack.org/show/436516/ To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1516031] Re: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)
This issue has been published as OSSN-0061:
https://wiki.openstack.org/wiki/OSSN/OSSN-0061
** Changed in: ossn
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1516031
Title:
Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)
Status in Glance:
Triaged
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
This have been reported by Daniel P. Berrange:
"
In the OpenStack Liberty release, the Glance project added support for image
signature verification.
http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
signing-and-verification-support.html
The verification code was added in the following git commit
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e
Unfortunately the design of this signature verification method is flawed by
design.
The generalized approach to creating signatures of content is to apply
a hash to the content and then encrypt it in some manner. Consider
that the signature is defined to use hash=sha256 and cipher=rsa we can
describe the signature computation as
signature = rsa(sha256(content))
In the case of verifying a disk image, the content we care about
verifying is the complete disk image file. Unfortunately, the glance
specification chose *not* to compute the signature against the disk
image file. Glance already had an MD5 checksum calculated for the disk
image file, so they instead chose to compute the signature against the
MD5 checksum instead. ie glance is running
signature = rsa(sha256(md5(disk-image-content)))
This degrades the security of the system to that of the weakest hash,
which is obviously MD5 here.
The code where glance verifies the signature is in the
glance/locations.py, the 'set_data' method where is does
result = signature_utils.verify_signature(
self.context, checksum, self.image.extra_properties)
if result:
LOG.info(_LI("Successfully verified signature for image %s"),
self.image.image_id)
The 'checksum' variable is populate by the glance_store driver, but it
is hardcoded to always be md5 in all current glance storage backends:
$ git grep hashlib glance_store/_drivers/ | grep checksum
glance_store/_drivers/filesystem.py: checksum = hashlib.md5()
glance_store/_drivers/rbd.py: checksum = hashlib.md5()
glance_store/_drivers/s3.py: checksum = hashlib.md5()
glance_store/_drivers/s3.py: checksum = hashlib.md5()
glance_store/_drivers/sheepdog.py: checksum = hashlib.md5()
glance_store/_drivers/swift/store.py: checksum =
hashlib.md5()
glance_store/_drivers/vmware_datastore.py: self.checksum =
hashlib.md5()
Since we will soon be shipping OpenStack Liberty release, we need to at least
give a security notice to alert our customers to the fact that the signature
verification is cryptographically weak/broken. IMHO, it quite likely deserves a
CVE though
NB, this is public knowledge as I first became aware of this flawed
design in comments / discussion on a public specification proposed to
implement the same approach in the Nova project.
My suggested way to fix this is to simply abandon the current impl and
re-do it such that it directly computes the signature against the
disk image, and does not use the existing md5 checksum in any way.
Regards,
Daniel
"
Mailing list thread for Nova impl:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html
Nova Spec: https://review.openstack.org/#/c/188874/
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1516031/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1451931] Re: ironic password config not marked as secret
This has been published as OSSN-0049: https://wiki.openstack.org/wiki/OSSN/OSSN-0049 ** Changed in: ossn Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1451931 Title: ironic password config not marked as secret Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The ironic config option for the password and auth token are not marked as secret so the values will get logged during startup in debug mode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451931/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1456228] Re: Trusted vm can be powered on untrusted host
This has been published as OSSN-0059: https://wiki.openstack.org/wiki/OSSN/OSSN-0059 ** Changed in: ossn Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1456228 Title: Trusted vm can be powered on untrusted host Status in OpenStack Compute (nova): Invalid Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This is related to the trusted compute. I recently setup trusted compute pool in my company and have observed that although new trusted vm is not able to be launched from an untrusted host, but if an trusted vm that have launched earlier on a trusted host which is compromised later on, that VM can still be powered on. 1. Exact version of Nova/Openstack: [root@grunt2 ~]# rpm -qa | grep nova python-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-network-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-compute-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-conductor-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-cells-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-api-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-console-2014.1.2-100+45c2cbc.fc20.noarch python-novaclient-2.17.0-2.fc21.noarch openstack-nova-cert-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-scheduler-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-objectstore-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-common-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-novncproxy-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-doc-2014.1.2-100+45c2cbc.fc20.noarch 2. Relevant log files: this is not a error, don't think logs will help.. 3. Reproduce steps: * create trusted compute pool with only one compute node * create an trusted VM on that compute node * compromise the trusted compute node by changing the boot order * power on the trusted Vm created earlier. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1456228/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1515302] [NEW] Group membership attribute is hard-coded when using 'user_enable_emulation'
Public bug reported:
The 'group_member_attribute' is used in Keystone when looking for groups
in LDAP to find membership. But, when using 'user_enable_emulation', the
following code in keystone/common/ldap/core.py instead references a hard
coded 'member' entry instead of 'group_member_attribute'.
---
def _get_enabled(self, object_id):
dn = self._id_to_dn(object_id)
query = '(member=%s)' % dn < Here
with self.get_connection() as conn:
try:
enabled_value =
conn.search_s(self.enabled_emulation_dn,
ldap.SCOPE_BASE,
query, ['cn'])
except ldap.NO_SUCH_OBJECT:
return False
else:
return bool(enabled_value)
---
As a result, when integrating Keystone with an LDAP back-end and using
the 'enabled_user_emulation' feature with a group for which the
membership attribute is 'uniquemember', users are listed as not enabled.
** Affects: keystone
Importance: Undecided
Assignee: Nathan Kinder (nkinder)
Status: New
** Changed in: keystone
Assignee: (unassigned) => Nathan Kinder (nkinder)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1515302
Title:
Group membership attribute is hard-coded when using
'user_enable_emulation'
Status in OpenStack Identity (keystone):
New
Bug description:
The 'group_member_attribute' is used in Keystone when looking for
groups in LDAP to find membership. But, when using
'user_enable_emulation', the following code in
keystone/common/ldap/core.py instead references a hard coded 'member'
entry instead of 'group_member_attribute'.
---
def _get_enabled(self, object_id):
dn = self._id_to_dn(object_id)
query = '(member=%s)' % dn < Here
with self.get_connection() as conn:
try:
enabled_value =
conn.search_s(self.enabled_emulation_dn,
ldap.SCOPE_BASE,
query, ['cn'])
except ldap.NO_SUCH_OBJECT:
return False
else:
return bool(enabled_value)
---
As a result, when integrating Keystone with an LDAP back-end and using
the 'enabled_user_emulation' feature with a group for which the
membership attribute is 'uniquemember', users are listed as not
enabled.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1515302/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1401170] Re: 0-size images allow unprivileged user to deplete glance resources
This has been published as OSSN-0057:
https://wiki.openstack.org/wiki/OSSN/OSSN-0057
** Changed in: ossn
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1401170
Title:
0-size images allow unprivileged user to deplete glance resources
Status in Glance:
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
Glance allows to create 0-size images ('glance image-create' without
parameters). Those images do not consume resources of storage backend
and do not hit any limits for size, but take up space in database.
Malicious user can cause database resource depletion with endless
flood of 'image-create' requests. Because an empty request is small
it will cause more strain on openstack than on the attacker.
RateLimit on API requests allows to delay consequences of attack, but
does not prevent it.
Here is simple script to run attack:
while true;do curl -i -X POST -H 'X-Auth-Token: ***'
http://glance-endpoint:9292/v1/images;done
My estimation for database growth is about 1Mb/minute (with extra-
slow shell-based attack, but a specially crafted script will allow to
run it with RateLimit speed).
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1401170/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1455582] Re: Hypervisor compromise may result in malicious trust creation
This has been published as OSSN-0053: https://wiki.openstack.org/wiki/OSSN/OSSN-0053 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1455582 Title: Hypervisor compromise may result in malicious trust creation Status in Keystone: Confirmed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a hypervisor is compromised, and the hypervisor is a a Nova compute node, the end user now has access to every token that passes through that node. By default, a keystone token can be exchanged for another token. There is no restriction on scoping of the new token. A scoped token can be exchanged for an unscoped token, or a token scoped to a different project. We had set the default time limit for tokens down to 1 hour, to reduce the surface area of the attack. However, many workloads require a single token for the whole workload, and these workloads take more than one hour, so several installations have increased token lifespans back to the old value of 24 hours. A token can be used to change a password. If this is done, all tokens are revoked for the user. With the trust API, a user can set up a long term delegation that allows another user to perform an operation on their behalf. While tokens created via trusts are limited in what they can do, the limitations are only on things like change passwords or create a new token. Thus, if an attacker compromises a compute node and harvests tokens, the highest value attack for them is to automatically create a trust from the compromised user to some other account. This bypasses the time limitation of the token expiration, and will allow the attacker to perform operations on the users resources at the attackers convenience. Any site that is running a recent version of Heat would be expected to have many trusts set up from the customer user accounts to the Heat service user. Heat creates trusts using the users tokens, so we know this approach is not just theoretical, but actively used. This leaves a fairly obvious trail, in that a user can see all of the trusts created with the user as the trustor. Any trusts that do not have a Heat user as the trustee are suspect. It might even be possible to compromise Heat users, so even those should be audited. There are other ways that a harvested token can be abused, but the trust approach is the one I find the most worrysome, as it could be done as a "sleeper" agent. The same issues apply to the OAUTH1.0a extension. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack
This has been published as OSSN-0054:
https://wiki.openstack.org/wiki/OSSN/OSSN-0054
** Changed in: ossn
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1457551
Title:
Another Horizon login page vulnerability to a DoS attack
Status in OpenStack Dashboard (Horizon):
Won't Fix
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
This bug is very similar to: https://bugs.launchpad.net/bugs/1394370
Steps to reproduce:
1) Setup Horizon to use db as session engine (using this doc:
http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html).
I've used MySQL.
2) Run 'for i in {1..100}; do curl -b "sessionid=a;"
http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal.
I've got 100 rows in django_session after this.
I've used devstack installation just with updated master branch.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1464750] Re: Service accounts can be used to login horizon
This has been published as OSSN-0055: https://wiki.openstack.org/wiki/OSSN/OSSN-0055 ** Changed in: ossn Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1390124] Re: No validation between client's IdP and Keystone IdP
This has been published as OSSN-0047: https://wiki.openstack.org/wiki/OSSN/OSSN-0047 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1390124 Title: No validation between client's IdP and Keystone IdP Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: With today's configuration there is no strict link between federated assertion issued by a trusted IdP and a IdP configured inside Keystone. Hence, user has ability to choose a mapping and possibly get unauthorized access. Proposed solution: setup a IdP identified included in an assertion issued by a IdP and validate whether that both values are equal. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1390124/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1414532] Re: asserts used in cache.py
This has been published as OSSN-0048:
https://wiki.openstack.org/wiki/OSSN/OSSN-0048
** Changed in: ossn
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1414532
Title:
asserts used in cache.py
Status in OpenStack Image Registry and Delivery Service (Glance):
Fix Released
Status in OpenStack Security Advisories:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
The asserts in the snippet below check at #2 to see if the HTTP method
match the HTTP methods actually specified in the patterns at #1.
/opt/stack/glance/glance/api/middleware/cache.py
PATTERNS = { <--- #1
('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'),
('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'),
('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'),
('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$')
}
...
@staticmethod
def _match_request(request):
"""Determine the version of the url and extract the image id
:returns tuple of version and image id if the url is a
cacheable,
otherwise None
"""
for ((version, method), pattern) in PATTERNS.items():
match = pattern.match(request.path_info)
try:
assert request.method == method <--- #2
image_id = match.group(1)
# Ensure the image id we got looks like an image id to
filter
# out a URI like /images/detail. See LP Bug #879136
assert image_id != 'detail'
except (AttributeError, AssertionError):
continue
else:
return (version, method, image_id)
As stated in the Python documentation assert statements will not be evaluated
when the Python code is compiled with optimization flags. This means that
these
checks will not be properly executed and one can in that case call a specific
method with a completely different HTTP verb. This can result in security
issues.
For example think of having some filtering in place in front of the glance API
to maybe allow only certain API queries to come from certain IP addresses. For
example: 'the HTTP verb DELETE may only be executed from this IP range'. An
attacker can now specify a completely different HTTP verb such as GET and make
sure he still matches regular expressions at #1 and then bypass the firewall.
It's a bit of a hypothetical scenario but in general one should never ever do
error checking with assert statemetns. This should only be done for things
which can never realistically fail and that is simply not an assumption one
can
hold when it comes to untrusted input from the network.
For more information see
https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and
https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE
This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354
but it's not fixed and maybe it should even be a security issue hence why I
reported it again and tagged as a security vulnerability. I am not familiar
enough with the code base to make that call.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440185] [NEW] Identity provider create fails if remote_id is not set
Public bug reported:
When support for multiple remote_ids was added
(https://review.openstack.org/#/c/152156/), a prolem was introduced
where Keystone will return a 400 response when an identity provider is
created without a remote_id. The remote_id is supposed to be optional.
Here is what the problem looks like using python-openstackclient:
[root@rdo ~]# openstack --os-auth-url http://rdo.rdodom.test:5000/v3
--os-user-domain-name default \
--os-username admin --os-password password --os-project-domain-name default
--os-project-name admin \
--os-identity-api-version 3 identity provider create --enable test
ERROR: openstack 'NoneType' object is not iterable (HTTP 400) (Request-ID:
req-172efcf5-6e1b-4059-99f1-44acb069067a)
The problem is that the dict that is passed into
IdentityProviderModel.from_dict() looks like this:
{u'enabled': True, u'description': None, u'remote_ids': None}
We pop the 'remote_ids' item from the dict to create remote_ids_list,
but this results in the list being None. We then try to iterate the
list, which triggers an exception that leads to the 400 error. We need
to fix the way we initialize the list.
** Affects: keystone
Importance: Undecided
Assignee: Nathan Kinder (nkinder)
Status: In Progress
** Changed in: keystone
Assignee: (unassigned) => Nathan Kinder (nkinder)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1440185
Title:
Identity provider create fails if remote_id is not set
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
When support for multiple remote_ids was added
(https://review.openstack.org/#/c/152156/), a prolem was introduced
where Keystone will return a 400 response when an identity provider is
created without a remote_id. The remote_id is supposed to be
optional. Here is what the problem looks like using python-
openstackclient:
[root@rdo ~]# openstack --os-auth-url http://rdo.rdodom.test:5000/v3
--os-user-domain-name default \
--os-username admin --os-password password --os-project-domain-name
default --os-project-name admin \
--os-identity-api-version 3 identity provider create --enable test
ERROR: openstack 'NoneType' object is not iterable (HTTP 400) (Request-ID:
req-172efcf5-6e1b-4059-99f1-44acb069067a)
The problem is that the dict that is passed into
IdentityProviderModel.from_dict() looks like this:
{u'enabled': True, u'description': None, u'remote_ids': None}
We pop the 'remote_ids' item from the dict to create remote_ids_list,
but this results in the list being None. We then try to iterate the
list, which triggers an exception that leads to the 400 error. We
need to fix the way we initialize the list.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440185/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1434701] [NEW] websso should compare remote_id_attribute to remote_id of IdP
Public bug reported:
When using the websso feature in keystone, the identity provider is
looked up based on the value of the 'remote_id_attribute' environment
variable provided by the SAML assertion (or claim in the case of OpenID
Connect). Logic would dictate that the 'remote_id_attribute' value is
searched for against the 'remote_id' field in the backend where identity
providers are stored. This is not the case. Here is an example from
my test environment:
When hitting http://rdo.rdodom.test:5000/v3/auth/OS-
FEDERATION/websso/saml2?origin=http%3A//rdo.rdodom.test:
{"error": {"message": "Could not find Identity Provider:
https://ipa.rdodom.test/idp/saml2/metadata";, "code": 404, "title": "Not
Found"}}
This message contains the value of my 'remote_id_attribute' from the
assertion. This value is 'https://ipa.rdodom.test/idp/saml2/metadata'.
The identity provider looks like this:
[root@rdo ~(keystone_v3_admin)]$ openstack identity provider show ipsilon
+-++
| Field | Value |
+-++
| description | None |
| enabled | True |
| id | ipsilon|
| remote_id | https://ipa.rdodom.test/idp/saml2/metadata |
+-++
You can see that the remote_id matches the value that my assertion
contains.
My keystone.conf has this:
remote_id_attribute = MELLON_IDP
trusted_dashboard = http://rdo.rdodom.test
Keystone is currently looking up the identity provider by trying to
match the value from the 'remote_id_attribute' to the 'id' field of the
identity provider in keystone. This seems wrong.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1434701
Title:
websso should compare remote_id_attribute to remote_id of IdP
Status in OpenStack Identity (Keystone):
New
Bug description:
When using the websso feature in keystone, the identity provider is
looked up based on the value of the 'remote_id_attribute' environment
variable provided by the SAML assertion (or claim in the case of
OpenID Connect). Logic would dictate that the 'remote_id_attribute'
value is searched for against the 'remote_id' field in the backend
where identity providers are stored. This is not the case. Here is
an example from my test environment:
When hitting http://rdo.rdodom.test:5000/v3/auth/OS-
FEDERATION/websso/saml2?origin=http%3A//rdo.rdodom.test:
{"error": {"message": "Could not find Identity Provider:
https://ipa.rdodom.test/idp/saml2/metadata";, "code": 404, "title":
"Not Found"}}
This message contains the value of my 'remote_id_attribute' from the
assertion. This value is
'https://ipa.rdodom.test/idp/saml2/metadata'. The identity provider
looks like this:
[root@rdo ~(keystone_v3_admin)]$ openstack identity provider show ipsilon
+-++
| Field | Value |
+-++
| description | None |
| enabled | True |
| id | ipsilon|
| remote_id | https://ipa.rdodom.test/idp/saml2/metadata |
+-++
You can see that the remote_id matches the value that my assertion
contains.
My keystone.conf has this:
remote_id_attribute = MELLON_IDP
trusted_dashboard = http://rdo.rdodom.test
Keystone is currently looking up the identity provider by trying to
match the value from the 'remote_id_attribute' to the 'id' field of
the identity provider in keystone. This seems wrong.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1434701/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1420942] Re: noVNC insecure cookie allows session hijacking
This has been published as OSSN-0044: https://wiki.openstack.org/wiki/OSSN/OSSN-0044 ** Changed in: ossn Status: New => Fix Released ** Changed in: ossn Assignee: (unassigned) => Paul McMillan (paul-mcmillan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1420942 Title: noVNC insecure cookie allows session hijacking Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable. The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic. The setup is as follows: Nova and horizon configured to serve from https. Nova is patched to resolve #1409142. User is accessing the cloud through a man in the middle who controls all traffic to and from the user. [1] user -> attacker -> cloud(https) Here's what happens: 1) User logs into cloud securely via https://yourcloud.com/ 2) User securely accesses a server via websocket VNC and logs in. User (optionally) closes this window. 3) User opens a new browser tab to an insecure site (it can be any insecure site at all) 4) On receiving the request for the insecure site, the attacker fetches it from the source, and rewrites it to include an invisible attack iframe before serving it to the user. [2] 5) The attack iframe directs the user's browser to open http://yourcloud.com:6080 inside the hidden iframe (even if you don't serve that site insecurely) 6) When the user's browser requests http://yourcloud.com:6080, the attacker logs the request including the cookies, and responds with a blank page. 7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser. A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely. Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar. Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic: https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header -Paul [1] As a practical aside, it is easy to become this mitm on most local network segments, so users who connect to any network with any untrusted users are vulnerable. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses. [2] the attacker can actually do this step at any point in the process, even before step 1. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1420942/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1420942] Re: noVNC insecure cookie allows session hijacking
This should be marked as public now. As Tritan mentioned in comment#8, it's already been disclosed (not to mention that we already wrote and published an OSSN). ** Information type changed from Private Security to Public Security ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1420942 Title: noVNC insecure cookie allows session hijacking Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable. The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic. The setup is as follows: Nova and horizon configured to serve from https. Nova is patched to resolve #1409142. User is accessing the cloud through a man in the middle who controls all traffic to and from the user. [1] user -> attacker -> cloud(https) Here's what happens: 1) User logs into cloud securely via https://yourcloud.com/ 2) User securely accesses a server via websocket VNC and logs in. User (optionally) closes this window. 3) User opens a new browser tab to an insecure site (it can be any insecure site at all) 4) On receiving the request for the insecure site, the attacker fetches it from the source, and rewrites it to include an invisible attack iframe before serving it to the user. [2] 5) The attack iframe directs the user's browser to open http://yourcloud.com:6080 inside the hidden iframe (even if you don't serve that site insecurely) 6) When the user's browser requests http://yourcloud.com:6080, the attacker logs the request including the cookies, and responds with a blank page. 7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser. A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely. Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar. Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic: https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header -Paul [1] As a practical aside, it is easy to become this mitm on most local network segments, so users who connect to any network with any untrusted users are vulnerable. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses. [2] the attacker can actually do this step at any point in the process, even before step 1. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1420942/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker
This has been published as OSSN-0038 to the openstack and openstack-dev mailing lists as well as the wiki: https://wiki.openstack.org/wiki/OSSN/OSSN-0038 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Cinder havana series: Fix Released Status in Cinder icehouse series: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Fix Released Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1354512] Re: Anonymous user can download public image through Swift
This was published as OSSN-0025: https://wiki.openstack.org/wiki/OSSN/OSSN-0025 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1354512 Title: Anonymous user can download public image through Swift Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: 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 --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 /glance_/ 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. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1354512/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1384365] [NEW] Domain admin should be allowed to show their domain
Public bug reported: When using the policy.v3cloudsample.json, a domain admin (possessing the 'admin' role with a domain scoped token) is not allowed to show their own domain. This operation is restricted to the cloud admin: "identity:get_domain": "rule:cloud_admin" The admin of a domain should be allowed to view/show their own domain. ** Affects: keystone Importance: Undecided Assignee: Nathan Kinder (nkinder) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1384365 Title: Domain admin should be allowed to show their domain Status in OpenStack Identity (Keystone): In Progress Bug description: When using the policy.v3cloudsample.json, a domain admin (possessing the 'admin' role with a domain scoped token) is not allowed to show their own domain. This operation is restricted to the cloud admin: "identity:get_domain": "rule:cloud_admin" The admin of a domain should be allowed to view/show their own domain. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1384365/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1381809] [NEW] Domain aware policy shoule restrict certain operations to cloud admin
Public bug reported: The domain aware policy that is provided as a part of keystone (policy.v3cloudsample.json) attempts to define a few layers of administrative roles: cloud admin - responsible for overall cloud management domain admin - responsible for management within a domain project admin/owner - responsible for management of a project There are some APIs that should be restricted to the cloud admin, but they are currently allowed to any user with the "admin" role that is defined at any scope, such as the administrator of a project. Some examples are the region and federation APIs: - "identity:get_region": "", "identity:list_regions": "", "identity:create_region": "rule:admin_or_cloud_admin", "identity:update_region": "rule:admin_or_cloud_admin", "identity:delete_region": "rule:admin_or_cloud_admin", "identity:create_identity_provider": "rule:admin_required", "identity:list_identity_providers": "rule:admin_required", "identity:get_identity_providers": "rule:admin_required", "identity:update_identity_provider": "rule:admin_required", "identity:delete_identity_provider": "rule:admin_required", "identity:create_protocol": "rule:admin_required", "identity:update_protocol": "rule:admin_required", "identity:get_protocol": "rule:admin_required", "identity:list_protocols": "rule:admin_required", "identity:delete_protocol": "rule:admin_required", "identity:create_mapping": "rule:admin_required", "identity:get_mapping": "rule:admin_required", "identity:list_mappings": "rule:admin_required", "identity:delete_mapping": "rule:admin_required", "identity:update_mapping": "rule:admin_required", --- ** Affects: keystone Importance: Undecided Assignee: Nathan Kinder (nkinder) Status: New ** Changed in: keystone Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1381809 Title: Domain aware policy shoule restrict certain operations to cloud admin Status in OpenStack Identity (Keystone): New Bug description: The domain aware policy that is provided as a part of keystone (policy.v3cloudsample.json) attempts to define a few layers of administrative roles: cloud admin - responsible for overall cloud management domain admin - responsible for management within a domain project admin/owner - responsible for management of a project There are some APIs that should be restricted to the cloud admin, but they are currently allowed to any user with the "admin" role that is defined at any scope, such as the administrator of a project. Some examples are the region and federation APIs: - "identity:get_region": "", "identity:list_regions": "", "identity:create_region": "rule:admin_or_cloud_admin", "identity:update_region": "rule:admin_or_cloud_admin", "identity:delete_region": "rule:admin_or_cloud_admin", "identity:create_identity_provider": "rule:admin_required", "identity:list_identity_providers": "rule:admin_required", "identity:get_identity_providers": "rule:admin_required", "identity:update_identity_provider": "rule:admin_required", "identity:delete_identity_provider": "rule:admin_required", "identity:create_protocol": "rule:admin_required", "identity:update_protocol": "rule:admin_required", "identity:get_protocol": "rule:admin_required", "identity:list_protocols": "rule:admin_required", "identity:delete_protocol": "rule:admin_required", "identity:create_mapping": "rule:admin_required", "identity:get_mapping": "rule:admin_required", "identity:list_mappings": "rule:admin_required", "identity:delete_mapping": "rule:admin_required", "identity:update_mapping": "rule:admin_required", --- To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1381809/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1337349] Re: Nova qemu hypervisor host smbios serial number is leaked to guest
This issue has been published as OSSN-0028: https://wiki.openstack.org/wiki/OSSN/OSSN-0028 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1337349 Title: Nova qemu hypervisor host smbios serial number is leaked to guest Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Erwan Velu from eNovance reported a vulnerability in OpenStack Nova. The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak. The defect have been pinpointed to: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054 From a simple virtual machine, this may allow numerous info leak like: Allow compute hardware enumeration from guests Deduce service tag and get all hardware configuration Ability to know if two instances are on the same compute Dell hardware is particulary impacted as : - the uuid encodes the service tag - the service tag can be used on support site to determine: - detailled hardware configuration - date & country where the hw was shipped - date & type of support contract - amount of servers bought during this shipment If there is no use case for this, we should scrambled that piece of information. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1337349/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1376983] Re: v2.0 API does not work with httpd for admin interface
*** This bug is a duplicate of bug 1343579 ***
https://bugs.launchpad.net/bugs/1343579
** This bug has been marked a duplicate of bug 1343579
Versionless GET on keystone gives different answer with port 5000 and 35357
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1376983
Title:
v2.0 API does not work with httpd for admin interface
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
When Keystone is deployed in Apache httpd, v2.0 does not work for the
admin interface. Here is what I see when using httpd:
---
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/
{"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "http://127.0.0.1:35357/v3/";, "rel": "self"}]}]}}
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/v2.0
{"error": {"message": "Could not find version: v2.0", "code": 404, "title":
"Not Found"}}
---
Here are the results of same requests when running keystone-all with
the exact same configuration:
---
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/
{"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "http://127.0.0.1:35357/v3/";, "rel": "self"}]}, {"status": "stable",
"updated": "2014-04-17T00:00:00Z", "media-types": [{"base": "application/json",
"type": "application/vnd.openstack.identity-v2.0+json"}, {"base":
"application/xml", "type": "application/vnd.openstack.identity-v2.0+xml"}],
"id": "v2.0", "links": [{"href": "http://127.0.0.1:35357/v2.0/";, "rel":
"self"}, {"href": "http://docs.openstack.org/";, "type": "text/html", "rel":
"describedby"}]}]}}
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/v2.0
{"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z",
"media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v2.0+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v2.0+xml"}], "id": "v2.0", "links":
[{"href": "http://127.0.0.1:35357/v2.0/";, "rel": "self"}, {"href":
"http://docs.openstack.org/";, "type": "text/html", "rel": "describedby"}]}}
---
There's nothing really of interest in keystone.log with debug enabled.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1376983/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1376983] [NEW] v2.0 API does not work with httpd for admin interface
*** This bug is a duplicate of bug 1343579 ***
https://bugs.launchpad.net/bugs/1343579
Public bug reported:
When Keystone is deployed in Apache httpd, v2.0 does not work for the
admin interface. Here is what I see when using httpd:
---
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/
{"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "http://127.0.0.1:35357/v3/";, "rel": "self"}]}]}}
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/v2.0
{"error": {"message": "Could not find version: v2.0", "code": 404, "title":
"Not Found"}}
---
Here are the results of same requests when running keystone-all with the
exact same configuration:
---
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/
{"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "http://127.0.0.1:35357/v3/";, "rel": "self"}]}, {"status": "stable",
"updated": "2014-04-17T00:00:00Z", "media-types": [{"base": "application/json",
"type": "application/vnd.openstack.identity-v2.0+json"}, {"base":
"application/xml", "type": "application/vnd.openstack.identity-v2.0+xml"}],
"id": "v2.0", "links": [{"href": "http://127.0.0.1:35357/v2.0/";, "rel":
"self"}, {"href": "http://docs.openstack.org/";, "type": "text/html", "rel":
"describedby"}]}]}}
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/v2.0
{"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z",
"media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v2.0+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v2.0+xml"}], "id": "v2.0", "links":
[{"href": "http://127.0.0.1:35357/v2.0/";, "rel": "self"}, {"href":
"http://docs.openstack.org/";, "type": "text/html", "rel": "describedby"}]}}
---
There's nothing really of interest in keystone.log with debug enabled.
** Affects: keystone
Importance: Undecided
Assignee: Nathan Kinder (nkinder)
Status: In Progress
** Changed in: keystone
Status: New => In Progress
** Changed in: keystone
Assignee: (unassigned) => Nathan Kinder (nkinder)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1376983
Title:
v2.0 API does not work with httpd for admin interface
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
When Keystone is deployed in Apache httpd, v2.0 does not work for the
admin interface. Here is what I see when using httpd:
---
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/
{"versions": {"values": [{"status": "stable", "updated":
"2013-03-06T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}, {"base": "application/xml",
"type": "application/vnd.openstack.identity-v3+xml"}], "id": "v3.0", "links":
[{"href": "http://127.0.0.1:35357/v3/";, "rel": "self"}]}]}}
[rhosuser@rhos ~]$ curl http://127.0.0.1:35357/v2.0
{"error"
[Yahoo-eng-team] [Bug 1376053] [NEW] user_enabled_invert does not properly handle string values
Public bug reported:
The user_enabled_invert setting is supposed to invert the meaning of
True/False for the user enabled attribute. This makes "lock" attributes
useful, where "False" indicates that an account is not locked.
The invert logic expects that we have a bool type that we then invert
using 'not' in this snippet of code from UserApi._ldap_res_to_model:
elif self.enabled_invert and not self.enabled_emulation:
enabled = obj.get('enabled', self.enabled_default)
obj['enabled'] = not enabled
The problem is that we get a bool trype from the default value, and a
str type from LDAP. Evaluating a string with 'not' will be False for
any non-empty string. This means that we will fail to invert a string
of "False" that is returned from LDAP, leading to accounts being
inadvertently disabled. This code needs to handle converting a str type
to bool before inverting the value.
** Affects: keystone
Importance: Medium
Assignee: Nathan Kinder (nkinder)
Status: In Progress
** Tags: juno-rc-potential
** Tags added: juno-rc-candidate
** Changed in: keystone
Status: New => In Progress
** Changed in: keystone
Assignee: (unassigned) => Nathan Kinder (nkinder)
** Summary changed:
- user_enabled_invert does notproperly handle string values
+ user_enabled_invert does not properly handle string values
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1376053
Title:
user_enabled_invert does not properly handle string values
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
The user_enabled_invert setting is supposed to invert the meaning of
True/False for the user enabled attribute. This makes "lock"
attributes useful, where "False" indicates that an account is not
locked.
The invert logic expects that we have a bool type that we then invert
using 'not' in this snippet of code from UserApi._ldap_res_to_model:
elif self.enabled_invert and not self.enabled_emulation:
enabled = obj.get('enabled', self.enabled_default)
obj['enabled'] = not enabled
The problem is that we get a bool trype from the default value, and a
str type from LDAP. Evaluating a string with 'not' will be False for
any non-empty string. This means that we will fail to invert a string
of "False" that is returned from LDAP, leading to accounts being
inadvertently disabled. This code needs to handle converting a str
type to bool before inverting the value.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1376053/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1004114] Re: Password logging
This was published as OSSN-0024: https://wiki.openstack.org/wiki/OSSN/OSSN-0024 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning
This was published as OSSN-0027: https://wiki.openstack.org/wiki/OSSN/OSSN-0027 ** Changed in: ossn Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1373599] [NEW] Trust operations in policy.json are misleading
Public bug reported:
The sample policy.json files included in Keystone have the trust API
operations listed. For example:
"identity:create_trust": "user_id:%(trust.trustor_user_id)s",
"identity:get_trust": "rule:admin_or_owner",
"identity:list_trusts": "",
"identity:list_roles_for_trust": "",
"identity:check_role_for_trust": "",
"identity:get_role_for_trust": "",
"identity:delete_trust": "",
This implies that these trust operations are protected by policy, which
is true but misleading. While policy does protect these operations,
they are hardcoded to be very restrictive. Here are some examples from
the controller code:
--
@controller.protected()
def delete_trust(self, context, trust_id):
trust = self.trust_api.get_trust(trust_id)
if not trust:
raise exception.TrustNotFound(trust_id=trust_id)
user_id = self._get_user_id(context)
_admin_trustor_only(context, trust, user_id)
self.trust_api.delete_trust(trust_id)
@controller.protected()
def list_roles_for_trust(self, context, trust_id):
trust = self.get_trust(context, trust_id)['trust']
if not trust:
raise exception.TrustNotFound(trust_id=trust_id)
user_id = self._get_user_id(context)
_trustor_trustee_only(trust, user_id)
return {'roles': trust['roles'],
'links': trust['roles_links']}
--
In the trust controller code, the following restrictions are currently
hard-coded:
create_trust - trustor only
get_trust - trustor or trustee only
l ist_trusts - admin only to list all trusts, trustor or trustee only for
related trusts
list_roles_for_trust - trustor or trustee only
check_role_for_trust - trustor or trustee only
get_role_for_trust - trustor or trustee only (indirectly via
check_role_for_trust)
delete_trust - admin or trustor only
The policies in policy.json can make these operations more restricted,
but not less restricted than the hard-coded restrictions. We can't
simply remove these settings from policy.json, as that would cause the
"default" rule to be used which makes trusts unusable in the case of the
default "default" rule of "admin_required". This only leaves us with
the option of clearly documenting the behavior IMHO. Unfortunately,
JSON doesn't allow comments, so we can't just add nice comments right
there in policy.json. I think that the correct approach is:
- Add a general purpose paragraph to the RBAC section of
doc/source/configuration.rst that states that some operations have hard-
coded restrictions that policy is unable to circumvent. Mention that
policy can still make these operations more restrictive.
- Add documentation for the trust extension at
keystone/doc/source/extensions/trust.rst that mentions the hard-coded
restrictions for each trust operation. Documentation for the trust
extension in this area is completely missing at this time.
** Affects: keystone
Importance: Undecided
Status: Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1373599
Title:
Trust operations in policy.json are misleading
Status in OpenStack Identity (Keystone):
Confirmed
Bug description:
The sample policy.json files included in Keystone have the trust API
operations listed. For example:
"identity:create_trust": "user_id:%(trust.trustor_user_id)s",
"identity:get_trust": "rule:admin_or_owner",
"identity:list_trusts": "",
"identity:list_roles_for_trust": "",
"identity:check_role_for_trust": "",
"identity:get_role_for_trust": "",
"identity:delete_trust": "",
This implies that these trust operations are protected by policy,
which is true but misleading. While policy does protect these
operations, they are hardcoded to be very restrictive. Here are some
examples from the controller code:
--
@controller.protected()
def delete_trust(self, context, trust_id):
trust = self.trust_api.get_trust(trust_id)
if not trust:
raise exception.TrustNotFound(trust_id=trust_id)
user_id = self._get_user_id(context)
_admin_trustor_only(context, trust, user_id)
self.trust_api.delete_trust(trust_id)
@controller.protected()
def list_roles_for_trust(self, context, trust_id):
trust = self.get_trust(context, trust_id)['trust']
if not trust:
raise exception.TrustNotFound(trust_id=trust_id)
user_id = self._get_user_id(context)
_trustor_trustee_only(trust, user_id)
return {'roles': trust['roles'],
'links': trust['roles_links']}
--
[Yahoo-eng-team] [Bug 1365961] Re: Dangerous iptables rule generated in case of protocol "any" and source-port/destination-port usage
The security note for this issue has been published as OSSN-0029: https://wiki.openstack.org/wiki/OSSN/OSSN-0029 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1365961 Title: Dangerous iptables rule generated in case of protocol "any" and source-port/destination-port usage Status in OpenStack Neutron (virtual network service): Fix Committed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Icehouse 2014.1.2, FWaas using iptables driver In order to allow DNS (TCP and UDP) request, the following rule was defined: neutron firewall-rule-create --protocol any --destination-port 53 --action allow On L3agent namespace this has been translated in the following iptables rules: -A neutron-l3-agent-iv441c58eb2 -j ACCEPT -A neutron-l3-agent-ov441c58eb2 -j ACCEPT => there is no restriction on the destination port(53), like we could expect it !!! There is 2 solutions to handle this issue: 1) Doesn't allow user to create a rule specifing protocol "any" AND a source-port/destination-port. 2) Generating the following rules (like some firewalls do): -A neutron-l3-agent-iv441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT -A neutron-l3-agent-iv441c58eb2 -p udp -m udp --dport 53 -j ACCEPT -A neutron-l3-agent-ov441c58eb2 -p tcp -m tcp --dport 53 -j ACCEPT -A neutron-l3-agent-ov441c58eb2 -p udp -m udp --dport 53 -j ACCEPT => TCP and UDP have been completed. The source code affected is located in neutron/services/firewall/drivers/linux/iptables_fwaas.py (L268) def _port_arg(self, direction, protocol, port): if not (protocol in ['udp', 'tcp'] and port): return '' return '--%s %s' % (direction, port) => trunk code is affected too. Nota: This is not a real Neutron security vulnerability but it is a real security vulnerability for applications living in the Openstack cloud... That's why I tagged it as "security vulnerability" Regards, To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1365961/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1334926] Re: floatingip still working once connected even after it is disociated
This was published as OSSN-0020: https://wiki.openstack.org/wiki/OSSN/OSSN-0020 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present
This was published as OSSN-0022: https://wiki.openstack.org/wiki/OSSN/OSSN-0022 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1365712] Re: Command Execution Possible Through Config File Tampering
This is already covered by published note OSSN-0026: https://wiki.openstack.org/wiki/OSSN/OSSN-0026 ** Changed in: ossn Status: New => Fix Released ** Changed in: ossn Assignee: (unassigned) => Travis McPeak (travis-mcpeak) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1365712 Title: Command Execution Possible Through Config File Tampering Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The OpenStack Security Group has been reviewing OpenStack code to find potential security vulnerabilities. One class of these vulnerabilities is to allow someone with write access to nova.conf to cause code to be executed as the OpenStack user. Some details are here: https://review.openstack.org/#/c/118910/ More tracking information is here: https://bugs.launchpad.net/nova/+bug/1192971 This bug is specifically to address the possible vulnerability at nova/nova/virt/baremetal/ipmi.py:292 If a user has write access to nova.conf, he can set [baremetal] terminal = /bin/foo and cause /bin/foo to be executed. If a user has write access to nova.conf, he case set [baremetal] terminal_cert_dir = "; cat /etc/passwd" and cause the password file to be written to stdout. Some input validation would help correct this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1365712/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1348844] Re: Keystone logs auth tokens in URLs at log level info
This was published as OSSN-0023:
https://wiki.openstack.org/wiki/OSSN/OSSN-0023
** Changed in: ossn
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1348844
Title:
Keystone logs auth tokens in URLs at log level info
Status in OpenStack Identity (Keystone):
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
Example:
2014-07-25 22:28:25.352 1458 INFO eventlet.wsgi.server [-]
10.241.1.50,10.241.1.80 - - [25/Jul/2014 22:28:25] "GET
/v2.0/tokens/d5036612660543a3a9b8054c79dea8d3 HTTP/1.1" 200 3174
0.021630
We've found that this regex can catch all of these messages:
/v2.0/tokens/[\da-f]{32}
Keystone also logs a bunch of other sensitive data in debug level
messages, but this one it still present even if you only take info
level messages and above. We'd like to solve this problem at the
source instead of greping it out of our log files.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1348844/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1004114] Re: Password logging
We should write an OSSN for this so people are aware of the fact that passwords for users will be logged in Horizon if debug logging is enabled. Now that a keystoneclient patch has been merged, we will soon have a release that doesn't log passwords anymore. We should recommend using the newer keystoneclient as soon as it's available. ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossn Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: Fix Committed Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1347909] [NEW] Trust unit tests should target additional threat scenarios
Public bug reported: During the OpenStack Security Group Juno midcycle, some threat modelling work around Keystone trusts identified some threat scenarios that the existing unit tests do not cover. It should be made clear that these scenarios are handled correctly by Keystone form a security standpoint, but tests should be added to protect against regressions in these security sensitive areas. Scenario 1: - The first scenario is related to deletion of a grant that has been previously delegated via a trust. We need to ensure that executing a trust for a role that the trustor no longer has is rejected. For example, consider the following chain of events: - User A is granted 'somerole' on 'someproject'. - User A creates a trust to delegate 'somerole' on 'someproject' to User B. - The grant for 'somerole' on 'someproject' for user A is deleted. - User B attempts to execute the trust, which should be rejected. Scenario 2: - The second scenario is related to an attempt to use a trust token with impersonation to execute another trust as the impersonated user. We need to ensure that a trust token can't be used to execute another trust. For example, consider the following chain of events: - User A creates a trust to delegate some roles to User B. - User B creates a trust to delegate some roles to User C. - User C successfully executes the trust to impersonate User B. - User C uses the trust token that impersonates User B to attempt to execute the trust created by User A, which should be rejected. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1347909 Title: Trust unit tests should target additional threat scenarios Status in OpenStack Identity (Keystone): New Bug description: During the OpenStack Security Group Juno midcycle, some threat modelling work around Keystone trusts identified some threat scenarios that the existing unit tests do not cover. It should be made clear that these scenarios are handled correctly by Keystone form a security standpoint, but tests should be added to protect against regressions in these security sensitive areas. Scenario 1: - The first scenario is related to deletion of a grant that has been previously delegated via a trust. We need to ensure that executing a trust for a role that the trustor no longer has is rejected. For example, consider the following chain of events: - User A is granted 'somerole' on 'someproject'. - User A creates a trust to delegate 'somerole' on 'someproject' to User B. - The grant for 'somerole' on 'someproject' for user A is deleted. - User B attempts to execute the trust, which should be rejected. Scenario 2: - The second scenario is related to an attempt to use a trust token with impersonation to execute another trust as the impersonated user. We need to ensure that a trust token can't be used to execute another trust. For example, consider the following chain of events: - User A creates a trust to delegate some roles to User B. - User B creates a trust to delegate some roles to User C. - User C successfully executes the trust to impersonate User B. - User C uses the trust token that impersonates User B to attempt to execute the trust created by User A, which should be rejected. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1347909/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present
** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: New Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1337029] [NEW] Allow LDAP account lock attributes to be used as enable attributes
Public bug reported: Some LDAP servers support disabling accounts via a boolean "lock" attribute. For these servers, a value in LDAP of "True" means that the account is locked, while a value of "False" means the account is active. Keystone currently expects a boolean "enabled" attribute where "True" means the account is enabled and "False" means the account is disabled. To support LDAP account lock attributes, we need a way to tell Keystone that the boolean values from LDAP are inverted. This will avoid the need for an admin to create custom schema for a new "enabled" attribute or to use the emulated enabled group feature (which adds significant LDAP operation overhead as seen by packet capture). ** Affects: keystone Importance: Undecided Assignee: Nathan Kinder (nkinder) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1337029 Title: Allow LDAP account lock attributes to be used as enable attributes Status in OpenStack Identity (Keystone): In Progress Bug description: Some LDAP servers support disabling accounts via a boolean "lock" attribute. For these servers, a value in LDAP of "True" means that the account is locked, while a value of "False" means the account is active. Keystone currently expects a boolean "enabled" attribute where "True" means the account is enabled and "False" means the account is disabled. To support LDAP account lock attributes, we need a way to tell Keystone that the boolean values from LDAP are inverted. This will avoid the need for an admin to create custom schema for a new "enabled" attribute or to use the emulated enabled group feature (which adds significant LDAP operation overhead as seen by packet capture). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1337029/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1335437] [NEW] LDAP attributes mapped to None can cause 500 errors
Public bug reported: When LDAP is being used as a backend, attributes that are mapped to 'None' will trigger a 500 error if they are not also configured to be ignored. This can be easily reproduced by modifying the default config as follows: - # List of attributes stripped off the user on update. (list # value) #user_attribute_ignore=default_project_id,tenants user_attribute_ignore=tenants # LDAP attribute mapped to default_project_id for users. # (string value) #user_default_project_id_attribute= - If you then perform a 'keystone user-list', it will trigger a 500 error: - [root@keystone ~(keystone_admin)]# keystone user-list Authorization Failed: An unexpected error prevented the server from fulfilling your request. (HTTP 500) - The end of the stacktrace in keystone.log clearly shows the problem: - 2014-06-28 06:23:36.366 21931 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 502, in _ldap_res_to_model 2014-06-28 06:23:36.366 21931 TRACE keystone.common.wsgi v = lower_res[self.attribute_mapping.get(k, k).lower()] 2014-06-28 06:23:36.366 21931 TRACE keystone.common.wsgi AttributeError: 'NoneType' object has no attribute 'lower' - ** Affects: keystone Importance: Undecided Assignee: Nathan Kinder (nkinder) Status: In Progress ** Changed in: keystone Status: New => In Progress ** Changed in: keystone Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1335437 Title: LDAP attributes mapped to None can cause 500 errors Status in OpenStack Identity (Keystone): In Progress Bug description: When LDAP is being used as a backend, attributes that are mapped to 'None' will trigger a 500 error if they are not also configured to be ignored. This can be easily reproduced by modifying the default config as follows: - # List of attributes stripped off the user on update. (list # value) #user_attribute_ignore=default_project_id,tenants user_attribute_ignore=tenants # LDAP attribute mapped to default_project_id for users. # (string value) #user_default_project_id_attribute= - If you then perform a 'keystone user-list', it will trigger a 500 error: - [root@keystone ~(keystone_admin)]# keystone user-list Authorization Failed: An unexpected error prevented the server from fulfilling your request. (HTTP 500) - The end of the stacktrace in keystone.log clearly shows the problem: - 2014-06-28 06:23:36.366 21931 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 502, in _ldap_res_to_model 2014-06-28 06:23:36.366 21931 TRACE keystone.common.wsgi v = lower_res[self.attribute_mapping.get(k, k).lower()] 2014-06-28 06:23:36.366 21931 TRACE keystone.common.wsgi AttributeError: 'NoneType' object has no attribute 'lower' - To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1335437/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1334926] Re: floatingip still working once connected even after it is disociated
** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): New Status in OpenStack Security Notes: New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1271426] Re: protected property change not rejected if a subsequent rule match accepts them
The new revision of OSSN-0013 has been published to the mailing lists and the wiki: https://wiki.openstack.org/wiki/OSSN/OSSN-0013 ** Changed in: ossn Status: In Progress => Fix Released ** Changed in: ossn Assignee: Robert Clark (robert-clark) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1271426 Title: protected property change not rejected if a subsequent rule match accepts them Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance havana series: Fix Released Status in OpenStack Security Notes: Fix Released Bug description: See initial report here: http://lists.openstack.org/pipermail /openstack-dev/2014-January/024861.html What is happening is that if there is a specific rule that would reject an action and a less specific rule that comes after that would accept the action, then the action is being accepted. It should be rejected. This is because we iterate through the property protection rules rather than just finding the first match. This bug does not occur when policies are used to determine property protections, only when roles are used directly. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1271426/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1313746] Re: Non-admins can create public images
Published as OSSN-0015 on the wiki and the openstack and openstack-dev mailing lists: https://wiki.openstack.org/wiki/OSSN/OSSN-0015 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1313746 Title: Non-admins can create public images Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Glance documentation ( http://docs.openstack.org/developer/glance/glanceapi.html ) states: > Note Use of the is_public parameter is restricted to admin users. For all other users it will be ignored. However, this is not true on havana, ie. with horizon: - user a uploads an image with is_public checkbox **checked**, - user b logs in and can see that image in /project/images_and_snapshots/ It is reproducible with the command line of course: vagrant@precise64:/opt/stack/horizon$ glance --os-username aa --os-password aa --os-tenant-name aa --os-auth-url http://127.0.0.1:5000/v2.0 image-create --is-public True --name hacked --disk-format qcow2 --container-format bare --file cirros-0.3.2-x86_64-disk.img +--+--+ | Property | Value| +--+--+ | checksum | 64d7c1cd2b6f60c92c14662941cb7913 | | container_format | bare | | created_at | 2014-04-28T14:10:07 | | deleted | False| | deleted_at | None | | disk_format | qcow2| | id | 8f843998-d69f-42ee-90a2-24031aa8fe5b | | is_public| True | | min_disk | 0| | min_ram | 0| | name | hacked | | owner| c8df7a80acd44967a757ad1e346f3340 | | protected| False| | size | 13167616 | | status | active | | updated_at | 2014-04-28T14:10:07 | +--+--+ vagrant@precise64:/opt/stack/horizon$ glance --os-username bb --os-password bb --os-tenant-name bb --os-auth-url http://127.0.0.1:5000/v2.0 image-list +--+-+-+--+--++ | ID | Name| Disk Format | Container Format | Size | Status | +--+-+-+--+--++ | d6b482f7-7922-46f2-b501-11d18fb20f41 | cirros-0.3.1-x86_64-uec | ami | ami | 25165824 | active | | 5579dc39-06ba-4fa8-a9d9-b26d66e8a0b0 | cirros-0.3.1-x86_64-uec-kernel | aki | aki | 4955792 | active | | bdfc240a-2c6b-4511-bf72-0b5a9453a24a | cirros-0.3.1-x86_64-uec-ramdisk | ari | ari | 3714968 | active | | 8f843998-d69f-42ee-90a2-24031aa8fe5b | hacked | qcow2 | bare | 13167616 | active | +--+-+-+--+--++ Potentially, a malicious user could upload an image with a backdoor and make it available to the public. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1313746/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1271426] Re: protected property change not rejected if a subsequent rule match accepts them
Reopening this OSSN bug. The workaround in the OSSN has been reported to not work. Details from the reporter to come shortly. ** Changed in: ossn Status: Fix Released => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1271426 Title: protected property change not rejected if a subsequent rule match accepts them Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance havana series: Fix Released Status in OpenStack Security Notes: In Progress Bug description: See initial report here: http://lists.openstack.org/pipermail /openstack-dev/2014-January/024861.html What is happening is that if there is a specific rule that would reject an action and a less specific rule that comes after that would accept the action, then the action is being accepted. It should be rejected. This is because we iterate through the property protection rules rather than just finding the first match. This bug does not occur when policies are used to determine property protections, only when roles are used directly. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1271426/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1317314] Re: making an image public should be only admin by default
The OSSN for this is being handled in bug #1313746. Closing this as a duplicate. ** Changed in: ossn Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1317314 Title: making an image public should be only admin by default Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Notes: Won't Fix Bug description: Uploading an image with --is-public=True should by default only be allowed by the admin. Allowing anyone to upload an image as public is likely a security concern. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1317314/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1317314] Re: making an image public should be only admin by default
** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1317314 Title: making an image public should be only admin by default Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Notes: New Bug description: Uploading an image with --is-public=True should by default only be allowed by the admin. Allowing anyone to upload an image as public is likely a security concern. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1317314/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1271426] Re: protected property change not rejected if a subsequent rule match accepts them
This has been published as OSSN-0013 to the mailing lists (openstack and openstack-dev), and the OpenStack wiki: https://wiki.openstack.org/wiki/OSSN/OSSN-0013 ** Changed in: ossn Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1271426 Title: protected property change not rejected if a subsequent rule match accepts them Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance havana series: Fix Released Status in OpenStack Security Notes: Fix Released Bug description: See initial report here: http://lists.openstack.org/pipermail /openstack-dev/2014-January/024861.html What is happening is that if there is a specific rule that would reject an action and a less specific rule that comes after that would accept the action, then the action is being accepted. It should be rejected. This is because we iterate through the property protection rules rather than just finding the first match. This bug does not occur when policies are used to determine property protections, only when roles are used directly. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1271426/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1287219] Re: scope of domain admin too broad in v3 policy sample
Published as OSSN-0010 to the following locations:
openst...@lists.openstack.org
openstack-...@lists.openstack.org
https://wiki.openstack.org/wiki/OSSN/OSSN-0010
** Changed in: ossn
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1287219
Title:
scope of domain admin too broad in v3 policy sample
Status in OpenStack Identity (Keystone):
Fix Released
Status in OpenStack Security Advisories:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
Using the policies in the new default policy.v3cloudsample.json file,
a domain admin can easily elevate himself and become the cloud admin:
1) Get a token of a domain admin (a user with 'admin' role on any domain
other that the default domain which is the cloud admin's domain)
2) Grant yourself the admin role on the default domain which is the domain of
the cloud admin (PUT
/v3/domains/default/user//roles/
3) Change your domain_id to the id of the default domain (PATCH
/v3/users/ -d '"{user": {"domain_id": "default"}}'
4) Get a new token scoped to the default domain
==> You are now the cloud admin
It is expected that step number 2 should fail. Admins should be able
to grant roles only on their domain and their projects, not on other
projects. Otherwise, it is as if they are not really scoped at all.
NOTE: I am using the default policy.v3cloudsample.json file as is, unchanged.
I only defined the domain of the cloud admins to be the default domain by
editing this rule:
"cloud_admin": "rule:admin_required and domain_id:default",
I think that the default policy file should be changed to prevent
administrators' ability to grant roles on objects of foreign domains
(with the exception of admins in the domain defined by the cloud_admin
rule, of course).
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1287219/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1308793] [NEW] Remove LDAP password hashing code
Public bug reported: Keystone currently has code that hashes LDAP user passwords when creating and updating users (using salted SHA-1). Keystone itself should not be doing this hashing. The LDAP server itself is supposed to receive the clear text "userPassword" attribute value so it can hash it itself. This hashing may or may not be using salted SHA-1 depending on the LDAP server implementation or password policy configuration. In addition, some LDAP server implementations may even refuse to accept pre-hashed passwords. The proper behavior is to just pass the clear-text password off to the LDAP server as a part of the LDAP add or modify operation. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1308793 Title: Remove LDAP password hashing code Status in OpenStack Identity (Keystone): New Bug description: Keystone currently has code that hashes LDAP user passwords when creating and updating users (using salted SHA-1). Keystone itself should not be doing this hashing. The LDAP server itself is supposed to receive the clear text "userPassword" attribute value so it can hash it itself. This hashing may or may not be using salted SHA-1 depending on the LDAP server implementation or password policy configuration. In addition, some LDAP server implementations may even refuse to accept pre-hashed passwords. The proper behavior is to just pass the clear-text password off to the LDAP server as a part of the LDAP add or modify operation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1308793/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1268751] Re: Potential token revocation abuse via group membership
An OSSN on this issue has been published to the wiki, openstack-dev, and openstack mailing lists: http://git.openstack.org/cgit/openstack/openstack-security- notes/commit/?id=5380798f052eaebc023271c90d65b8f6d6fa6331 https://wiki.openstack.org/w/index.php?title=OSSN/OSSN-0009&action=edit&redlink=1 ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1268751 Title: Potential token revocation abuse via group membership Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a group is deleted, all tokens for all users that are a member of that group are revoked. This leads to potential abuse: 1. A group admin adds a user to a group without users knowledge 2. User creates token 3. Admin deletes group. 4. All of the users tokens are revoked. Admittedly, this abuse must be instigated by a group admin, which is the global admin in the default policy file, but an alternative policy file could allow for the delegation of "add user to group" behavior. In such a system, this could act as a denial of service attack for a set of users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268751/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1300982] Re: No headers in REST API auth request results in HTTP 500
I just attempted to reproduce this on a Havana install, and it seems to
report an appropriate response/error:
-
# curl -v -A "" -H "Host:" -H "Accept:" -H "Content-Type:" -d @/tmp/request.txt
"http://10.0.1.7:35357/v2.0/tokens";
* About to connect() to 10.0.1.7 port 35357 (#0)
* Trying 10.0.1.7... connected
* Connected to 10.0.1.7 (10.0.1.7) port 35357 (#0)
> POST /v2.0/tokens HTTP/1.1
> Content-Length: 103
>
< HTTP/1.1 400 Bad Request
< Vary: X-Auth-Token
< Content-Type: application/json
< Content-Length: 257
< Date: Wed, 02 Apr 2014 02:22:51 GMT
<
* Connection #0 to host 10.0.1.7 left intact
* Closing connection #0
{"error": {"message": "Expecting to find application/json in Content-Type
header. The server could not comply with the request since it is either
malformed or otherwise incorrect. The client is assumed to be in error.",
"code": 400, "title": "Bad Request"}}
-
I think we can go ahead and close this as "Invalid". Apologies for the
noise.
** Changed in: keystone
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1300982
Title:
No headers in REST API auth request results in HTTP 500
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
REQ to http://host.example.com:35357/v2.0/tokens:
{"auth":{"passwordCredentials":{"username": "admin", "password":"***"},
"tenant":"admin"}}
RESP:
Status Code: 500 Internal Server Error
Connection: keep-alive
Content-Length: 266
Content-Type: application/xml
Date: Wed, 11 Jul 2012 13:41:34 GMT
Vary: X-Auth-Token
http://docs.openstack.org/identity/api/v2.0"; message="An
unexpected error prevented the server from fulfilling your request. argument of
type 'NoneType' is not iterable" code="500" title="Internal Server Error"/>
Adding header "Content-type: application/json" fixes the problem.
It would be nice to improve the return code/error message.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1300982/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1300982] [NEW] No headers in REST API auth request results in HTTP 500
Public bug reported:
REQ to http://host.example.com:35357/v2.0/tokens:
{"auth":{"passwordCredentials":{"username": "admin", "password":"***"},
"tenant":"admin"}}
RESP:
Status Code: 500 Internal Server Error
Connection: keep-alive
Content-Length: 266
Content-Type: application/xml
Date: Wed, 11 Jul 2012 13:41:34 GMT
Vary: X-Auth-Token
http://docs.openstack.org/identity/api/v2.0"; message="An
unexpected error prevented the server from fulfilling your request. argument of
type 'NoneType' is not iterable" code="500" title="Internal Server Error"/>
Adding header "Content-type: application/json" fixes the problem.
It would be nice to improve the return code/error message.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1300982
Title:
No headers in REST API auth request results in HTTP 500
Status in OpenStack Identity (Keystone):
New
Bug description:
REQ to http://host.example.com:35357/v2.0/tokens:
{"auth":{"passwordCredentials":{"username": "admin", "password":"***"},
"tenant":"admin"}}
RESP:
Status Code: 500 Internal Server Error
Connection: keep-alive
Content-Length: 266
Content-Type: application/xml
Date: Wed, 11 Jul 2012 13:41:34 GMT
Vary: X-Auth-Token
http://docs.openstack.org/identity/api/v2.0"; message="An
unexpected error prevented the server from fulfilling your request. argument of
type 'NoneType' is not iterable" code="500" title="Internal Server Error"/>
Adding header "Content-type: application/json" fixes the problem.
It would be nice to improve the return code/error message.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1300982/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption
I've adjusted the "Summary" section as suggested by Rob. I've gone ahead and published the following OSSN to the following locations: https://wiki.openstack.org/wiki/OSSN/OSSN-0008 openst...@lists.openstack.org openstack-...@lists.openstack.org Thanks everyone for the reviews and contributions to this OSSN! -- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-secur...@lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1227575 Title: DoS style attack on noVNC server can lead to service interruption or disruption Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Notes: Fix Released Bug description: There is no limiting on the number of VNC sessions that can be created for a single user's VNC token. Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server results in many connection timeouts. Due to these connection timeout error, other users trying to access their VM's VNC console cannot do so. A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors Script: http://paste.openstack.org/show/47254/ Script output connections get timed out after a while --- .. Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Impact: 1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail. This can cause serious problems to users already having a running VNC session or trying to create new sessions. 2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol also gets affected after the connection timeout errors. For example: Before running the sumulate thousands of connections program: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1
[Yahoo-eng-team] [Bug 1240554] Re: Insecure live migration with libvirt driver
** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1240554 Title: Insecure live migration with libvirt driver Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: By default, libvirt on the receiving end of a live migration starts a qemu process listening on 0.0.0.0 waiting for a tcp connection from the sender. During block migration, qemu-nbd is started similarly. This is bad because compute nodes have interfaces on the guest network. As a result, guests can interfere with live migrations. There is a flag during migration to remedy this called VIR_MIGRATE_TUNNELLED, which tunnels traffic over the libvirt socket (which can be secured with TLS). This seems like a great option. Unfortunately it doesn't work with the new nbd-based block migration code, so there isn't a great option for securing the traffic. Related to this, libvirt just added: - Default migration bind()/listen() IP addr in /etc/libvirt/qemu.conf - Pass in bind()/listen() IP address to migration APIs So with libvirt >= 1.1.4, Nova will have the ability to control the interface used (Problem originally reported by Vish Ishaya) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1240554/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1280965] [NEW] LDAP dumb user is not filtered when listing role assignments
Public bug reported:
When the LDAP assignment driver is used and the "use_dumb_member"
configuration option is enabled, the dumb member is listed when listing
the role assignments. This can be seen by running the live LDAP tests,
as the "test_list_role_assignments_unfiltered" test will fail due to the
additional role assignments for the dumb member.
We should be filtering out the dumb member in
RoleApi.list_role_assignments(), as we already do inRoleApi.
get_role_assignments().
** Affects: keystone
Importance: Undecided
Assignee: Nathan Kinder (nkinder)
Status: In Progress
** Changed in: keystone
Status: New => In Progress
** Changed in: keystone
Assignee: (unassigned) => Nathan Kinder (nkinder)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1280965
Title:
LDAP dumb user is not filtered when listing role assignments
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
When the LDAP assignment driver is used and the "use_dumb_member"
configuration option is enabled, the dumb member is listed when
listing the role assignments. This can be seen by running the live
LDAP tests, as the "test_list_role_assignments_unfiltered" test will
fail due to the additional role assignments for the dumb member.
We should be filtering out the dumb member in
RoleApi.list_role_assignments(), as we already do inRoleApi.
get_role_assignments().
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1280965/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1280509] [NEW] Live LDAP test config uses incorrect default user DN
Public bug reported:
The default configuration for the live LDAP tests is supposed to match
the default devstack configuration. Unfortunately, the user DN in the
test configuration uses the wrong attribute in the RDN. Devstack uses
the "cn" attribute, but the test config uses the "dc" attribute. The
test configuration should be changed to match devstack.
** Affects: keystone
Importance: Undecided
Assignee: Nathan Kinder (nkinder)
Status: In Progress
** Changed in: keystone
Status: New => In Progress
** Changed in: keystone
Assignee: (unassigned) => Nathan Kinder (nkinder)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1280509
Title:
Live LDAP test config uses incorrect default user DN
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
The default configuration for the live LDAP tests is supposed to match
the default devstack configuration. Unfortunately, the user DN in
the test configuration uses the wrong attribute in the RDN. Devstack
uses the "cn" attribute, but the test config uses the "dc" attribute.
The test configuration should be changed to match devstack.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1280509/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@"
Published the following OSSN to the openstack and openstack-dev mailing lists: - Keystone can allow user impersonation when using REMOTE_USER for external authentication --- ### Summary ### When external authentication is used with Keystone using the "ExternalDefault" plug-in, external usernames containing "@" characters are truncated at the "@" character before being mapped to a local Keystone user. This can result in separate external users mapping to the same local Keystone user, which could lead to user impersonation. ### Affected Services / Software ### Keystone, Havana ### Discussion ### When Keystone is run in the Apache HTTP Server, the webserver can handle authentication and pass the authenticated username to Keystone using the REMOTE_USER environment variable. External authentication behavior is handled by authentication plugins in Keystone. In the Havana release of OpenStack, if the external username provided in the REMOTE_USER environment variable contains an "@" character Keystone will only use the portion preceding the "@" character as the username when using the "ExternalDefault" authentication plugin. This results in the ability for multiple unique external usernames to map to the same single username in Keystone. For example, the external usernames "j...@example1.com" and "j...@example2.com" would both map to the Keystone user "jdoe". This behavior could potentially be abused to allow one to impersonate another similarly named external user. Keystone in OpenStack releases prior to Havana uses the entire value contained in the REMOTE_USER environment variable, so those versions are not vulnerable to this impersonation issue. ### Recommended Actions ### If the "ExternalDefault" plugin is being used for external authentication in the Havana release, you should ensure that external usernames do not contain "@" characters unless you want to collapse similarly named external users into a single user on the Keystone side. If your external usernames do contain "@" characters and you do not want to collapse similarly named external users into a single user on the Keystone side, you might be able to use the "ExternalDomain" plug-in. This plugin considers the portion of the external username that follows an "@" character to be the domain that the user belongs to in Keystone. This allows similarly named external users to map to separate Keystone users if the portion of the external username that follows an "@" character maps to a Keystone domain name. To configure the "ExternalDomain" authentication plugin, set the "external" parameter in the "[auth]" section of Keystone's keystone.conf as follows: begin example keystone.conf snippet [auth] methods = external,password,token external = keystone.auth.plugins.external.ExternalDomain end example keystone.conf snippet If neither of the above recommendations work for your deployment, a custom authentication plugin can be created that uses the external username that contains an "@" character as-is. ### Contacts / References ### This OSSN : https://bugs.launchpad.net/ossn/+bug/1254619 Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1254619 OpenStack Security ML : openstack-secur...@lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): Fix Committed Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalD
[Yahoo-eng-team] [Bug 1226078] Re: Glance allows user to create images and add other tenants as members (CVE-2013-4354)
Published on OpenStack and OpenStack-Dev mailing lists on 11 Dec 2013. ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1226078 Title: Glance allows user to create images and add other tenants as members (CVE-2013-4354) Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Status in OpenStack Security Notes: Fix Released Bug description: It's well known that Glance does not perform any check on tenants. This has been a behavior we kept as-is to avoid increasing requests needed in the image management process, however, after some tests, I think this behavior can be a security issue. Scenario: - Create an image using user1 - Pick tenant's id of user2 and add it as a member of the image user1 just created - Use user2 to list images. This will list the image user1 created. I think this is an issue because it allows user from other tenants to sneak images with a backdoor to other tenants. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1226078/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1237989] Re: user can update his password without knowing the old password
Published on OpenStack and OpenStack-Dev mailing lists on 22 Nov 2013. ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: Fix Released Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
