From 1858186 at bugs.launchpad.net Fri Jan 3 08:11:26 2020 From: 1858186 at bugs.launchpad.net (kuangpeiling) Date: Fri, 03 Jan 2020 08:11:26 -0000 Subject: [Openstack-security] [Bug 1858186] [NEW] http_log_request will print debug info include pki certificate which is unsafety Message-ID: <157803908613.28078.11140836620628209429.malonedeb@chaenomeles.canonical.com> Public bug reported: when i use pki token,i find nova debug log include the whole pki certificate info,is this safety?need to modify? my request is curl -g -i -X GET https://identity.az1.dc1.domainname.com:443/identity-admin/v3/auth/tokens/OS-PKI/revoked debug.log such as: RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfs0QO\n-----END CMS-----\n"} ** Affects: keystoneauth Importance: Undecided Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1858186 Title: http_log_request will print debug info include pki certificate which is unsafety Status in keystoneauth: New Bug description: when i use pki token,i find nova debug log include the whole pki certificate info,is this safety?need to modify? my request is curl -g -i -X GET https://identity.az1.dc1.domainname.com:443/identity-admin/v3/auth/tokens/OS-PKI/revoked debug.log such as: RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfs0QO\n-----END CMS-----\n"} To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1858186/+subscriptions From 1858186 at bugs.launchpad.net Fri Jan 3 08:17:59 2020 From: 1858186 at bugs.launchpad.net (kuangpeiling) Date: Fri, 03 Jan 2020 08:17:59 -0000 Subject: [Openstack-security] [Bug 1858186] Re: http_log_request will print debug info include pki certificate which is unsafety References: <157803908613.28078.11140836620628209429.malonedeb@chaenomeles.canonical.com> Message-ID: <157803948032.22193.9263247187230689430.launchpad@wampee.canonical.com> ** Description changed: when i use pki token,i find nova debug log include the whole pki certificate info,is this safety?need to modify? - my request is + my request is curl -g -i -X GET https://identity.az1.dc1.domainname.com:443/identity-admin/v3/auth/tokens/OS-PKI/revoked - debug.log: - RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwYJKoZIhvcNAQcCoIIBrDCCAagCAQExDTALBglghkgBZQMEAgEwHgYJKoZI\nhvcNAQcBoBEED3sicmV2b2tlZCI6IFtdfTGCAXIwggFuAgEBMEkwPTELMAkGA1UE\nBhMCQ04xDzANBgNVBAoTBkh1YXdlaTEdMBsGA1UEAxMUSHVhd2VpIElUIFByb2R1\nY3QgQ0ECCBWpkSG6QZq3MAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQDF\nbzhT6VPqrir7wnKvxVxH+sYthHMX0Om+OaMecCL+VnQE1wcg7tAAh1LI7Z6qkSAr\nF1FnrQeq6PV+8EbD4ZsvfLisk0NHI8IgnS36dyTznitddX7zPTVl4g3TQVox2Qmm\nnPSYrqDx6bLxDQGcuMANkpbCDrlqmmOio2BMboHi6V6aNRMPdYGYOVAKxuYbt3s8\n3FDEsM/DpEDywdhQiXGL2fa81QaXIuu5LaS1wUbb8IBEtwF8YkZOS7tOWSSUxsZ9\nNdjKEmhBUN4qFg5yTRKU7WLVegrZnwKPFbcdqMbeDVcgGT0bcEhtBIa90uKI50Fb\nB6PVg7DpfJdPTE/fs0QO\n-----END CMS-----\n"} + debug.log such as: + RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfs0QO\n-----END CMS-----\n"} ** Description changed: when i use pki token,i find nova debug log include the whole pki certificate info,is this safety?need to modify? my request is curl -g -i -X GET https://identity.az1.dc1.domainname.com:443/identity-admin/v3/auth/tokens/OS-PKI/revoked debug.log such as: RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfs0QO\n-----END CMS-----\n"} + + code session.py: + if response is not None: + if not status_code: + status_code = response.status_code + if not headers: + headers = response.headers + if not text: + # NOTE(samueldmq): If the response does not provide enough info + # about the content type to decide whether it is useful and + # safe to log it or not, just do not log the body. Trying to + # read the response body anyways may result on reading a long + # stream of bytes and getting an unexpected MemoryError. See + # bug 1616105 for further details. + content_type = response.headers.get('content-type', None) + + # NOTE(lamt): Per [1], the Content-Type header can be of the + # form Content-Type := type "/" subtype *[";" parameter] + # [1] https://www.w3.org/Protocols/rfc1341/4_Content-Type.html + for log_type in _LOG_CONTENT_TYPES: + if content_type is not None and content_type.startswith( + log_type): + text = self._remove_service_catalog(response.text) + break + else: + text = ('Omitted, Content-Type is set to %s. Only ' + '%s responses have their bodies logged.') + text = text % (content_type, ', '.join(_LOG_CONTENT_TYPES)) + if json: + text = self._json.encode(json) + + string_parts = ['RESP:'] + + if status_code: + string_parts.append('[%s]' % status_code) + if headers: + for header in six.iteritems(headers): + string_parts.append('%s: %s' % self._process_header(header)) + if text: + string_parts.append('\nRESP BODY: %s\n' % text) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1858186 Title: http_log_request will print debug info include pki certificate which is unsafety Status in keystoneauth: Invalid Bug description: when i use pki token,i find nova debug log include the whole pki certificate info,is this safety?need to modify? my request is curl -g -i -X GET https://identity.az1.dc1.domainname.com:443/identity-admin/v3/auth/tokens/OS-PKI/revoked debug.log such as: RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfs0QO\n-----END CMS-----\n"} code session.py: if response is not None: if not status_code: status_code = response.status_code if not headers: headers = response.headers if not text: # NOTE(samueldmq): If the response does not provide enough info # about the content type to decide whether it is useful and # safe to log it or not, just do not log the body. Trying to # read the response body anyways may result on reading a long # stream of bytes and getting an unexpected MemoryError. See # bug 1616105 for further details. content_type = response.headers.get('content-type', None) # NOTE(lamt): Per [1], the Content-Type header can be of the # form Content-Type := type "/" subtype *[";" parameter] # [1] https://www.w3.org/Protocols/rfc1341/4_Content-Type.html for log_type in _LOG_CONTENT_TYPES: if content_type is not None and content_type.startswith( log_type): text = self._remove_service_catalog(response.text) break else: text = ('Omitted, Content-Type is set to %s. Only ' '%s responses have their bodies logged.') text = text % (content_type, ', '.join(_LOG_CONTENT_TYPES)) if json: text = self._json.encode(json) string_parts = ['RESP:'] if status_code: string_parts.append('[%s]' % status_code) if headers: for header in six.iteritems(headers): string_parts.append('%s: %s' % self._process_header(header)) if text: string_parts.append('\nRESP BODY: %s\n' % text) To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1858186/+subscriptions From 1858186 at bugs.launchpad.net Fri Jan 3 08:28:54 2020 From: 1858186 at bugs.launchpad.net (kuangpeiling) Date: Fri, 03 Jan 2020 08:28:54 -0000 Subject: [Openstack-security] [Bug 1858186] Re: http_log_request will print debug info include pki certificate which is unsafety References: <157803908613.28078.11140836620628209429.malonedeb@chaenomeles.canonical.com> Message-ID: <157804013651.5706.7695477033799220940.launchpad@gac.canonical.com> ** Changed in: keystoneauth Status: New => Invalid ** Information type changed from Public to Private Security ** Information type changed from Private Security to Private -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1858186 Title: http_log_request will print debug info include pki certificate which is unsafety Status in keystoneauth: Invalid Bug description: when i use pki token,i find nova debug log include the whole pki certificate info,is this safety?need to modify? my request is curl -g -i -X GET https://identity.az1.dc1.domainname.com:443/identity-admin/v3/auth/tokens/OS-PKI/revoked debug.log such as: RESP BODY: {"signed": "-----BEGIN CMS-----\nMIIBuwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfs0QO\n-----END CMS-----\n"} code session.py: if response is not None: if not status_code: status_code = response.status_code if not headers: headers = response.headers if not text: # NOTE(samueldmq): If the response does not provide enough info # about the content type to decide whether it is useful and # safe to log it or not, just do not log the body. Trying to # read the response body anyways may result on reading a long # stream of bytes and getting an unexpected MemoryError. See # bug 1616105 for further details. content_type = response.headers.get('content-type', None) # NOTE(lamt): Per [1], the Content-Type header can be of the # form Content-Type := type "/" subtype *[";" parameter] # [1] https://www.w3.org/Protocols/rfc1341/4_Content-Type.html for log_type in _LOG_CONTENT_TYPES: if content_type is not None and content_type.startswith( log_type): text = self._remove_service_catalog(response.text) break else: text = ('Omitted, Content-Type is set to %s. Only ' '%s responses have their bodies logged.') text = text % (content_type, ', '.join(_LOG_CONTENT_TYPES)) if json: text = self._json.encode(json) string_parts = ['RESP:'] if status_code: string_parts.append('[%s]' % status_code) if headers: for header in six.iteritems(headers): string_parts.append('%s: %s' % self._process_header(header)) if text: string_parts.append('\nRESP BODY: %s\n' % text) To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1858186/+subscriptions From bcafarel at redhat.com Tue Jan 14 11:34:01 2020 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Tue, 14 Jan 2020 11:34:01 -0000 Subject: [Openstack-security] [Bug 1734320] Re: Eavesdropping private traffic References: <151152217834.14483.1577991310209811902.malonedeb@soybean.canonical.com> Message-ID: <157900164251.5202.5570205390311741798.launchpad@gac.canonical.com> ** Tags removed: neutron-proactive-backport-potential -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1734320 Title: Eavesdropping private traffic Status in neutron: Fix Committed Status in OpenStack Compute (nova): In Progress Status in os-vif: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Eavesdropping private traffic ============================= Abstract -------- We've discovered a security issue that allows end users within their own private network to receive from, and send traffic to, other private networks on the same compute node. Description ----------- During live-migration there is a small time window where the ports of instances are untagged. Instances have a port trunked to the integration bridge and receive 802.1Q tagged private traffic from other tenants. If the port is administratively down during live migration, the port will remain in trunk mode indefinitely. Traffic is possible between ports is that are administratively down, even between tenants self-service networks. Conditions ---------- The following conditions are necessary. * Openvswitch Self-service networks * An Openstack administrator or an automated process needs to schedule a Live migration We tested this on newton. Issues ------ This outcome is the result of multiple independent issues. We will list the most important first, and follow with bugs that create a fragile situation. Issue #1 Initially creating a trunk port When the port is initially created, it is in trunk mode. This creates a fail-open situation. See: https://github.com/openstack/os-vif/blob/newton-eol/vif_plug_ovs/linux_net.py#L52 Recommendation: create ports in the port_dead state, don't leave it dangling in trunk-mode. Add a drop-flow initially. Issue #2 Order of creation. The instance is actually migrated before the (networking) configuration is completed. Recommendation: wait with finishing the live migration until the underlying configuration has been applied completely. Issue #3 Not closing the port when it is down. Neutron calls the port_dead function to ensure the port is down. It sets the tag to 4095 and adds a "drop" flow if (and only if) there is already another tag on the port. The port_dead function will keep untagged ports untagged. https://github.com/openstack/neutron/blob/stable/newton/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L995 Recommendation: Make port_dead also shut the port if no tag is found. Log a warning if this happens. Issue #4 Putting the port administratively down actually puts the port on a compute node shared vlan Instances from different projects on different private networks can talk to each other if they put their ports down. The code does install an openflow "drop" rule but it has a lower priority (2) than the allow rules. Recommendation: Increase the port_dead openflow drop rule priority to MAX Timeline --------  2017-09-14 Discovery eavesdropping issue  2017-09-15 Verify workaround.  2017-10-04 Discovery port-down-traffic issue  2017-11-24 Vendor Disclosure to Openstack Steps to reproduce ------------------ 1. Attach an instance to two networks: admin$ openstack server create --nic net-id= --nic net-id = --image --flavor instance_temp 2. Attach a FIP to the instance to be able to log in to this instance 3. Verify: admin$ openstack server show -c name -c addresses fe28a2ee-098f-4425 -9d3c-8e2cd383547d +-----------+-----------------------------------------------------------------------------+ | Field | Value | +-----------+-----------------------------------------------------------------------------+ | addresses | network1=192.168.99.8, ; network2=192.168.80.14 | | name | instance_temp | +-----------+-----------------------------------------------------------------------------+ 4. Ssh to the instance using network1 and run a tcpdump on the other port network2 [root at instance_temp]$ tcpdump -eeenni eth1 5. Get port-id of network2 admin$ nova interface-list fe28a2ee-098f-4425-9d3c-8e2cd383547d +------------+--------------------------------------+--------------------------------------+---------------+-------------------+ | Port State | Port ID | Net ID | IP addresses | MAC Addr | +------------+--------------------------------------+--------------------------------------+---------------+-------------------+ | ACTIVE | a848520b-0814-4030-bb48-49e4b5cf8160 | d69028f7-9558-4f14-8ce6-29cb8f1c19cd | 192.168.80.14 | fa:16:3e:2d:8b:7b | | ACTIVE | fad148ca-cf7a-4839-aac3-a2cd8d1d2260 | d22c22ae-0a42-4e3b-8144-f28534c3439a | 192.168.99.8 | fa:16:3e:60:2c:fa | +------------+--------------------------------------+--------------------------------------+---------------+-------------------+ 6. Force port down on network 2 admin$ neutron port-update a848520b-0814-4030-bb48-49e4b5cf8160 --admin-state-up False 7. Port gets tagged with vlan 4095, the dead vlan tag, which is normal: compute1# grep a848520b-0814-4030-bb48-49e4b5cf8160 /var/log/neutron/neutron-openvswitch-agent.log | tail -1 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-e008feb3-8a35-4c97-adac-b48ff88165b2 - - - - -] VIF port: a848520b-0814-4030-bb48-49e4b5cf8160 admin state up disabled, putting on the dead VLAN 8. Verify the port is tagged with vlan 4095 compute1# ovs-vsctl show | grep -A3 qvoa848520b-08       Port "qvoa848520b-08"           tag: 4095           Interface "qvoa848520b-08" 9. Now live-migrate the instance: admin# nova live-migration fe28a2ee-098f-4425-9d3c-8e2cd383547d 10. Verify the tag is gone on compute2, and take a deep breath compute2# ovs-vsctl show | grep -A3 qvoa848520b-08       Port "qvoa848520b-08"           Interface "qvoa848520b-08"       Port... compute2# echo "Wut!" 11. Now traffic of all other self-service networks present on compute2 can be sniffed from instance_temp [root at instance_temp] tcpdump -eenni eth1 13:14:31.748266 fa:16:3e:6a:17:38 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 10.103.12.160 tell 10.103.12.152, length 28 13:14:31.804573 fa:16:3e:e8:a2:d2 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.70, length 28 13:14:31.810482 fa:16:3e:95:ca:3a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.154, length 28 13:14:31.977820 fa:16:3e:6f:f4:9b > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.150, length 28 13:14:31.979590 fa:16:3e:0f:3d:cc > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 9, p 0, ethertype ARP, Request who-has 10.103.9.163 tell 10.103.9.1, length 28 13:14:32.048082 fa:16:3e:65:64:38 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.101, length 28 13:14:32.127400 fa:16:3e:30:cb:b5 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 10.103.12.160 tell 10.103.12.165, length 28 13:14:32.141982 fa:16:3e:96:cd:b0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.100, length 28 13:14:32.205327 fa:16:3e:a2:0b:76 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.153, length 28 13:14:32.444142 fa:16:3e:1f:db:ed > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 58: vlan 72, p 0, ethertype IPv4, 192.168.99.212 > 224.0.0.18: VRRPv2, Advertisement, vrid 50, prio 103, authtype none, intvl 1s, length 20 13:14:32.449497 fa:16:3e:1c:24:c0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.20, length 28 13:14:32.476015 fa:16:3e:f2:3b:97 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.22, length 28 13:14:32.575034 fa:16:3e:44:fe:35 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 10.103.12.160 tell 10.103.12.163, length 28 13:14:32.676185 fa:16:3e:1e:92:d7 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 10.103.12.160 tell 10.103.12.150, length 28 13:14:32.711755 fa:16:3e:99:6c:c8 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 62: vlan 10, p 0, ethertype IPv4, 10.103.12.154 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 49, authtype simple, intvl 1s, length 24 13:14:32.711773 fa:16:3e:f5:23:d5 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 58: vlan 12, p 0, ethertype IPv4, 10.103.15.154 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 49, authtype simple, intvl 1s, length 20 Workaround ---------- We temporary fixed this issue by forcing the dead vlan tag on port creation on compute nodes: /usr/lib/python2.7/site-packages/vif_plug_ovs/linux_net.py: def _create_ovs_vif_cmd(bridge, dev, iface_id, mac,                         instance_id, interface_type=None,                         vhost_server_path=None): + # ODCN: initialize port as dead + # ODCN: TODO: set drop flow     cmd = ['--', '--if-exists', 'del-port', dev, '--',             'add-port', bridge, dev, + 'tag=4095',             '--', 'set', 'Interface', dev,             'external-ids:iface-id=%s' % iface_id,             'external-ids:iface-status=active',             'external-ids:attached-mac=%s' % mac,             'external-ids:vm-uuid=%s' % instance_id]     if interface_type:         cmd += ['type=%s' % interface_type]     if vhost_server_path:         cmd += ['options:vhost-server-path=%s' % vhost_server_path]     return cmd https://github.com/openstack/neutron/blob/stable/newton/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L995     def port_dead(self, port, log_errors=True):         '''Once a port has no binding, put it on the "dead vlan".         :param port: an ovs_lib.VifPort object.         '''         # Don't kill a port if it's already dead         cur_tag = self.int_br.db_get_val("Port", port.port_name, "tag",                                          log_errors=log_errors) + # ODCN GM 20170915 + if not cur_tag: + LOG.error('port_dead(): port %s has no tag', port.port_name) + # ODCN AJS 20170915 + if not cur_tag or cur_tag != constants.DEAD_VLAN_TAG: - if cur_tag and cur_tag != constants.DEAD_VLAN_TAG:            LOG.info('port_dead(): put port %s on dead vlan', port.port_name)            self.int_br.set_db_attribute("Port", port.port_name, "tag",                                          constants.DEAD_VLAN_TAG,                                          log_errors=log_errors)             self.int_br.drop_port(in_port=port.ofport) plugins/ml2/drivers/openvswitch/agent/openflow/ovs_ofctl/ovs_bridge.py     def drop_port(self, in_port): + # ODCN AJS 20171004: - self.install_drop(priority=2, in_port=in_port) + self.install_drop(priority=65535, in_port=in_port) Regards, ODC Noord. Gerhard Muntingh Albert Siersema Paul Peereboom To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1734320/+subscriptions From 1819957 at bugs.launchpad.net Tue Jan 28 08:54:48 2020 From: 1819957 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 28 Jan 2020 08:54:48 -0000 Subject: [Openstack-security] [Bug 1819957] Fix proposed to oslo.cache (stable/queens) References: <155250258380.27992.5839797432076968036.malonedeb@wampee.canonical.com> Message-ID: <158020168844.18494.15999653119899460050.malone@gac.canonical.com> Fix proposed to branch: stable/queens Review: https://review.opendev.org/704508 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1819957 Title: Caching with stale data when a server disconnects due to network partition and reconnects Status in OpenStack Identity (keystone): Invalid Status in keystonemiddleware: Triaged Status in oslo.cache: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: The flush_on_reconnect optional flag is not used. This can cause stale data to be utilized from a cache server that disconnected due to a network partition. This has security concerns as follows: 1* Password changes/user changes may be reverted for the cache TTL 1a* User may get locked out if PCI-DSS is on and the password change happens during the network partition. 2* Grant changes may be reverted for the cache TTL 3* Resources (all types) may become "undeleted" for the cache TTL 4* Tokens (KSM) may become valid again during the cache TTL As noted in the python-memcached library: @param flush_on_reconnect: optional flag which prevents a scenario that can cause stale data to be read: If there's more than one memcached server and the connection to one is interrupted, keys that mapped to that server will get reassigned to another. If the first server comes back, those keys will map to it again. If it still has its data, get()s can read stale data that was overwritten on another server. This flag is off by default for backwards compatibility. The solution is to explicitly pass flush_on_reconnect as an optional argument. A concern with this model is that the memcached servers may be utilized by other tooling and may lose cache state (in the case the oslo.cache connection is the only thing affected by the network partitioning). This similarly needs to be addressed in pymemcache when it is utilized in lieu of python-memcached. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1819957/+subscriptions From 1841933 at bugs.launchpad.net Tue Jan 28 09:34:50 2020 From: 1841933 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 28 Jan 2020 09:34:50 -0000 Subject: [Openstack-security] [Bug 1841933] Re: Fetching metadata via LB may result with wrong instance data References: <156708456800.5802.11171099222674714929.malonedeb@gac.canonical.com> Message-ID: <158020409258.4955.6261047661406213367.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: Adit Sarfaty (asarfaty) => Kobi Samoray (ksamoray) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1841933 Title: Fetching metadata via LB may result with wrong instance data Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: While querying metadata from an instance via a loadbalancer, metadata service relies on X-Metadata-Provider to identify the correct instance by querying Neutron for subnets which are attached to the loadbalancer. Then the subnet result is used to identify the instance by querying for ports which are attached to the subnets above. Yet, when the first query result is empty due to deletion, bug or any other reason within the Neutron side, this may cause a security vulnerability, as Neutron will retrieve ports of _any_ instance which has the same IP address as the instance which is queried. That could compromise key pairs and other sensitive data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1841933/+subscriptions From 1824248 at bugs.launchpad.net Thu Jan 30 06:10:45 2020 From: 1824248 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 30 Jan 2020 06:10:45 -0000 Subject: [Openstack-security] [Bug 1824248] Fix merged to neutron (stable/stein) References: <155493822208.21486.11348171578680982627.malonedeb@soybean.canonical.com> Message-ID: <158036464543.19107.12319472365754742593.malone@gac.canonical.com> Reviewed: https://review.opendev.org/688716 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=47890e9b85826951387fedb57ab474bd20ab1c3b Submitter: Zuul Branch: stable/stein commit 47890e9b85826951387fedb57ab474bd20ab1c3b Author: Slawek Kaplonski Date: Thu Sep 12 22:02:52 2019 +0200 List SG rules which belongs to tenant's SG In case when user's security group contains rules created e.g. by admin, and such rules has got admin's tenant as tenant_id, owner of security group should be able to see those rules. Some time ago this was addressed for request: GET /v2.0/security-groups/ But it is also required to behave in same way for GET /v2.0/security-group-rules So this patch fixes this behaviour for listing of security group rules. To achieve that this patch also adds new policy rule: ADMIN_OWNER_OR_SG_OWNER which is similar to already existing ADMIN_OWNER_OR_NETWORK_OWNER used e.g. for listing or creating ports. Change-Id: I09114712582d2d38d14cf1683b87a8ce3a8e8c3c Closes-Bug: #1824248 (cherry picked from commit b898d2e3c08b50e576ee849fbe8614c66f360c62) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1824248 Title: Security Group filtering hides rules from user Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Manage Rules part of the GUI hides the rules currently visible in the Launch Instance modal window. It allows a malicious admin to add backdoor access rules that might be later added to VMs without the knowledge of owner of those VMs. When sending GET request as below, it responds only with the rules that are created by user and this happens when using Manage Rules part of the GUI: On the other hand when using GET request as below, it responds with all SG and it includes all rules, and there is no filtering and this is used in Launch Instance modal window: Here is example of rules display in Manage Rules part of GUI: > /opt/stack/horizon/openstack_dashboard/dashboards/project/security_groups/views.py(50)_get_data() -> return api.neutron.security_group_get(self.request, sg_id) (Pdb) l  45 @memoized.memoized_method  46 def _get_data(self):  47 sg_id = filters.get_int_or_uuid(self.kwargs['security_group_id'])  48 try:  49 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  50 -> return api.neutron.security_group_get(self.request, sg_id)  51 except Exception:  52 redirect = reverse('horizon:project:security_groups:index')  53 exceptions.handle(self.request,  54 _('Unable to retrieve security group.'),  55 redirect=redirect) (Pdb) p api.neutron.security_group_get(self.request, sg_id) , , , ]}> (Pdb) (Pdb) p self.request As you might have noticed there are no ports access 44 and 22 (SSH) And from the Launch Instance Modal Window, as well as CLI we can see that there are two more rules that are invisible for user, port 44 and 22 (SSH) as displayed below: > /opt/stack/horizon/openstack_dashboard/api/rest/network.py(47)get() -> return {'items': [sg.to_dict() for sg in security_groups]} (Pdb) l  42 """  43  44 security_groups = api.neutron.security_group_list(request)  45 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()  46  47 -> return {'items': [sg.to_dict() for sg in security_groups]}  48  49  50 @urls.register  51 class FloatingIP(generic.View):  52 """API for a single floating IP address.""" (Pdb) p security_groups [, , , , , ]}>] (Pdb) (Pdb) p request Thank you, Robin To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1824248/+subscriptions