From tdecacqu at redhat.com Mon Nov 2 15:13:16 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 02 Nov 2015 15:13:16 -0000 Subject: [Openstack-security] [Bug 1471158] Re: Incorrect regular expressions used for schema validation References: <20150703091933.9600.68969.malonedeb@gac.canonical.com> Message-ID: <20151102151316.15346.73562.malone@chaenomeles.canonical.com> Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1471158 Title: Incorrect regular expressions used for schema validation Status in Designate: Fix Released Status in Designate juno series: Fix Committed Status in Designate kilo series: Fix Committed Status in OpenStack Security Advisory: Incomplete Bug description: The regular expressions listed in designate/schema/format.py allow trailing "\n" characters because "$" matches "\n" at the end of the string. Submitting a record creation request with "name" ending with "\n" currently results in an internal server, with the following traceback in the log file: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply executor_callback)) File "/usr/lib/python2.7/site-packages/designate/rpc.py", line 178, in _dispatch return super(RPCDispatcher, self)._dispatch(*args, **kwds) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch executor_callback) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 130, in _do_dispatch result = func(ctxt, **new_args) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 220, in wrapper result = f(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 194, in wrapper result = f(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 1119, in create_recordset context, domain, recordset, increment_serial=increment_serial) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 84, in wrapper **copy.deepcopy(kwargs)) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 123, in wrapper self.storage.rollback() File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 119, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 118, in wrapper result = f(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 1138, in _create_recordset_in_storage self._is_valid_recordset_name(context, domain, recordset.name) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 341, in _is_valid_recordset_name raise ValueError('Please supply a FQDN') ValueError: Please supply a FQDN If such additional checks are everywhere, the incorrect regular expressions should be harmless, and the security flag can be removed. Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1235655 To manage notifications about this bug go to: https://bugs.launchpad.net/designate/+bug/1471158/+subscriptions From sean_mcginnis at dell.com Sun Nov 1 21:35:07 2015 From: sean_mcginnis at dell.com (Sean McGinnis) Date: Sun, 01 Nov 2015 21:35:07 -0000 Subject: [Openstack-security] [Bug 1375599] Re: Cinder should not publish sensitive data such as user token in notifications. References: <20140930070610.4767.44598.malonedeb@wampee.canonical.com> Message-ID: <20151101213507.15307.73437.malone@chaenomeles.canonical.com> Closing stale bug. If this is still an issue please reopen. ** Changed in: cinder Status: New => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1375599 Title: Cinder should not publish sensitive data such as user token in notifications. Status in Cinder: Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: Here is a message captured in rabbitmq: ctxt: {u'domain': None, u'project_name': u'admin', u'user_id': u'f6fafd3282a841849a01beeb80fd3161', u'roles': [u'heat_stack_owner', u'_member_', u'admin'], u'user_identity': u'f6fafd3282a841849a01beeb80fd3161 d6acdbfa2bba426c912f214c665e78d9 - - -', u'project_domain': None, u'timestamp': u'2014-09-25T07:01:02.936829', u'auth_token': u'bac7c01f4eb1412b841ab819ceddc5ad', u'remote_address': u'19.0.0.99', u'quota_class': None, u'project_id': u'd6acdbfa2bba426c912f214c665e78d9', u'is_admin': True, u'user': u'f6fafd3282a841849a01beeb80fd3161', u'service_catalog': [{u'endpoints': [{u'adminURL': u'http://19.0.0.99:8774/v2/d6acdbfa2bba426c912f214c665e78d9', u'region': u'RegionOne', u'internalURL': u'http://19.0.0.99:8774/v2/d6acdbfa2bba426c912f214c665e78d9', u'publicURL': u'http://19.0.0.99:8774/v2/d6acdbfa2bba426c912f214c665e78d9'}], u'type': u'compute', u'name': u'nova'}], u'request_id': u'req-623ecb62-0660-4264-b0d3-04eb13f54914', u'user_domain': None, u'read_deleted': u'no', u'tenant': u'd6acdbfa2bba426c912f214c665e78d9'} publisher_id: volume.aj-celiometer at lvmdriver-1 event_type: volume.delete.end payload: {u'status': u'deleting', u'instance_uuid': None, u'user_id': u'f6fafd3282a841849a01beeb80fd3161', u'availability_zone': u'nova', u'tenant_id': u'd6acdbfa2bba426c912f214c665e78d9', u'created_at': u'2014-09-24 14:11:42', u'snapshot_id': None, u'volume_type': u'0bc2a44a-fd19-4448-8399-1538fc8724e5', u'host': u'aj-celiometer at lvmdriver-1#lvmdriver-1', u'replication_status': u'disabled', u'volume_id': u'25102eee-9e82-4ba8-8f8c-17bc52c6519f', u'replication_extended_status': None, u'replication_driver_data': None, u'size': 1, u'launched_at': u'2014-09-24 14:11:42', u'display_name': None} metadata: {'timestamp': u'2014-09-25 07:01:19.271715', 'message_id': u'9c77a382-05c2-4014-a1a9-cbc41b2d2eb7'} To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1375599/+subscriptions From sean_mcginnis at dell.com Sun Nov 1 21:31:08 2015 From: sean_mcginnis at dell.com (Sean McGinnis) Date: Sun, 01 Nov 2015 21:31:08 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20151101213108.31691.11952.malone@wampee.canonical.com> Closing stale bug. If this is still an issue please reopen. ** Changed in: cinder Status: Confirmed => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From kathleen.m.fischer at nasa.gov Wed Nov 4 13:35:03 2015 From: kathleen.m.fischer at nasa.gov (Fischer, Kathleen M. (KSC-ESC-712)[VENCORE-ESC]) Date: Wed, 4 Nov 2015 13:35:03 +0000 Subject: [Openstack-security] Good work security group! In-Reply-To: References: Message-ID: <37F5D0FC8B815D479969E4FC1F09906C0511C3E7@NDMSMBX401.ndc.nasa.gov> Kudos!   Kathleen Mayer Fischer/ CECS, FITSI-A / Vencore 3PAO, Vencore IT Systems and Cloud Security On 10/25/15, 1:00 PM, "openstack-security-request at lists.openstack.org" wrote: >Hi all, > >Just wanted to let all of you involved in OpenStack security know that >the group got a shout out at Ruxcon security conference for security >engineering done right. It was mentioned in context of being easy to >reach, having good process of dealing with reports and security >engineering in general. Another slide mentioned Bandit and cross >project guidelines >(https://pbs.twimg.com/media/CSHpRzJU8AAu8fj.jpg:large). > > >The talk was not related to OpenStack in any way ? it was about >security in general. Well done to everyone involved! > > >Best Regards, > >Stanis?aw Pitucha From gerrit2 at review.openstack.org Wed Nov 4 19:59:07 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Nov 2015 19:59:07 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If143638a5ae21068c062048dc6e5e91b31cd524f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/232371 Log: commit 111c3a79075d3f9dab17dd0d6ccd2200beac79a1 Author: bria4010 Date: Thu Oct 8 02:59:21 2015 -0400 Image Import Refactor This spec proposes a refactoring of the Glance image import functionality along the lines worked out during discussions at the Mitka summit. ApiImpact DocImpact SecurityImpact Change-Id: If143638a5ae21068c062048dc6e5e91b31cd524f Implements: blueprint image-import-refactor From dmccowan at cisco.com Wed Nov 4 22:22:37 2015 From: dmccowan at cisco.com (Dave McCowan) Date: Wed, 04 Nov 2015 22:22:37 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20151104222237.22876.28047.malone@gac.canonical.com> @rydou: What browser did you use that did not include an Origin header? @Abel: Getting consoles for the same instance from different hosts is not the vulnerability. The vulnerability is getting access to the same instance from the same browser, but using websocket code downloaded from a different server (hijacking the existing connection). I'll follow up with you offline. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From gerrit2 at review.openstack.org Thu Nov 5 18:16:11 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Nov 2015 18:16:11 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit f3d2506969a0aacc9238b1b259394eaf4acde374 Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact It depends on this glance spec: Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From gerrit2 at review.openstack.org Fri Nov 6 14:26:13 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Nov 2015 14:26:13 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit b9ba3a526e6002befeb84df73ff61699476bc958 Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From gerrit2 at review.openstack.org Fri Nov 6 15:12:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Nov 2015 15:12:52 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ic9cf9862739381a30130b4be87075f726736ff88 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/240719 Log: commit 4f08560bb60f99e32cb017de481426e4831960a1 Author: Adam Young Date: Sun Oct 11 23:15:52 2015 -0400 set `is_admin` on tokens for admin project Adds two new configuration value: admin_project_name admin_project_domain_name If both values are set, and tokens requested for projects (only, not domains) that match both will have an additional value in them; `is_admin_project=true` DocImpact -- Configuration changes need documentation APIImpact -- Adds optional return values in token validation calls SecurityImpact -- Should be helpful in making access control decisions Implements: blueprint is-admin-project Closes-Bug: #968696 Change-Id: Ic9cf9862739381a30130b4be87075f726736ff88 From gerrit2 at review.openstack.org Fri Nov 6 16:29:53 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Nov 2015 16:29:53 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ic9cf9862739381a30130b4be87075f726736ff88 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/240719 Log: commit 0956ba4be0a095b665a431291060bdfa03b8eac9 Author: Adam Young Date: Sun Oct 11 23:15:52 2015 -0400 set `is_admin` on tokens for admin project Adds two new configuration value: admin_project_name admin_project_domain_name If both values are set, and tokens requested for projects (only, not domains) that match both will have an additional value in them; `is_admin_project=true` DocImpact -- Configuration changes need documentation APIImpact -- Adds optional return values in token validation calls SecurityImpact -- Should be helpful in making access control decisions Implements: blueprint is-admin-project Closes-Bug: #968696 Change-Id: Ic9cf9862739381a30130b4be87075f726736ff88 From gerrit2 at review.openstack.org Fri Nov 6 17:51:54 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Nov 2015 17:51:54 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Ibd84f475db464498fa9daed4454fdcd6ccd9c37c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/125704 Log: commit 5deabe4b7ffea1e91bb6babd6bcef41ec81fc885 Author: Adam Young Date: Thu Oct 2 12:38:31 2014 -0400 Implied Roles When assigned a role, the user will also be assigned all roles implied by any prior roles The hierarchy of the roles will be expanded when issuing a token. DocImpact SecurityImpact Change-Id: Ibd84f475db464498fa9daed4454fdcd6ccd9c37c From gerrit2 at review.openstack.org Mon Nov 9 11:29:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Nov 2015 11:29:52 +0000 Subject: [Openstack-security] [openstack/swift] SecurityImpact review request change I1f629987fbc8c59406432faad9cb2bfa34b5eccc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/227855 Log: commit 1d7a8b4134d889c44f38a62eab4ae600f5d84c48 Author: janonymous Date: Fri Sep 25 19:13:28 2015 +0530 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time. eg: $ time nc localhost 8776 real 1m0.063s Added Parameters in Initial commit that needs to be changed as appropriate for swift configuration. DocImpact: Added wsgi_keep_alive option (default=False). SecurityImpact Closes-Bug: #1361360 Change-Id: I1f629987fbc8c59406432faad9cb2bfa34b5eccc From gerrit2 at review.openstack.org Mon Nov 9 12:46:58 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Nov 2015 12:46:58 +0000 Subject: [Openstack-security] [openstack/swift] SecurityImpact review request change I1f629987fbc8c59406432faad9cb2bfa34b5eccc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/227855 Log: commit 886e6ccb340c34622eb3e31e997e988ee22becfb Author: janonymous Date: Fri Sep 25 19:13:28 2015 +0530 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Allows closing idle client connections after a period of time. eg: $ time nc localhost 8776 real 1m0.063s Added Parameters in Initial commit that needs to be changed as appropriate for swift configuration. DocImpact: Added wsgi_keep_alive option (default=False). SecurityImpact Closes-Bug: #1361360 Change-Id: I1f629987fbc8c59406432faad9cb2bfa34b5eccc From 1514569 at bugs.launchpad.net Mon Nov 9 20:11:58 2015 From: 1514569 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 09 Nov 2015 20:11:58 -0000 Subject: [Openstack-security] [Bug 1514569] Re: Fix Postgres root-enable References: <20151109195235.21620.71031.malonedeb@soybean.canonical.com> Message-ID: <20151109201158.23008.51132.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/243292 ** Changed in: trove Status: New => 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/1514569 Title: Fix Postgres root-enable Status in Trove: In Progress Bug description: Fix PostgreSQL root functions The default PostgreSQL administration account is 'postgres'. In the current implementation Trove uses the 'postgres' account and return a new superuser called 'root' when the root access is requested. The user 'root' has however no special meaning in PostgreSQL and the existing applications may rely on the default superuser name 'postgres'. Trove should be using its own administrative account (os_admin) instead. Notes: The current implementation is broken for variaous reasons: - It uses UUIDs in place of 'secure' password. - It creates a 'root' user, but no database for it. The clients won't be able to authenticate without explicitly providing an existing database name. - The created 'root' user has no 'SUPERUSER' attribute and hence is not a real superuser (cannot perform certain tasks)... - The implementation suffers a defect that allows a non-root user gain root access to an instance without marking is as 'root-enabled' A similar defect exists in other datastores (MySQL) too: 1. Create an instance. 2. Enable root. 3. Use your root access to change the password of the built-in 'postgres' account (Trove will still work because it uses the 'peer' authentication method - the UNIX account). 4. Login as 'postgres' using the changed password and drop the created 'root' account. 5. Backup & restore the instance. 6. Trove reports the root has never been enabled (it checks for existence of superuser accounts other than the built-in 'postgres'). 7. You enjoy the root access of the 'postgres' user (the password is not reset on restore). To manage notifications about this bug go to: https://bugs.launchpad.net/trove/+bug/1514569/+subscriptions From gerrit2 at review.openstack.org Tue Nov 10 02:43:15 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Nov 2015 02:43:15 +0000 Subject: [Openstack-security] [openstack/swift] SecurityImpact review request change I1f629987fbc8c59406432faad9cb2bfa34b5eccc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/227855 Log: commit ba79354aaa9b4bd6a4b62fadd1dacf136884505d Author: janonymous Date: Fri Sep 25 19:13:28 2015 +0530 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Allows closing idle client connections after a period of time. eg: $ time nc localhost 8776 real 1m0.063s Added Parameters in Initial commit that needs to be changed as appropriate for swift configuration. DocImpact: Added keepalive option (default=False). SecurityImpact Closes-Bug: #1361360 Change-Id: I1f629987fbc8c59406432faad9cb2bfa34b5eccc From fungi at yuggoth.org Tue Nov 10 14:40:16 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 10 Nov 2015 14:40:16 -0000 Subject: [Openstack-security] [Bug 1422046] Re: cinder backup-list is always listing all tenants's bug for admin References: <20150215013602.20879.11525.malonedeb@wampee.canonical.com> Message-ID: <20151110144016.31624.17194.malone@chaenomeles.canonical.com> Correct, we consider that latter case a "security hardening opportunity" and I'm triaging this report as one now (class D in our taxonomy https://security.openstack.org/vmt-process.html#incident-report-taxonomy ). Depending on severity and available time from editors in the Security Team, these sorts of issues sometimes get an OpenStack Security Note published (OSSN rather than OSSA). ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public ** 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/1422046 Title: cinder backup-list is always listing all tenants's bug for admin Status in OpenStack Dashboard (Horizon): New Status in ospurge: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in python-cinderclient: Fix Released Status in python-cinderclient package in Ubuntu: Confirmed Bug description: cinder backup-list doesn't support '--all-tenants' argument for admin wright now. This lead to admin always getting all tenants's backups. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1422046/+subscriptions From fungi at yuggoth.org Tue Nov 10 15:21:44 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 10 Nov 2015 15:21:44 -0000 Subject: [Openstack-security] [Bug 1514396] Re: cinder backup-list is always listing all tenants's bug for admin in V1 api References: <20151109111138.23414.38152.malonedeb@gac.canonical.com> Message-ID: <20151110152144.31696.15046.malone@chaenomeles.canonical.com> As with related bug 1422046, I'm similarly triaging this as a security hardening opportunity (class D in our taxonomy https://security.openstack.org/vmt-process.html#incident-report-taxonomy ). ** Changed in: ossa Status: Incomplete => 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/1514396 Title: cinder backup-list is always listing all tenants's bug for admin in V1 api Status in ospurge: Confirmed Status in OpenStack Security Advisory: Won't Fix Status in python-cinderclient: Confirmed Bug description: https://bugs.launchpad.net/python-cinderclient/+bug/1422046 has been fixed for V2 only This is a security issue cause it leads to deleting all production backups when logged as admin To manage notifications about this bug go to: https://bugs.launchpad.net/ospurge/+bug/1514396/+subscriptions From 1434545 at bugs.launchpad.net Tue Nov 10 17:10:33 2015 From: 1434545 at bugs.launchpad.net (Amrith) Date: Tue, 10 Nov 2015 17:10:33 -0000 Subject: [Openstack-security] [Bug 1434545] Re: Several command injection vulnerabilities in guestagent/pkg References: <20150320131103.23017.37206.malonedeb@chaenomeles.canonical.com> Message-ID: <20151110171035.1265.56522.launchpad@wampee.canonical.com> ** Changed in: trove Importance: High => Medium -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434545 Title: Several command injection vulnerabilities in guestagent/pkg Status in OpenStack Security Advisory: Won't Fix Status in Trove: Triaged Bug description: At several places in the file guestagent/pkg.py, there are shell injection vulnerabilities: https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L209 In this line, the cmd_list is being built parameterized, but then it is just combined into one big string and called directly on a shell through the command getstatusoutput, which does a popen. If package name is set maliciously, the command will execute arbitrary code with the privilege of the trove process. The same is true on this line, https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L258 , where a package named something like "abc; rm -rf /etc" will cause all files in /etc which Trove has permissions for, to be deleted. Again, on this line: https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L371 , a malicious package name will cause arbitrary code injection with the privileges of the Trove process. I'm not nearly familiar enough with the Trove code and uses to know all the ways that package names for this code can be set, but these commands should be parameterized. Finally, os.popen is a deprecated function. The subprocess module should be used instead. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1434545/+subscriptions From 1465922 at bugs.launchpad.net Wed Nov 11 22:10:43 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Nov 2015 22:10:43 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20151111221043.1149.69623.malone@gac.canonical.com> Reviewed: https://review.openstack.org/201328 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a7037547fecf0998ea09b1139123c3c1ef97472d Submitter: Jenkins Branch: stable/juno commit a7037547fecf0998ea09b1139123c3c1ef97472d Author: Brant Knudson Date: Fri Jun 19 14:40:30 2015 -0500 Add test showing password logged There was no test that showed that the password is logged when a user is created or admin changes user password. Conflicts: keystone/tests/unit/test_v3_identity.py Change-Id: I5ffa04e9ac359355cff47a622731f1bf6a27ea7b Partial-Bug: #1465922 (cherry picked from commit c2c3a0ff86314bee3d62f69d30206ff7584f229f) (cherry picked from commit fba2d5c15e298e0936800a0e3d1ff7588235c359) ** Tags added: in-stable-juno -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: In Progress Status in OpenStack Identity (keystone) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Wed Nov 11 23:42:02 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Nov 2015 23:42:02 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20151111234202.1742.23392.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/201329 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=c15cbc48d63e9cb6a6994ffc73fded2464a8651c Submitter: Jenkins Branch: stable/juno commit c15cbc48d63e9cb6a6994ffc73fded2464a8651c Author: Brant Knudson Date: Fri Jun 19 14:18:18 2015 -0500 Mask passwords in debug log on user password operations When a user is created, they change their password, or admin changes their password and debug logging is enabled, the value of the user's password was logged. The value should be masked. Conflicts: keystone/common/controller.py keystone/tests/unit/test_v3_identity.py Change-Id: I07b7441378fb630f01204d6b656b218f6b94dd5a Closes-Bug: #1465922 (cherry picked from commit fbdb100e656b19958589fa659bf9d95303e76ab8) (cherry picked from commit c4dc1331e111f6fce070163129cef008a204e99f) ** Changed in: keystone/juno 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/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (keystone) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1361360 at bugs.launchpad.net Sat Nov 14 10:32:07 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 10:32:07 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151114103207.16242.6277.launchpad@soybean.canonical.com> ** Also affects: glance/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in Glance juno series: New Status in heat: Fix Released Status in heat kilo series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (keystone) kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: Fix Committed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1274034 at bugs.launchpad.net Sat Nov 14 10:34:03 2015 From: 1274034 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 10:34:03 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20151114103403.22164.37047.launchpad@wampee.canonical.com> ** Also affects: neutron/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Status in OpenStack Security Advisory: 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 From 1414532 at bugs.launchpad.net Sat Nov 14 15:04:37 2015 From: 1414532 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 15:04:37 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20151114150440.26289.98026.launchpad@wampee.canonical.com> ** Changed in: glance/juno Milestone: None => 2014.2.4 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in Glance: Fix Released Status in Glance juno series: Fix Committed Status in OpenStack Security Advisory: 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 From 1465922 at bugs.launchpad.net Sat Nov 14 15:06:17 2015 From: 1465922 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 15:06:17 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20151114150619.12607.43101.launchpad@chaenomeles.canonical.com> ** Changed in: keystone/juno Milestone: None => 2014.2.4 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (keystone) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1361360 at bugs.launchpad.net Sat Nov 14 15:04:32 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 15:04:32 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151114150436.12019.62232.launchpad@chaenomeles.canonical.com> ** Changed in: glance/juno Status: New => Fix Committed ** Changed in: glance/juno Milestone: None => 2014.2.4 ** Changed in: keystone/juno Milestone: None => 2014.2.4 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in Glance juno series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (keystone) kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: Fix Committed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1274034 at bugs.launchpad.net Sat Nov 14 15:07:02 2015 From: 1274034 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 15:07:02 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20151114150704.4300.67582.launchpad@gac.canonical.com> ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Milestone: None => 2014.2.4 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in neutron juno series: Fix Committed Status in neutron kilo series: Fix Released Status in OpenStack Security Advisory: 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 From 1451931 at bugs.launchpad.net Sat Nov 14 15:10:53 2015 From: 1451931 at bugs.launchpad.net (Alan Pevec) Date: Sat, 14 Nov 2015 15:10:53 -0000 Subject: [Openstack-security] [Bug 1451931] Re: ironic password config not marked as secret References: <20150505164255.28640.31104.malonedeb@soybean.canonical.com> Message-ID: <20151114151056.22127.25109.launchpad@wampee.canonical.com> ** Changed in: nova/juno Milestone: None => 2014.2.4 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. 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 Committed 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 From 1465922 at bugs.launchpad.net Sun Nov 15 16:28:12 2015 From: 1465922 at bugs.launchpad.net (Robert Clark) Date: Sun, 15 Nov 2015 16:28:12 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20151115162812.21891.77678.malone@wampee.canonical.com> We would typically issue an OSSN for such behaviour, it's somewhat boilerplate but it's important to document the issue, particularly as a number of production workloads run in debug mode. I also think it's interesting that Bandit didn't catch this, it's pretty good at finding these sorts of issues. ** Also affects: bandit Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Bandit: New Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (keystone) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/bandit/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Sun Nov 15 16:29:06 2015 From: 1465922 at bugs.launchpad.net (Robert Clark) Date: Sun, 15 Nov 2015 16:29:06 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20151115162906.22486.11135.malone@wampee.canonical.com> Added bandit bug so those guys can take a look to see if this can be caught in future. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Bandit: New Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (keystone) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/bandit/+bug/1465922/+subscriptions From gerrit2 at review.openstack.org Mon Nov 16 21:15:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Nov 2015 21:15:05 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ic5f4d4c26794550a92481bf2b725ef5eafa581b2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/245987 Log: commit b82ebc81171554dd672e13e9c97167ceacf264a6 Author: Matt Riedemann Date: Mon Nov 16 13:11:09 2015 -0800 xen: mask auth_password in StorageError raised from _parse_volume_info The connection_data dict can have credentials in it, so we need to scrub those before putting the stringified dict into the StorageError message and raising that up. Note that strutils.mask_password converts the dict to a string using six.text_type so we don't have to do that conversion first. This could show up in the logs because of the attach_volume flow where if that fails, the nova.virt.block_device attach code will log it. SecurityImpact Change-Id: Ic5f4d4c26794550a92481bf2b725ef5eafa581b2 Closes-Bug: #1516765 From nkinder at redhat.com Mon Nov 16 21:35:08 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 16 Nov 2015 21:35:08 -0000 Subject: [Openstack-security] [Bug 1456228] Re: Trusted vm can be powered on untrusted host References: <20150518141406.21329.60661.malonedeb@wampee.canonical.com> Message-ID: <20151116213509.4509.77782.malone@chaenomeles.canonical.com> 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 OpenStack Security, which is subscribed to OpenStack. 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 at 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 From nkinder at redhat.com Mon Nov 16 21:37:15 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 16 Nov 2015 21:37:15 -0000 Subject: [Openstack-security] [Bug 1451931] Re: ironic password config not marked as secret References: <20150505164255.28640.31104.malonedeb@soybean.canonical.com> Message-ID: <20151116213716.19284.21463.malone@wampee.canonical.com> 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 OpenStack Security, which is subscribed to OpenStack. 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 From gerrit2 at review.openstack.org Mon Nov 16 22:07:28 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Nov 2015 22:07:28 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ic5f4d4c26794550a92481bf2b725ef5eafa581b2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/245987 Log: commit 4a090f68a984685a0e1a22feddefffd410caf3e4 Author: Matt Riedemann Date: Mon Nov 16 13:11:09 2015 -0800 xen: mask passwords in volume connection_data dict The connection_data dict can have credentials in it, so we need to scrub those before putting the stringified dict into the StorageError message and raising that up and when logging the dict. Note that strutils.mask_password converts the dict to a string using six.text_type so we don't have to do that conversion first. SecurityImpact Change-Id: Ic5f4d4c26794550a92481bf2b725ef5eafa581b2 Closes-Bug: #1516765 From 1447679 at bugs.launchpad.net Tue Nov 17 01:10:35 2015 From: 1447679 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 Nov 2015 01:10:35 -0000 Subject: [Openstack-security] [Bug 1447679] Change abandoned on nova (master) References: <20150423154044.13260.70404.malonedeb@chaenomeles.canonical.com> Message-ID: <20151117011036.4801.14378.malone@chaenomeles.canonical.com> Change abandoned by Michael Still (mikal at stillhq.com) on branch: master Review: https://review.openstack.org/182129 Reason: This change has stalled. Please restore it if that's not the case. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1447679 Title: service No-VNC (port 6080) doesn't require authentication Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Reported via private E-mail from Anass ANNOUR: I found that the service No-VNC (port 6080) doesn't require authentication, if you know the URL (ex: http://192.168.198.164:6080/vnc_auto.html?token=3640a3c8-ad10-45da-a523-18d3793ef8ec) you can access the machine from any other computer without any authentication before the token expires. (or in the same time as user still use the console) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1447679/+subscriptions From gerrit2 at review.openstack.org Tue Nov 17 01:53:10 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Nov 2015 01:53:10 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Ibd84f475db464498fa9daed4454fdcd6ccd9c37c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/125704 Log: commit 4c8732b016d6538c8279445300e3a58c9c407ee1 Author: Adam Young Date: Thu Oct 2 12:38:31 2014 -0400 Implied Roles When assigned a role, the user will also be assigned all roles implied by any prior roles The hierarchy of the roles will be expanded when issuing a token. DocImpact SecurityImpact Change-Id: Ibd84f475db464498fa9daed4454fdcd6ccd9c37c From gerrit2 at review.openstack.org Tue Nov 17 02:30:29 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Nov 2015 02:30:29 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I2531506fcd3b31fc2b733ee0cc5c4911a6528e1a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/245537 Log: commit 05ff08b8d9d5cc3ba7e58a57116a4a3ce311d0bf Author: changzhi Date: Sun Nov 15 21:52:24 2015 +0800 Create default sg rules when create a sg Default security group rules will be created when create security group. Sometimes we need to create default security rules when create new security groups. The format of default security group rules is "ethertype,direction,protocol,port_range_min,port_range_max". For example, security_group_default_rules=ethertype,ingress,tcp,22,22:ethertype,ingress,tcp,80,80 Related-bp: https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group DocImpact SecurityImpact Change-Id: I2531506fcd3b31fc2b733ee0cc5c4911a6528e1a From gerrit2 at review.openstack.org Tue Nov 17 05:52:11 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Nov 2015 05:52:11 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I2531506fcd3b31fc2b733ee0cc5c4911a6528e1a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/245537 Log: commit 104549a0933dd7e5b9f90e350f644d126d6cadf7 Author: changzhi Date: Sun Nov 15 21:52:24 2015 +0800 Create default sg rules when create a sg Sometimes we need to create a default security rule when a new security group is created. The following patch facilitates the same. The format of default security group rule is "ethertype,direction,protocol,port_range_min,port_range_max". For example: security_group_default_rules=ipv4,ingress,tcp,22,22:ipv4,ingress,tcp,80,80 Related-bp: https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group DocImpact SecurityImpact Change-Id: I2531506fcd3b31fc2b733ee0cc5c4911a6528e1a From gerrit2 at review.openstack.org Tue Nov 17 15:24:17 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Nov 2015 15:24:17 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Ibd84f475db464498fa9daed4454fdcd6ccd9c37c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/125704 Log: commit d48aab174f9a7316a79f67011f24cff059a901df Author: Adam Young Date: Thu Oct 2 12:38:31 2014 -0400 Implied Roles When assigned a role, the user will also be assigned all roles implied by any prior roles The hierarchy of the roles will be expanded when issuing a token. DocImpact SecurityImpact Change-Id: Ibd84f475db464498fa9daed4454fdcd6ccd9c37c From tdecacqu at redhat.com Tue Nov 17 17:00:48 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 17 Nov 2015 17:00:48 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151117170048.4242.33645.malone@chaenomeles.canonical.com> Is this something a regular user can abuse ? (iirc role assignment requires adminess) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Incomplete Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From 1499555 at bugs.launchpad.net Tue Nov 17 17:56:34 2015 From: 1499555 at bugs.launchpad.net (Guang Yee) Date: Tue, 17 Nov 2015 17:56:34 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151117175634.21461.77524.malone@wampee.canonical.com> Only admin can perform role assignments so this is not so much as abuse as putting a safety mechanism in place to help them deal with the architectural limitations. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Incomplete Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From tdecacqu at redhat.com Tue Nov 17 18:07:38 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 17 Nov 2015 18:07:38 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151117180738.4723.62947.malone@chaenomeles.canonical.com> Then according to VMT taxonomy ( https://security.openstack.org/vmt- process.html#incident-report-taxonomy ), this sounds more like a class D. ** Changed in: ossa Status: Incomplete => 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/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From 1499555 at bugs.launchpad.net Tue Nov 17 21:34:37 2015 From: 1499555 at bugs.launchpad.net (Guang Yee) Date: Tue, 17 Nov 2015 21:34:37 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151117213437.7620.83839.malone@soybean.canonical.com> Yes I agree this is more like a class D. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From 1369865 at bugs.launchpad.net Tue Nov 17 21:36:59 2015 From: 1369865 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 Nov 2015 21:36:59 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20151117213659.18079.48700.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/246611 ** Changed in: horizon 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/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): In Progress Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard