From major at mhtx.net Mon Jul 3 15:13:00 2017
From: major at mhtx.net (Major Hayden)
Date: Mon, 03 Jul 2017 15:13:00 -0000
Subject: [Openstack-security] [Bug 1702123] [NEW] SELinux error: keepalived
reading haproxy pid file
Message-ID: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com>
Public bug reported:
When keepalived tries to read the haproxy PID file, SELinux denies the
access. This should be added into the haproxy role.
** Affects: openstack-ansible
Importance: Undecided
Assignee: Major Hayden (rackerhacker)
Status: New
** Tags: security
** Description changed:
When keepalived tries to read the haproxy PID file, SELinux denies the
- access. This should be added into the ansible-keepalived role.
+ access. This should be added into the haproxy role.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1702123
Title:
SELinux error: keepalived reading haproxy pid file
Status in openstack-ansible:
New
Bug description:
When keepalived tries to read the haproxy PID file, SELinux denies the
access. This should be added into the haproxy role.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions
From major at mhtx.net Mon Jul 3 16:18:12 2017
From: major at mhtx.net (Major Hayden)
Date: Mon, 03 Jul 2017 16:18:12 -0000
Subject: [Openstack-security] [Bug 1702123] Re: SELinux error: keepalived
reading haproxy pid file
References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com>
Message-ID: <149909869273.26230.18100713339891409350.malone@chaenomeles.canonical.com>
PR made for ansible-keepalived -> https://github.com/evrardjp/ansible-
keepalived/pull/47
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1702123
Title:
SELinux error: keepalived reading haproxy pid file
Status in openstack-ansible:
New
Bug description:
When keepalived tries to read the haproxy PID file, SELinux denies the
access. This should be added into the haproxy role.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions
From 1685678 at bugs.launchpad.net Mon Jul 3 23:28:51 2017
From: 1685678 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 03 Jul 2017 23:28:51 -0000
Subject: [Openstack-security] [Bug 1685678] Re: swap volume operation may
leak credentials into debug logs
References: <20170424003200.1328.91704.malonedeb@gac.canonical.com>
Message-ID: <149912453302.6183.262299781421330856.launchpad@gac.canonical.com>
** Changed in: nova
Assignee: Dane Fichter (dane-fichter) => Matt Riedemann (mriedem)
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1685678
Title:
swap volume operation may leak credentials into debug logs
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
The swap volume code in the compute service logs old and new volume
connection_info dicts to debug here:
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930
The new connection_info comes from Cinder:
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901
That's a plain dict from the response which may contain credentials.
The old connection_info comes from the
nova.objects.block_device.BlockDeviceMapping object, which uses
SensitiveStringField to sanitize the field's value when logged:
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904
https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280
The new connection_info could contain credentials though, so we should
mask those when logging it, even at debug level.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1685678/+subscriptions
From major at mhtx.net Wed Jul 5 21:07:20 2017
From: major at mhtx.net (Major Hayden)
Date: Wed, 05 Jul 2017 21:07:20 -0000
Subject: [Openstack-security] [Bug 1702571] [NEW] ansible-hardening docs are
vague about using as standalone
Message-ID: <149928884089.15922.6070230979479956825.malonedeb@wampee.canonical.com>
Public bug reported:
The ansible-hardening docs are a bit vague about how to handle
standalone deployments. Questions to answer:
1) How/where to provide variables?
2) What about roles in non standard locations? /home/myuser/ansible-hardening?
3) How do you install via ansible-galaxy from git?
4) What do you need to install first before running the role?
5) What would an inventory file look like?
** Affects: openstack-ansible
Importance: Low
Assignee: Major Hayden (rackerhacker)
Status: Confirmed
** Tags: security
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1702571
Title:
ansible-hardening docs are vague about using as standalone
Status in openstack-ansible:
Confirmed
Bug description:
The ansible-hardening docs are a bit vague about how to handle
standalone deployments. Questions to answer:
1) How/where to provide variables?
2) What about roles in non standard locations? /home/myuser/ansible-hardening?
3) How do you install via ansible-galaxy from git?
4) What do you need to install first before running the role?
5) What would an inventory file look like?
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1702571/+subscriptions
From 1702571 at bugs.launchpad.net Thu Jul 6 19:45:13 2017
From: 1702571 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 06 Jul 2017 19:45:13 -0000
Subject: [Openstack-security] [Bug 1702571] Re: ansible-hardening docs are
vague about using as standalone
References: <149928884089.15922.6070230979479956825.malonedeb@wampee.canonical.com>
Message-ID: <149937031366.26975.12056520551347775004.malone@chaenomeles.canonical.com>
Fix proposed to branch: master
Review: https://review.openstack.org/481203
** Changed in: openstack-ansible
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1702571
Title:
ansible-hardening docs are vague about using as standalone
Status in openstack-ansible:
In Progress
Bug description:
The ansible-hardening docs are a bit vague about how to handle
standalone deployments. Questions to answer:
1) How/where to provide variables?
2) What about roles in non standard locations? /home/myuser/ansible-hardening?
3) How do you install via ansible-galaxy from git?
4) What do you need to install first before running the role?
5) What would an inventory file look like?
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1702571/+subscriptions
From 1685678 at bugs.launchpad.net Mon Jul 10 16:04:56 2017
From: 1685678 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 10 Jul 2017 16:04:56 -0000
Subject: [Openstack-security] [Bug 1685678] Re: swap volume operation may
leak credentials into debug logs
References: <20170424003200.1328.91704.malonedeb@gac.canonical.com>
Message-ID: <149970269823.15347.4944327312147895412.launchpad@wampee.canonical.com>
** Changed in: nova
Assignee: Matt Riedemann (mriedem) => Dane Fichter (dane-fichter)
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1685678
Title:
swap volume operation may leak credentials into debug logs
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
The swap volume code in the compute service logs old and new volume
connection_info dicts to debug here:
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930
The new connection_info comes from Cinder:
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901
That's a plain dict from the response which may contain credentials.
The old connection_info comes from the
nova.objects.block_device.BlockDeviceMapping object, which uses
SensitiveStringField to sanitize the field's value when logged:
https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904
https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280
The new connection_info could contain credentials though, so we should
mask those when logging it, even at debug level.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1685678/+subscriptions
From 1702123 at bugs.launchpad.net Tue Jul 11 16:12:45 2017
From: 1702123 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 11 Jul 2017 16:12:45 -0000
Subject: [Openstack-security] [Bug 1702123] Re: SELinux error: keepalived
reading haproxy pid file
References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com>
Message-ID: <149978956669.15421.1184906657753596471.launchpad@wampee.canonical.com>
** Changed in: openstack-ansible
Status: New => Fix Released
** Changed in: openstack-ansible
Status: Fix Released => Confirmed
** Changed in: openstack-ansible
Assignee: Major Hayden (rackerhacker) => Jean-Philippe Evrard (jean-philippe-evrard)
** Changed in: openstack-ansible
Importance: Undecided => High
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1702123
Title:
SELinux error: keepalived reading haproxy pid file
Status in openstack-ansible:
Confirmed
Bug description:
When keepalived tries to read the haproxy PID file, SELinux denies the
access. This should be added into the haproxy role.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions
From fungi at yuggoth.org Wed Jul 12 14:44:43 2017
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 12 Jul 2017 14:44:43 -0000
Subject: [Openstack-security] [Bug 1703369] Re: get_identity_providers
policy should be singular
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <149987068328.15080.17998194804416089072.malone@wampee.canonical.com>
Since Luke is running with the OSSN task confirmed, I'm going to take
that as agreement that this is class B2 and set our OSSA task to won't
fix. Thanks!
** Changed in: ossa
Status: Incomplete => Won't Fix
** Tags added: security
** Information type changed from Public Security to Public
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
New
Status in OpenStack Identity (keystone) ocata series:
New
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From 1666959 at bugs.launchpad.net Wed Jul 12 16:34:57 2017
From: 1666959 at bugs.launchpad.net (Ihar Hrachyshka)
Date: Wed, 12 Jul 2017 16:34:57 -0000
Subject: [Openstack-security] [Bug 1666959] Re: ha_vrrp_auth_type defaults
to PASS which is insecure
References: <20170222154900.3995.72774.malonedeb@chaenomeles.canonical.com>
Message-ID: <149987729740.24899.17099366206150909184.malone@soybean.canonical.com>
If the config option is worthless, it's a mild usability issue, and we
should drop it. Marking with the corresponding tag.
** Tags added: usability
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1666959
Title:
ha_vrrp_auth_type defaults to PASS which is insecure
Status in neutron:
New
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
With l3_ha enabled, ha_vrrp_auth_type defaults to PASS authentication:
https://github.com/openstack/neutron/blob/b90ec94dc3f83f63bdb505ace1e4c272435c494b/neutron/conf/agent/l3/ha.py#L28
which according to http://louwrentius.com/configuring-attacking-and-
securing-vrrp-on-linux.html is totally insecure because the VRRP
password is transmitted in the clear.
I'm not sure if this is currently a serious issue, since if the VRRP
network is untrusted, maybe there are already bigger problems. But I
thought it was worth reporting, at least.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1666959/+subscriptions
From lhinds at redhat.com Thu Jul 13 16:56:38 2017
From: lhinds at redhat.com (Luke Hinds)
Date: Thu, 13 Jul 2017 16:56:38 -0000
Subject: [Openstack-security] [Bug 1686743] Re: Ceph credentials included in
logs using older libvirt/qemu
References: <20170427142747.26531.54657.malonedeb@gac.canonical.com>
Message-ID: <149996500198.26895.18377530070756347799.launchpad@chaenomeles.canonical.com>
** Changed in: ossn
Status: New => Confirmed
** Changed in: ossn
Importance: Undecided => High
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1686743
Title:
Ceph credentials included in logs using older libvirt/qemu
Status in OpenStack Compute (nova):
New
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
Older versions of libvirt included network storage authentication
information on the qemu command line. If libvirt raises an exception
which logs the qemu command line it used, for example an error
starting a domain, this authentication information will end up in the
logs. There is an existing CVE for this issue here:
https://access.redhat.com/security/cve/CVE-2015-5160
Specifically, if a deployment is using ceph, a libvirt error starting
a domain would log the cephx secret key and the monitor addresses on
the qemu command line.
The issue has been resolved upstream. Users running qemu version 2.6
or later, and libvirt version 2.2 or later, are not vulnerable. No
change is required in Nova to resolve this issue.
Red Hat users running RHEL 7.3 or later are not vulnerable.
It's not 100% clear to me that an OpenStack CVE is required here as
it's not a bug in an OpenStack component, and it's already fixed
upstream. However, it did come to my attention after a user publicly
posted their ceph credentials on IRC, so evidently some OpenStack
users are running vulnerable systems, and this is a very common
configuration.
In Nova, we currently have:
MIN_LIBVIRT_VERSION = (1, 2, 9)
MIN_QEMU_VERSION = (2, 1, 0)
so anybody running the minimum supported versions will be vulnerable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1686743/+subscriptions
From fungi at yuggoth.org Thu Jul 13 19:49:31 2017
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 13 Jul 2017 19:49:31 -0000
Subject: [Openstack-security] [Bug 1618615] Re: Potential information
disclosure in EC2 "credentials"
References: <20160830202957.12384.56813.malonedeb@chaenomeles.canonical.com>
Message-ID: <149997537313.6469.3416627620127631146.launchpad@gac.canonical.com>
** Tags added: security
** Information type changed from Public Security to Public
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1618615
Title:
Potential information disclosure in EC2 "credentials"
Status in OpenStack Identity (keystone):
New
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Won't Fix
Bug description:
When creating a "credential" in Keystone, instead of using
uuid.uuid4() like in most places to generate a unique identifier, the
id is created from the SHA256 hash value of whatever is passed in as
the "access" key in the POST request (Code here:
https://github.com/openstack/keystone/blob/master/keystone/credential/controllers.py#L36-L60)
===== EXAMPLE REQUEST =====
POST /v3/credentials HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [ADMIN TOKEN]
Content-Length: 231
Content-Type: application/json
{
"credential": {
"blob": "{\"access\":\"\",\"secret\":\"secretKey\"}",
"project_id": "12345",
"type": "ec2",
"user_id": "12345"
}
}
HTTP/1.1 201 Created
Date: Tue, 30 Aug 2016 19:14:54 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 383
Content-Type: application/json
{"credential": {"user_id": "12345", "links": {"self":
"[ENDPOINT]/v3/credentials/141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea"},
"blob":
"{\"access\":\"\",\"secret\":\"secretKey\"}",
"project_id": "12345", "type": "ec2", "id":
"141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea"}}
===== /EXAMPLE =====
The id from the example above is
"141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea",
which is the same as the SHA256 value of ""
(you can test this with `echo -n "" | openssl
dgst -sha256` on *nix)
The documentation here seems to show MD5s and possibly tenant IDs used
as "access" values: http://developer.openstack.org/api-
ref/identity/v3/?expanded=assign-role-to-user-on-projects-owned-by-
domain-detail,create-policy-detail,show-credential-details-detail
,list-credentials-detail,create-credential-detail#list-credentials
Bruteforcing an actual MD5 isn't a huge security risk (i.e. trying to
predict all 32 characters from thin air), but if the MD5 is a hash of
a known value (i.e. the string "admin"), it would be trivial to test
for common values:
md5(admin) = 21232f297a57a5a743894a0e4a801fc3
sha256(21232f297a57a5a743894a0e4a801fc3) = 465c194afb65670f38322df087f0a9bb225cc257e43eb4ac5a0c98ef5b3173ac
If tenant IDs are used, this task becomes even easier: just generate
SHA256 hashes for 0 - 999999
A non-admin user can determine whether there are credentials using a
given access key by attempting to access the resource from its sha256
url identifier:
===== EXAMPLE REQUESTS =====
Existing credential
GET /v3/credentials/141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [NON-ADMIN TOKEN]
Content-Type: application/json
Connection: close
HTTP/1.1 403 Forbidden
Date: Tue, 30 Aug 2016 19:55:24 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 140
Content-Type: application/json
{"error": {"message": "You are not authorized to perform the
requested action: identity:get_credential", "code": 403, "title":
"Forbidden"}}
Non-existent credential
GET /v3/credentials/deadbeef HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [NON-ADMIN TOKEN]
Content-Type: application/json
HTTP/1.1 404 Not Found
Date: Tue, 30 Aug 2016 20:03:38 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 96
Content-Type: application/json
{"error": {"message": "Could not find credential: deadbeef",
"code": 404, "title": "Not Found"}}
===== /EXAMPLE =====
It is also possible to get a 500 error by creating a credential with
an invalid character in the "access" key:
===== EXAMPLE REQUEST =====
POST /v3/credentials HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [ADMIN TOKEN]
Content-Length: 212
Content-Type: application/json
{
"credential": {
"blob": "{\"access\":\"\uffff\",\"secret\":\"secretKey\"}",
"project_id": "12345",
"type": "ec2",
"user_id": "12345"
}
}
HTTP/1.1 500 Internal Server Error
Date: Tue, 30 Aug 2016 20:06:16 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 143
Content-Type: application/json
{"error": {"message": "An unexpected error prevented the server
from fulfilling your request.", "code": 500, "title": "Internal Server
Error"}}
===== /EXAMPLE =====
I'm unsure what the security impact would be here, mainly because of
the ambiguous examples provided in the Keystone API documentation
(linked above). If either of the 2 scenarios I outlined is a
reasonable use case (i.e. MD5 of a guessable value, or tenant IDs),
there may be a risk of information leakage by brute-force. It would
also be possible to prevent others from creating credentials with a
given access key by simply creating lots of credentials in Keystone
with predictable access keys. This would cause a collision whenever
attempting to create a credential set with an access key that has
already been used.
If, on the other hand, the credentials are always in the format
described by AWS here ( link:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSGettingStartedGuide/AWSCredentials.html
), it would require a huge number of requests to bruteforce the access
key (though it would not be impossible). However, it would be
possible, using the approach described above with a regular user
token, to determine whether a known EC2 access key was in place as a
credential in a given Keystone database.
I'm unclear on the utility of using SHA256 for the identifier at all
here, since random UUIDs would make this potential issue moot.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1618615/+subscriptions
From fungi at yuggoth.org Fri Jul 14 16:05:29 2017
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 14 Jul 2017 16:05:29 -0000
Subject: [Openstack-security] [Bug 1704398] Re: Inheriting trunk subport
segmentation details leaks information
References: <150004087773.6647.4215962220125184884.malonedeb@gac.canonical.com>
Message-ID: <150004833009.26197.1781959317175654931.malone@chaenomeles.canonical.com>
Given that this hasn't appeared in any official release yet, the risk
exposed by it is low, there's an assertion that it's probably working as
intended and a need has been expressed to bring additional teams into
the discussion... I'm going to switch this to Public for now.
If the issue is determined to be an actual defect and vulnerability and
somehow isn't fixed before release, we can revisit issuing an advisory
once it gets fixed but I see no reason to slow down this evaluation with
our embargo process.
** Information type changed from Private Security to Public
** Changed in: ossa
Status: Incomplete => Won't Fix
** Tags added: security
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1704398
Title:
Inheriting trunk subport segmentation details leaks information
Status in neutron:
Incomplete
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
The following information is discoverable for non-admin users of neutron despite the policy:
* the segmentation type and id of all vlan based networks
* the segmentation type of all non-vlan based networks
Reproduction:
configuration)
[[local|localrc]]
enable_plugin neutron ...
enable_service q-trunk
versions)
devstack b79531a9f96736225a8991052a0be5767c217377
neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c
1) for vlan networks
source openrc admin demo
openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
# demo user has no right to see segmentation type and id of vlan provider net
openstack network show net1
# but both the type and id are available in the subport list
openstack network subport list --trunk trunk0
2) for other network types
source openrc admin demo
openstack network create net0
openstack network create net1
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
# the type of net1 comes back in the error message (in my environment 'vxlan')
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
While according to the default policy this information should be admin-only. See around here:
https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45
This behavior was introduced in response to this rfe:
https://bugs.launchpad.net/neutron/+bug/1648129
Actually sharing this information is the point of the rfe.
IIRC the concern about the information leak was even raised during a
review, but it seems it went unaddressed. (Yep, I found the comment
again: https://review.openstack.org/436756 comment at 03-07 21:12)
I'm not sure if the segmentation details should be considered
sensitive information or not. But the current behavior (admin-only
here, not admin-only there) is clearly inconsistent.
We could probably solve this by just synchronizing the default
policies of provider network get operation and subport segmentation
detail inheritance.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1704398/+subscriptions
From morgan.fainberg at gmail.com Mon Jul 17 16:18:01 2017
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Mon, 17 Jul 2017 16:18:01 -0000
Subject: [Openstack-security] [Bug 1576765] Re: Potential DOS: Keystone
Extra Fields
References: <20160429154657.5758.65558.malonedeb@chaenomeles.canonical.com>
Message-ID: <150030828381.15700.10111573921283104444.launchpad@wampee.canonical.com>
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1576765
Title:
Potential DOS: Keystone Extra Fields
Status in OpenStack Identity (keystone):
Won't Fix
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
A user that has rights to update a resource in Keystone (project,
user, domain, etc) can inject extra data (near unlimited amounts) with
data that is only limited by the maximum request size. The extra
fields cannot be deleted (ever) in the current design (the value of
the field can be set to ~1byte minimum). An update excluding the field
leaves the field data intact as is.
This means that a bad actor can update a keystone resource and do one
of the following to DOS Keystone cluster, database replication,
database traffic, etc:
1) Create endless numbers of fields with very little data, that will
cause longer and longer json serialization/deserailization times due
to the volume of elements.
2) Create endless numbers of fields with large data sets, increasing
the delta of what is stored in the RDBMS and putting extra load on the
replication/etc processes for the shared data. This potentially could
be used as a vector to run the DB server out of
ram/cache/buffers/disk. This also causes the issue itemized above (1).
3) With HMT, it is possible to duplicate (as a domain/user) the above
listed items with more and more resources.
Memcache/caching will offset some of these issues until the memcache
server can no longer store the data from the keystone resource due to
exceeding the slab size (1MB) which could cause excessive load on the
memcached servers/caching servers.
With caching enabled, it is possible to run the keystone processes out
of memory/DOS due to the request_local cache in use to ensure that the
resources are fetched from the backend a single time (using a msgpack
of the data stored in memory) for a given HTTP request.
--- PROPOSED FIX --
* Issue a security bug fix that by default disables the ability to store data in the extra fields for *ALL* keystone resources
* Migrate any/all fields that keystone supports to first class-attributes (columns) in the SQL backend[s].
* 2-Cycle deprecation before removal of the support for "extra" field storage (toggled via config value) - in the P Cycle extra fields will no longer be supported. All non-standard data will need to be migrated to an external metadata storage.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1576765/+subscriptions
From 1704398 at bugs.launchpad.net Mon Jul 17 20:07:58 2017
From: 1704398 at bugs.launchpad.net (Armando Migliaccio)
Date: Mon, 17 Jul 2017 20:07:58 -0000
Subject: [Openstack-security] [Bug 1704398] Re: Inheriting trunk subport
segmentation details leaks information
References: <150004087773.6647.4215962220125184884.malonedeb@gac.canonical.com>
Message-ID: <150032207855.24248.13414557412374360399.malone@soybean.canonical.com>
I would recommend against exposing segmentation details by default, as
the trunk functionality is not generally enabled by default.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1704398
Title:
Inheriting trunk subport segmentation details leaks information
Status in neutron:
Incomplete
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
The following information is discoverable for non-admin users of neutron despite the policy:
* the segmentation type and id of all vlan based networks
* the segmentation type of all non-vlan based networks
Reproduction:
configuration)
[[local|localrc]]
enable_plugin neutron ...
enable_service q-trunk
versions)
devstack b79531a9f96736225a8991052a0be5767c217377
neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c
1) for vlan networks
source openrc admin demo
openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
# demo user has no right to see segmentation type and id of vlan provider net
openstack network show net1
# but both the type and id are available in the subport list
openstack network subport list --trunk trunk0
2) for other network types
source openrc admin demo
openstack network create net0
openstack network create net1
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
# the type of net1 comes back in the error message (in my environment 'vxlan')
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
While according to the default policy this information should be admin-only. See around here:
https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45
This behavior was introduced in response to this rfe:
https://bugs.launchpad.net/neutron/+bug/1648129
Actually sharing this information is the point of the rfe.
IIRC the concern about the information leak was even raised during a
review, but it seems it went unaddressed. (Yep, I found the comment
again: https://review.openstack.org/436756 comment at 03-07 21:12)
I'm not sure if the segmentation details should be considered
sensitive information or not. But the current behavior (admin-only
here, not admin-only there) is clearly inconsistent.
We could probably solve this by just synchronizing the default
policies of provider network get operation and subport segmentation
detail inheritance.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1704398/+subscriptions
From 1704398 at bugs.launchpad.net Mon Jul 17 20:59:05 2017
From: 1704398 at bugs.launchpad.net (Kevin Benton)
Date: Mon, 17 Jul 2017 20:59:05 -0000
Subject: [Openstack-security] [Bug 1704398] Re: Inheriting trunk subport
segmentation details leaks information
References: <150004087773.6647.4215962220125184884.malonedeb@gac.canonical.com>
Message-ID: <150032514604.24454.3516510861680852662.malone@soybean.canonical.com>
The 'inherit' property is just exposing one very specific detail of a
single encapsulation type (VLAN) that there isn't meaning to outside of
the compute<->switch link. Segmentation details for other encapsulation
types may contain sensitive information (e.g. tunnel termination
details), so I don't think they are really equivalent.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1704398
Title:
Inheriting trunk subport segmentation details leaks information
Status in neutron:
Incomplete
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
The following information is discoverable for non-admin users of neutron despite the policy:
* the segmentation type and id of all vlan based networks
* the segmentation type of all non-vlan based networks
Reproduction:
configuration)
[[local|localrc]]
enable_plugin neutron ...
enable_service q-trunk
versions)
devstack b79531a9f96736225a8991052a0be5767c217377
neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c
1) for vlan networks
source openrc admin demo
openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
# demo user has no right to see segmentation type and id of vlan provider net
openstack network show net1
# but both the type and id are available in the subport list
openstack network subport list --trunk trunk0
2) for other network types
source openrc admin demo
openstack network create net0
openstack network create net1
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
# the type of net1 comes back in the error message (in my environment 'vxlan')
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
While according to the default policy this information should be admin-only. See around here:
https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45
This behavior was introduced in response to this rfe:
https://bugs.launchpad.net/neutron/+bug/1648129
Actually sharing this information is the point of the rfe.
IIRC the concern about the information leak was even raised during a
review, but it seems it went unaddressed. (Yep, I found the comment
again: https://review.openstack.org/436756 comment at 03-07 21:12)
I'm not sure if the segmentation details should be considered
sensitive information or not. But the current behavior (admin-only
here, not admin-only there) is clearly inconsistent.
We could probably solve this by just synchronizing the default
policies of provider network get operation and subport segmentation
detail inheritance.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1704398/+subscriptions
From tdecacqu at redhat.com Tue Jul 18 00:54:53 2017
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Tue, 18 Jul 2017 00:54:53 -0000
Subject: [Openstack-security] [Bug 1704398] Re: Inheriting trunk subport
segmentation details leaks information
References: <150004087773.6647.4215962220125184884.malonedeb@gac.canonical.com>
Message-ID: <150033929491.26131.10060830020346700250.launchpad@chaenomeles.canonical.com>
** Description changed:
- This issue is being treated as a potential security risk under embargo.
- Please do not make any public mention of embargoed (private) security
- vulnerabilities before their coordinated publication by the OpenStack
- Vulnerability Management Team in the form of an official OpenStack
- Security Advisory. This includes discussion of the bug or associated
- fixes in public forums such as mailing lists, code review systems and
- bug trackers. Please also avoid private disclosure to other individuals
- not already approved for access to this information, and provide this
- same reminder to those who are made aware of the issue prior to
- publication. All discussion should remain confined to this private bug
- report, and any proposed fixes should be added to the bug as
- attachments.
-
The following information is discoverable for non-admin users of neutron despite the policy:
* the segmentation type and id of all vlan based networks
* the segmentation type of all non-vlan based networks
Reproduction:
configuration)
[[local|localrc]]
enable_plugin neutron ...
enable_service q-trunk
versions)
devstack b79531a9f96736225a8991052a0be5767c217377
neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c
1) for vlan networks
source openrc admin demo
openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
# demo user has no right to see segmentation type and id of vlan provider net
openstack network show net1
# but both the type and id are available in the subport list
openstack network subport list --trunk trunk0
2) for other network types
source openrc admin demo
openstack network create net0
openstack network create net1
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
# the type of net1 comes back in the error message (in my environment 'vxlan')
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
While according to the default policy this information should be admin-only. See around here:
https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45
This behavior was introduced in response to this rfe:
https://bugs.launchpad.net/neutron/+bug/1648129
Actually sharing this information is the point of the rfe.
IIRC the concern about the information leak was even raised during a
review, but it seems it went unaddressed. (Yep, I found the comment
again: https://review.openstack.org/436756 comment at 03-07 21:12)
I'm not sure if the segmentation details should be considered sensitive
information or not. But the current behavior (admin-only here, not
admin-only there) is clearly inconsistent.
We could probably solve this by just synchronizing the default policies
of provider network get operation and subport segmentation detail
inheritance.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1704398
Title:
Inheriting trunk subport segmentation details leaks information
Status in neutron:
Incomplete
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
The following information is discoverable for non-admin users of neutron despite the policy:
* the segmentation type and id of all vlan based networks
* the segmentation type of all non-vlan based networks
Reproduction:
configuration)
[[local|localrc]]
enable_plugin neutron ...
enable_service q-trunk
versions)
devstack b79531a9f96736225a8991052a0be5767c217377
neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c
1) for vlan networks
source openrc admin demo
openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
# demo user has no right to see segmentation type and id of vlan provider net
openstack network show net1
# but both the type and id are available in the subport list
openstack network subport list --trunk trunk0
2) for other network types
source openrc admin demo
openstack network create net0
openstack network create net1
source openrc demo demo
openstack port create port0 --network net0
openstack port create port1 --network net1
openstack network trunk create trunk0 --parent-port port0
# the type of net1 comes back in the error message (in my environment 'vxlan')
openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
While according to the default policy this information should be admin-only. See around here:
https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45
This behavior was introduced in response to this rfe:
https://bugs.launchpad.net/neutron/+bug/1648129
Actually sharing this information is the point of the rfe.
IIRC the concern about the information leak was even raised during a
review, but it seems it went unaddressed. (Yep, I found the comment
again: https://review.openstack.org/436756 comment at 03-07 21:12)
I'm not sure if the segmentation details should be considered
sensitive information or not. But the current behavior (admin-only
here, not admin-only there) is clearly inconsistent.
We could probably solve this by just synchronizing the default
policies of provider network get operation and subport segmentation
detail inheritance.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1704398/+subscriptions
From lhinds at redhat.com Tue Jul 18 09:59:05 2017
From: lhinds at redhat.com (Luke Hinds)
Date: Tue, 18 Jul 2017 09:59:05 -0000
Subject: [Openstack-security] [Bug 1686743] Re: Ceph credentials included in
logs using older libvirt/qemu
References: <20170427142747.26531.54657.malonedeb@gac.canonical.com>
Message-ID: <150037194768.15111.14587881229132920495.launchpad@wampee.canonical.com>
** Changed in: ossn
Assignee: (unassigned) => Luke Hinds (lhinds)
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1686743
Title:
Ceph credentials included in logs using older libvirt/qemu
Status in OpenStack Compute (nova):
New
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
Older versions of libvirt included network storage authentication
information on the qemu command line. If libvirt raises an exception
which logs the qemu command line it used, for example an error
starting a domain, this authentication information will end up in the
logs. There is an existing CVE for this issue here:
https://access.redhat.com/security/cve/CVE-2015-5160
Specifically, if a deployment is using ceph, a libvirt error starting
a domain would log the cephx secret key and the monitor addresses on
the qemu command line.
The issue has been resolved upstream. Users running qemu version 2.6
or later, and libvirt version 2.2 or later, are not vulnerable. No
change is required in Nova to resolve this issue.
Red Hat users running RHEL 7.3 or later are not vulnerable.
It's not 100% clear to me that an OpenStack CVE is required here as
it's not a bug in an OpenStack component, and it's already fixed
upstream. However, it did come to my attention after a user publicly
posted their ceph credentials on IRC, so evidently some OpenStack
users are running vulnerable systems, and this is a very common
configuration.
In Nova, we currently have:
MIN_LIBVIRT_VERSION = (1, 2, 9)
MIN_QEMU_VERSION = (2, 1, 0)
so anybody running the minimum supported versions will be vulnerable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1686743/+subscriptions
From 1703369 at bugs.launchpad.net Thu Jul 20 14:49:17 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 20 Jul 2017 14:49:17 -0000
Subject: [Openstack-security] [Bug 1703369] Re: get_identity_providers
policy should be singular
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150056215725.26552.8923604181348210012.malone@chaenomeles.canonical.com>
Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/485694
** Changed in: keystone/ocata
Status: New => In Progress
** Changed in: keystone/ocata
Assignee: (unassigned) => Lance Bragstad (lbragstad)
** Changed in: keystone/newton
Status: New => In Progress
** Changed in: keystone/newton
Assignee: (unassigned) => Lance Bragstad (lbragstad)
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
In Progress
Status in OpenStack Identity (keystone) ocata series:
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From 1703369 at bugs.launchpad.net Thu Jul 20 14:50:33 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 20 Jul 2017 14:50:33 -0000
Subject: [Openstack-security] [Bug 1703369] Fix proposed to keystone
(stable/newton)
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150056223346.26263.4575845271624060297.malone@chaenomeles.canonical.com>
Fix proposed to branch: stable/newton
Review: https://review.openstack.org/485695
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
In Progress
Status in OpenStack Identity (keystone) ocata series:
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From 1703369 at bugs.launchpad.net Fri Jul 21 00:12:57 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 21 Jul 2017 00:12:57 -0000
Subject: [Openstack-security] [Bug 1703369] Re: get_identity_providers
policy should be singular
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150059597711.24500.3878520101877574940.malone@soybean.canonical.com>
Reviewed: https://review.openstack.org/485694
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6c96675d63257d7ef2c27c5598c642efa7a25d08
Submitter: Jenkins
Branch: stable/ocata
commit 6c96675d63257d7ef2c27c5598c642efa7a25d08
Author: Matthew Edmonds
Date: Mon Jul 10 09:20:18 2017 -0400
fix identity:get_identity_providers typo
Changes identity:get_identity_providers policy rule to
identity:get_identity_provider to match what is checked by the code.
Conflicts:
keystone/common/policies/identity_provider.py
There was a conflict backporting this change since the policy-in-code
work in new in Pike. The conflict was resolved by removing the
policy-in-code change and making it manually against the old
etc/policy.json file.
Change-Id: I0841abd30fd15c034b5836e42a18938634b509b1
Closes-Bug: #1703369
(cherry picked from commit b7119637a04d0a07fa6419a407f433c01bbd1db2)
** Changed in: keystone/ocata
Status: In Progress => Fix Committed
** Changed in: keystone/newton
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
Fix Committed
Status in OpenStack Identity (keystone) ocata series:
Fix Committed
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From 1703369 at bugs.launchpad.net Fri Jul 21 00:13:17 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 21 Jul 2017 00:13:17 -0000
Subject: [Openstack-security] [Bug 1703369] Fix merged to keystone
(stable/newton)
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150059599722.6362.8412973635817348521.malone@gac.canonical.com>
Reviewed: https://review.openstack.org/485695
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=bd49c3ef6daa474e9c84c0d8721c0f6812ee3d2c
Submitter: Jenkins
Branch: stable/newton
commit bd49c3ef6daa474e9c84c0d8721c0f6812ee3d2c
Author: Matthew Edmonds
Date: Mon Jul 10 09:20:18 2017 -0400
fix identity:get_identity_providers typo
Changes identity:get_identity_providers policy rule to
identity:get_identity_provider to match what is checked by the code.
Conflicts:
keystone/common/policies/identity_provider.py
There was a conflict backporting this change since the policy-in-code
work in new in Pike. The conflict was resolved by removing the
policy-in-code change and making it manually against the old
etc/policy.json file.
Change-Id: I0841abd30fd15c034b5836e42a18938634b509b1
Closes-Bug: #1703369
(cherry picked from commit b7119637a04d0a07fa6419a407f433c01bbd1db2)
(cherry picked from commit 8038f545daa31354e08a4063209295439005c0b8)
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
Fix Committed
Status in OpenStack Identity (keystone) ocata series:
Fix Committed
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From 1702571 at bugs.launchpad.net Fri Jul 21 14:15:43 2017
From: 1702571 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 21 Jul 2017 14:15:43 -0000
Subject: [Openstack-security] [Bug 1702571] Re: ansible-hardening docs are
vague about using as standalone
References: <149928884089.15922.6070230979479956825.malonedeb@wampee.canonical.com>
Message-ID: <150064654400.15782.1644417669303736659.malone@wampee.canonical.com>
Reviewed: https://review.openstack.org/481203
Committed: https://git.openstack.org/cgit/openstack/ansible-hardening/commit/?id=4449474a3dea7467a09564aadbf68d71824e0601
Submitter: Jenkins
Branch: master
commit 4449474a3dea7467a09564aadbf68d71824e0601
Author: Major Hayden
Date: Mon Jul 10 09:45:24 2017 -0500
[Docs] Make install/usage docs more clear
This patch clarifies some of the installation and usage docs for
newcomers to the role.
Closes-Bug: 1702571
Change-Id: I1a935b37d9b9248ca53e8f252dd2407c15347935
** Changed in: openstack-ansible
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1702571
Title:
ansible-hardening docs are vague about using as standalone
Status in openstack-ansible:
Fix Released
Bug description:
The ansible-hardening docs are a bit vague about how to handle
standalone deployments. Questions to answer:
1) How/where to provide variables?
2) What about roles in non standard locations? /home/myuser/ansible-hardening?
3) How do you install via ansible-galaxy from git?
4) What do you need to install first before running the role?
5) What would an inventory file look like?
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1702571/+subscriptions
From sean at dague.net Mon Jul 24 15:30:38 2017
From: sean at dague.net (Sean Dague)
Date: Mon, 24 Jul 2017 15:30:38 -0000
Subject: [Openstack-security] [Bug 1686743] Re: Ceph credentials included in
logs using older libvirt/qemu
References: <20170427142747.26531.54657.malonedeb@gac.canonical.com>
Message-ID: <150091023821.6292.10803220577758142435.malone@gac.canonical.com>
I don't think there is really a Nova fix here, just an FYI
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1686743
Title:
Ceph credentials included in logs using older libvirt/qemu
Status in OpenStack Compute (nova):
Opinion
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
Older versions of libvirt included network storage authentication
information on the qemu command line. If libvirt raises an exception
which logs the qemu command line it used, for example an error
starting a domain, this authentication information will end up in the
logs. There is an existing CVE for this issue here:
https://access.redhat.com/security/cve/CVE-2015-5160
Specifically, if a deployment is using ceph, a libvirt error starting
a domain would log the cephx secret key and the monitor addresses on
the qemu command line.
The issue has been resolved upstream. Users running qemu version 2.6
or later, and libvirt version 2.2 or later, are not vulnerable. No
change is required in Nova to resolve this issue.
Red Hat users running RHEL 7.3 or later are not vulnerable.
It's not 100% clear to me that an OpenStack CVE is required here as
it's not a bug in an OpenStack component, and it's already fixed
upstream. However, it did come to my attention after a user publicly
posted their ceph credentials on IRC, so evidently some OpenStack
users are running vulnerable systems, and this is a very common
configuration.
In Nova, we currently have:
MIN_LIBVIRT_VERSION = (1, 2, 9)
MIN_QEMU_VERSION = (2, 1, 0)
so anybody running the minimum supported versions will be vulnerable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1686743/+subscriptions
From sean at dague.net Tue Jul 25 16:59:33 2017
From: sean at dague.net (Sean Dague)
Date: Tue, 25 Jul 2017 16:59:33 -0000
Subject: [Openstack-security] [Bug 1681465] Re: VNC connection to VMs is
unprotected
References: <20170410144043.30866.56391.malonedeb@soybean.canonical.com>
Message-ID: <150100197576.5969.470266289157670768.launchpad@gac.canonical.com>
** Changed in: nova
Status: New => Opinion
** Changed in: nova
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1681465
Title:
VNC connection to VMs is unprotected
Status in OpenStack Compute (nova):
Opinion
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Description:
============
OpenStack Nova does not provide any protection of VNC servers running
on compute nodes by default. Any client that has access to management
network can connect to the consoles of VMs running on compute node and
obtains full access to VMs via the console (e.g. by rebooting VMs to
single-user mode).
Steps to reproduce
==================
- Configuration: the management interface of the compute node has a public IP address and is not protected by firewalls
- Create a VM on the compute node
- Use a VNC client to connect directly to the IP of the compute node via port 590x from anywhere.
Expected result
===============
Connections refused. Only VNC connections from master node should be accepted. Other should connect using proxy on master node which does also authorization
Actual result
=============
Connection accepted. Anyone can use VNC client to connect directly to the console of VMs running on the compute node without any authentication/authorization
Discussion
===========
To be fair, most of examples in the OpenStack documentation have
management networks private, so the network configuration in the
examples are safe. However, OpenStack documentation only emphasizes
the separation of management network from other networks (VM, data)
and does not explicitly require (in a visible way) that the management
networks must be protected (private networks, firewalls). The
management network may be separated to another (public) network
segment and the system is still vulnerable to the VNC attack.
Therefore, the VNC connection to compute nodes should be protected
(password, iptables) by default, or the documentation should give
explicit warning that the management network must be private or
protected by firewalls.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1681465/+subscriptions
From 1703369 at bugs.launchpad.net Wed Jul 26 04:46:13 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 26 Jul 2017 04:46:13 -0000
Subject: [Openstack-security] [Bug 1703369] Fix included in
openstack/keystone 11.0.3
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150104437381.6183.811984939628821119.malone@gac.canonical.com>
This issue was fixed in the openstack/keystone 11.0.3 release.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
Fix Committed
Status in OpenStack Identity (keystone) ocata series:
Fix Committed
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From 1703369 at bugs.launchpad.net Wed Jul 26 04:46:54 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 26 Jul 2017 04:46:54 -0000
Subject: [Openstack-security] [Bug 1703369] Fix included in
openstack/keystone 10.0.3
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150104441418.6509.16216153437464447835.malone@gac.canonical.com>
This issue was fixed in the openstack/keystone 10.0.3 release.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
Fix Committed
Status in OpenStack Identity (keystone) ocata series:
Fix Committed
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From fungi at yuggoth.org Wed Jul 26 15:23:46 2017
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 26 Jul 2017 15:23:46 -0000
Subject: [Openstack-security] [Bug 1691662] Re: 11211 port for memcached is
not certified
References: <149508901995.5050.14822234702827071569.malonedeb@chaenomeles.canonical.com>
Message-ID: <150108262633.2809.11362626790747024645.malone@wampee.canonical.com>
Since this was originally opened as Public there wasn't much point in
switching it to Private Security once all the nova bug subscribers were
notified of it, so I've set it back to Public.
At this point, what consensus there is seems to be that this is an issue
which should be corrected in documentation and/or a concern with
memcached rather than any OpenStack software. It probably falls into
either report class B2 (A vulnerability without a complete fix yet,
security note for all versions, e.g., poor architecture / design) or C2
(A vulnerability, but not in OpenStack supported code, e.g., in a
dependency) in our taxonomy, and so should not need an advisory:
https://security.openstack.org/vmt-process.html#incident-report-taxonomy
** Information type changed from Private Security to Public
** Description changed:
- This issue is being treated as a potential security risk under embargo.
- Please do not make any public mention of embargoed (private) security
- vulnerabilities before their coordinated publication by the OpenStack
- Vulnerability Management Team in the form of an official OpenStack
- Security Advisory. This includes discussion of the bug or associated
- fixes in public forums such as mailing lists, code review systems and
- bug trackers. Please also avoid private disclosure to other individuals
- not already approved for access to this information, and provide this
- same reminder to those who are made aware of the issue prior to
- publication. All discussion should remain confined to this private bug
- report, and any proposed fixes should be added to the bug as
- attachments.
-
After the user logs in to the openstack node, the data stored in
memcached can be obtained with the command "memcached-tool 172.28.8.6:
11211 dump", and no authentication is required.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Tags added: security
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1691662
Title:
11211 port for memcached is not certified
Status in OpenStack Compute (nova):
Expired
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
After the user logs in to the openstack node, the data stored in
memcached can be obtained with the command "memcached-tool 172.28.8.6:
11211 dump", and no authentication is required.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1691662/+subscriptions
From lhinds at redhat.com Wed Jul 26 15:40:51 2017
From: lhinds at redhat.com (Luke Hinds)
Date: Wed, 26 Jul 2017 15:40:51 -0000
Subject: [Openstack-security] [Bug 1691662] Re: 11211 port for memcached is
not certified
References: <149508901995.5050.14822234702827071569.malonedeb@chaenomeles.canonical.com>
Message-ID: <150108365206.20470.14900529159897408153.malone@chaenomeles.canonical.com>
as sdague states, memcached should not be listening on any sort of
public interface, and this is covered in docs already:
https://docs.openstack.org/newton/install-guide-rdo/environment-
memcached.html
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1691662
Title:
11211 port for memcached is not certified
Status in OpenStack Compute (nova):
Expired
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
After the user logs in to the openstack node, the data stored in
memcached can be obtained with the command "memcached-tool 172.28.8.6:
11211 dump", and no authentication is required.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1691662/+subscriptions
From lhinds at redhat.com Wed Jul 26 15:42:48 2017
From: lhinds at redhat.com (Luke Hinds)
Date: Wed, 26 Jul 2017 15:42:48 -0000
Subject: [Openstack-security] [Bug 1691662] Re: 11211 port for memcached is
not certified
References: <149508901995.5050.14822234702827071569.malonedeb@chaenomeles.canonical.com>
Message-ID: <150108376900.19980.17897064888667615913.malone@chaenomeles.canonical.com>
just noticed the above was for RDO, however its the same for all dists:
https://docs.openstack.org/install-guide/environment-memcached-
ubuntu.html
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1691662
Title:
11211 port for memcached is not certified
Status in OpenStack Compute (nova):
Expired
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
After the user logs in to the openstack node, the data stored in
memcached can be obtained with the command "memcached-tool 172.28.8.6:
11211 dump", and no authentication is required.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1691662/+subscriptions
From lhinds at redhat.com Thu Jul 27 16:55:31 2017
From: lhinds at redhat.com (Luke Hinds)
Date: Thu, 27 Jul 2017 16:55:31 -0000
Subject: [Openstack-security] [Bug 1686743] Re: Ceph credentials included in
logs using older libvirt/qemu
References: <20170427142747.26531.54657.malonedeb@gac.canonical.com>
Message-ID: <150117453444.25109.3883767887258119710.launchpad@soybean.canonical.com>
** Changed in: ossn
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1686743
Title:
Ceph credentials included in logs using older libvirt/qemu
Status in OpenStack Compute (nova):
Opinion
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
Older versions of libvirt included network storage authentication
information on the qemu command line. If libvirt raises an exception
which logs the qemu command line it used, for example an error
starting a domain, this authentication information will end up in the
logs. There is an existing CVE for this issue here:
https://access.redhat.com/security/cve/CVE-2015-5160
Specifically, if a deployment is using ceph, a libvirt error starting
a domain would log the cephx secret key and the monitor addresses on
the qemu command line.
The issue has been resolved upstream. Users running qemu version 2.6
or later, and libvirt version 2.2 or later, are not vulnerable. No
change is required in Nova to resolve this issue.
Red Hat users running RHEL 7.3 or later are not vulnerable.
It's not 100% clear to me that an OpenStack CVE is required here as
it's not a bug in an OpenStack component, and it's already fixed
upstream. However, it did come to my attention after a user publicly
posted their ceph credentials on IRC, so evidently some OpenStack
users are running vulnerable systems, and this is a very common
configuration.
In Nova, we currently have:
MIN_LIBVIRT_VERSION = (1, 2, 9)
MIN_QEMU_VERSION = (2, 1, 0)
so anybody running the minimum supported versions will be vulnerable.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1686743/+subscriptions
From 1575913 at bugs.launchpad.net Thu Jul 27 20:58:48 2017
From: 1575913 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 27 Jul 2017 20:58:48 -0000
Subject: [Openstack-security] [Bug 1575913] Fix included in
openstack/horizon 12.0.0.0b3
References: <20160427202224.17621.97555.malonedeb@soybean.canonical.com>
Message-ID: <150118912837.2690.10808370615448649997.malone@wampee.canonical.com>
This issue was fixed in the openstack/horizon 12.0.0.0b3 development
milestone.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1575913
Title:
Generate and download keypair GET endpoint allows CSRF attacks
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Requests to create (and download) nova keypairs are made as GETs. As
such the CSRF token is not sent nor validated on these requests. This
breaks the principle Django's CSRF middleware relies upon which is
that requests with side effects should not cause side effects. I'm
told there was a reason for doing this related to being able to send
the data back to the browser, and that this may not be trivial to fix.
Filing this as a security bug since a malicious site could fool a user
into creating keypairs. The attacker would not gain access to the
contents, so the impact is not as serious as it might seem at first
glance.
See
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions
From 1703369 at bugs.launchpad.net Fri Jul 28 14:03:53 2017
From: 1703369 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 28 Jul 2017 14:03:53 -0000
Subject: [Openstack-security] [Bug 1703369] Fix included in
openstack/keystone 12.0.0.0b3
References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com>
Message-ID: <150125063336.4317.8106884773744945978.malone@gac.canonical.com>
This issue was fixed in the openstack/keystone 12.0.0.0b3 development
milestone.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) newton series:
Fix Committed
Status in OpenStack Identity (keystone) ocata series:
Fix Committed
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Confirmed
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions
From gerrit2 at review.openstack.org Fri Jul 28 17:24:03 2017
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 28 Jul 2017 17:24:03 +0000
Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review
request change I121b2e7641c77a4872a1e801eb039050e6a996ea
Message-ID:
Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/488541
Log:
commit bd4af8dfb7a57049e171bf36c89ebb667d003008
Author: Peter Hamilton
Date: Fri Jul 28 13:18:30 2017 -0400
Add support for certificate validation
This spec describes changes that would allow Nova to perform
certificate validation when verifying Glance image signatures.
While image signing ensures that image data is obtained
unmodified from Glance, it does not prevent an attacker from
uploading and signing a malicious image. The addition of Nova
API changes allows Nova users to control the certificates
which are allowed to sign images.
This spec describes work related to image verification. For
more information, see: https://review.openstack.org/#/c/343654
APIImpact
DocImpact
SecurityImpact
Change-Id: I121b2e7641c77a4872a1e801eb039050e6a996ea
From gerrit2 at review.openstack.org Fri Jul 28 17:34:36 2017
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 28 Jul 2017 17:34:36 +0000
Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review
request change I121b2e7641c77a4872a1e801eb039050e6a996ea
Message-ID:
Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/488541
Log:
commit beda550f103b1218e4d92bb3901158b3e19c088d
Author: Peter Hamilton
Date: Fri Jul 28 13:18:30 2017 -0400
Add support for certificate validation
This spec describes changes that would allow Nova to perform
certificate validation when verifying Glance image signatures.
While image signing ensures that image data is obtained
unmodified from Glance, it does not prevent an attacker from
uploading and signing a malicious image. The addition of Nova
API changes allows Nova users to control the certificates
which are allowed to sign images.
This spec describes work related to image verification. For
more information, see: https://review.openstack.org/#/c/343654
APIImpact
DocImpact
SecurityImpact
Previously-approved: Pike
Change-Id: I121b2e7641c77a4872a1e801eb039050e6a996ea