From fungi at yuggoth.org Tue Oct 3 16:22:31 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 03 Oct 2017 16:22:31 -0000 Subject: [Openstack-security] [Bug 1721063] Re: vulnerability in dnsmasq References: <150704464547.12531.4795484814443703556.malonedeb@wampee.canonical.com> Message-ID: <150704775167.28310.15654010941389230131.malone@gac.canonical.com> Triaged as vulnerability report class C2 "A vulnerability, but not in OpenStack supported code, e.g., in a dependency" https://security.openstack.org/vmt-process.html#incident-report-taxonomy . As such there will be no advisory, but work is underway already for a security note about this: https://review.openstack.org/509160 ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Won't Fix ** Information type changed from Public Security to Public ** Tags added: security ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossn Status: New => In Progress ** Changed in: ossn Assignee: (unassigned) => Luke Hinds (lhinds) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1721063 Title: vulnerability in dnsmasq Status in neutron: Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: As per [1],[2] , there have been some vulnerability issue in dnsmasq. The same have been fixed in dnsmasq version 2.78 In order to avoid the vulnerabilities, it would be advisable to update dnsmasq to version 2.78 [1]: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html [2]: https://thehackernews.com/2017/10/dnsmasq-network-services.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheHackersNews+%28The+Hackers+News+-+Security+Blog%29&_m=3n.009a.1592.dj0ao06ba4.yhy To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1721063/+subscriptions From gerrit2 at review.openstack.org Tue Oct 3 19:00:04 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Oct 2017 19:00:04 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change openstack%2Fcursive~master~I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit 717bc17f1c02c37f987cd61cd931d7e4093ed239 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 oAdd certificate validation This change adds support for certificate validation, including certificate inspection utilities. Validating a certificate requires the certificate UUID of the certificate to validate, a set of UUIDs corresponding to the set of trusted certificates needed to validate the certificate, and a user context for authentication to the key manager. A new certificate verification context is included that is used to store the set of trusted certificates once they are loaded from the key manager. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the set of trusted certificates. All new certificate utility code is added in a new module named certificate_utils. For more information on this work, see the spec: https://review.openstack.org/#/c/488541/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Implements: blueprint nova-validate-certificates From gerrit2 at review.openstack.org Tue Oct 3 19:58:41 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Oct 2017 19:58:41 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change openstack%2Fcursive~master~I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit ad879a1fbccfa31fdedd69e3193e9bf12a15f943 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for certificate validation, including certificate inspection utilities. Validating a certificate requires the certificate UUID of the certificate to validate, a set of UUIDs corresponding to the set of trusted certificates needed to validate the certificate, and a user context for authentication to the key manager. A new certificate verification context is included that is used to store the set of trusted certificates once they are loaded from the key manager. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the set of trusted certificates. All new certificate utility code is added in a new module named certificate_utils. For more information on this work, see the spec: https://review.openstack.org/#/c/488541/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Implements: blueprint nova-validate-certificates From 1664723 at bugs.launchpad.net Thu Oct 5 19:51:33 2017 From: 1664723 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Oct 2017 19:51:33 -0000 Subject: [Openstack-security] [Bug 1664723] Change abandoned on trove (master) References: <20170214213337.4535.90559.malonedeb@chaenomeles.canonical.com> Message-ID: <150723309383.7850.11547479453516103826.malone@wampee.canonical.com> Change abandoned by Trevor McCasland (TM2086 at att.com) on branch: master Review: https://review.openstack.org/454205 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1664723 Title: replication_slave user and passwords exposed in logging Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): In Progress Bug description: Currently the passwords and usernames for trove's replciation_user in pxc and percona configuration options are exposed in the logger. Mysql already has secret=True for their configuration options. This patch extends that to all of the other database configuration options using oslo.config.cfg.Opt option secret [1]. See output below for exact logs: tr-api.log.2017-02-14-095217:2017-02-14 10:21:58.628 DEBUG oslo_service.service [-] percona.replication_password = NETOU7897NNLOU from (pid=684) log_opt_values /usr/local/lib/python2.7 /dist-packages/oslo_config/cfg.py:2744 tr-api.log.2017-02-14-095217:2017-02-14 10:21:58.628 DEBUG oslo_service.service [-] percona.replication_user = slave_user from (pid=684) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py:2744 tr-api.log.2017-02-14-095217:2017-02-14 10:21:58.636 DEBUG oslo_service.service [-] pxc.replication_user = slave_user from (pid=684) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py:2744 References [1] http://docs.openstack.org/developer/oslo.config/cfg.html To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1664723/+subscriptions From 1686110 at bugs.launchpad.net Thu Oct 5 20:43:57 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Oct 2017 20:43:57 -0000 Subject: [Openstack-security] [Bug 1686110] Fix included in openstack/ansible-hardening 15.1.9 References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <150723623708.22043.15048838913566980982.malone@gac.canonical.com> This issue was fixed in the openstack/ansible-hardening 15.1.9 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions From gerrit2 at review.openstack.org Wed Oct 11 18:16:18 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Oct 2017 18:16:18 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change openstack%2Fnova-specs~master~I121b2e7641c77a4872a1e801eb039050e6a996ea Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/488541 Log: commit ffdbd9d0709b81379faff7e5399f22176b26141d Author: Peter Hamilton Date: Fri Jul 28 13:18:30 2017 -0400 Add support for certificate validation This spec describes changes that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of Nova API changes allows Nova users to control the certificates which are allowed to sign images. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 APIImpact DocImpact SecurityImpact Previously-approved: Pike Change-Id: I121b2e7641c77a4872a1e801eb039050e6a996ea From lhinds at redhat.com Thu Oct 12 16:50:48 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 12 Oct 2017 16:50:48 -0000 Subject: [Openstack-security] [Bug 1721063] Re: vulnerability in dnsmasq References: <150704464547.12531.4795484814443703556.malonedeb@wampee.canonical.com> Message-ID: <150782705114.21565.6738271588731962770.launchpad@gac.canonical.com> ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1721063 Title: vulnerability in dnsmasq Status in neutron: Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: As per [1],[2] , there have been some vulnerability issue in dnsmasq. The same have been fixed in dnsmasq version 2.78 In order to avoid the vulnerabilities, it would be advisable to update dnsmasq to version 2.78 [1]: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html [2]: https://thehackernews.com/2017/10/dnsmasq-network-services.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheHackersNews+%28The+Hackers+News+-+Security+Blog%29&_m=3n.009a.1592.dj0ao06ba4.yhy To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1721063/+subscriptions From 1611171 at bugs.launchpad.net Thu Oct 19 18:23:13 2017 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 19 Oct 2017 18:23:13 -0000 Subject: [Openstack-security] [Bug 1611171] Change abandoned on designate (master) References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <150843739398.17445.10646530651084580760.malone@gac.canonical.com> Change abandoned by Kiall Mac Innes (kiall at macinnes.ie) on branch: master Review: https://review.openstack.org/352843 Reason: Feel free to resurrect if needs be! -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1611171 at bugs.launchpad.net Fri Oct 20 08:41:06 2017 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 Oct 2017 08:41:06 -0000 Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <150848886642.13320.15137690094648537482.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/513665 ** Changed in: designate Assignee: Kiall Mac Innes (kiall) => Dr. Jens Harbott (j-harbott) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1611171 at bugs.launchpad.net Fri Oct 20 11:21:38 2017 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 Oct 2017 11:21:38 -0000 Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <150849850033.1041.80307620539760041.launchpad@soybean.canonical.com> ** Changed in: manila Assignee: iswarya vakati (v-iswarya) => Tom Barron (tpb) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1605914 at bugs.launchpad.net Mon Oct 23 09:18:23 2017 From: 1605914 at bugs.launchpad.net (Fan Zhang) Date: Mon, 23 Oct 2017 09:18:23 -0000 Subject: [Openstack-security] [Bug 1605914] Re: Hard coded security group References: <20160723182211.8674.89923.malonedeb@soybean.canonical.com> Message-ID: <150875030490.17167.9041864588926457055.launchpad@gac.canonical.com> ** Changed in: trove Assignee: (unassigned) => Fan Zhang (fanzhang) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1605914 Title: Hard coded security group Status in OpenStack DBaaS (Trove): Confirmed Bug description: "trove create" also creates a security group, with hard coded values. Some of which is not what I want/need - especially the 'allow everything' rule! Please allow to specify existing SG(s) (preferably plural) on either the command line (preferably), or in the datastore/datastore_version configuration. Or possibly in the datastore section in trove*.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/trove/+bug/1605914/+subscriptions From 1605914 at bugs.launchpad.net Mon Oct 23 09:47:47 2017 From: 1605914 at bugs.launchpad.net (Fan Zhang) Date: Mon, 23 Oct 2017 09:47:47 -0000 Subject: [Openstack-security] [Bug 1605914] Re: Hard coded security group References: <20160723182211.8674.89923.malonedeb@soybean.canonical.com> Message-ID: <150875206824.17640.468442913188036913.launchpad@gac.canonical.com> ** Changed in: trove Assignee: Fan Zhang (fanzhang) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1605914 Title: Hard coded security group Status in OpenStack DBaaS (Trove): Confirmed Bug description: "trove create" also creates a security group, with hard coded values. Some of which is not what I want/need - especially the 'allow everything' rule! Please allow to specify existing SG(s) (preferably plural) on either the command line (preferably), or in the datastore/datastore_version configuration. Or possibly in the datastore section in trove*.conf. To manage notifications about this bug go to: https://bugs.launchpad.net/trove/+bug/1605914/+subscriptions From 1713783 at bugs.launchpad.net Tue Oct 24 12:42:40 2017 From: 1713783 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 Oct 2017 12:42:40 -0000 Subject: [Openstack-security] [Bug 1713783] Fix included in openstack/nova 17.0.0.0b1 References: <150402703560.19393.11649471063519714290.malonedeb@chaenomeles.canonical.com> Message-ID: <150884896053.16956.5938806393324749662.malone@gac.canonical.com> This issue was fixed in the openstack/nova 17.0.0.0b1 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1713783 Title: After failed evacuation the recovered source compute tries to delete the instance Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Triaged Status in OpenStack Compute (nova) ocata series: Triaged Status in OpenStack Compute (nova) pike series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: Description =========== In case of a failed evacuation attempt the status of the migration is 'accepted' instead of 'failed' so when source compute is recovered the compute manager tries to delete the instance from the source host. However a secondary fault prevents deleting the allocation in placement so the actual deletion of the instance fails as well. Steps to reproduce ================== The following functional test reproduces the bug: https://review.openstack.org/#/c/498482/ What it does: initiate evacuation when no valid host is available and evacuation fails, but nova manager still tries to delete the instance. Logs:     2017-08-29 19:11:15,751 ERROR [oslo_messaging.rpc.server] Exception during message handling     NoValidHost: No valid host was found. There are not enough hosts available.     2017-08-29 19:11:16,103 INFO [nova.tests.functional.test_servers] Running periodic for compute1 (host1)     2017-08-29 19:11:16,115 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,120 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,131 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/allocations" status: 200 len: 152 microversion: 1.0     2017-08-29 19:11:16,138 INFO [nova.compute.resource_tracker] Final resource view: name=host1 phys_ram=8192MB used_ram=1024MB phys_disk=1028GB used_disk=1GB total_vcpus=10 used_vcpus=1 pci_stats=[]     2017-08-29 19:11:16,146 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,151 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,152 INFO [nova.tests.functional.test_servers] Running periodic for compute2 (host2)     2017-08-29 19:11:16,163 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,168 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,176 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/allocations" status: 200 len: 54 microversion: 1.0     2017-08-29 19:11:16,184 INFO [nova.compute.resource_tracker] Final resource view: name=host2 phys_ram=8192MB used_ram=512MB phys_disk=1028GB used_disk=0GB total_vcpus=10 used_vcpus=0 pci_stats=[]     2017-08-29 19:11:16,192 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,197 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,198 INFO [nova.tests.functional.test_servers] Finished with periodics     2017-08-29 19:11:16,255 INFO [nova.api.openstack.requestlog] 127.0.0.1 "GET /v2.1/6f70656e737461636b20342065766572/servers/5058200c-478e-4449-88c1-906fdd572662" status: 200 len: 1875 microversion: 2.53 time: 0.056198     2017-08-29 19:11:16,262 INFO [nova.api.openstack.requestlog] 127.0.0.1 "GET /v2.1/6f70656e737461636b20342065766572/os-migrations" status: 200 len: 373 microversion: 2.53 time: 0.004618     2017-08-29 19:11:16,280 INFO [nova.api.openstack.requestlog] 127.0.0.1 "PUT /v2.1/6f70656e737461636b20342065766572/os-services/c269bc74-4720-4de4-a6e5-889080b892a0" status: 200 len: 245 microversion: 2.53 time: 0.016442     2017-08-29 19:11:16,281 INFO [nova.service] Starting compute node (version 16.0.0)     2017-08-29 19:11:16,296 INFO [nova.compute.manager] Deleting instance as it has been evacuated from this host To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1713783/+subscriptions From 1464750 at bugs.launchpad.net Tue Oct 24 17:49:06 2017 From: 1464750 at bugs.launchpad.net (Akihiro Motoki) Date: Tue, 24 Oct 2017 17:49:06 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <150886734629.17385.1643345832120317870.malone@gac.canonical.com> As Horizon, we can potentially check a role of log-in user. service users like nova and neutron usually belong to a specific role. ** Changed in: horizon Status: Incomplete => Opinion -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Opinion 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 not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From 1417762 at bugs.launchpad.net Tue Oct 24 21:11:28 2017 From: 1417762 at bugs.launchpad.net (Akihiro Motoki) Date: Tue, 24 Oct 2017 21:11:28 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <150887948816.27829.12867238884282105929.malone@soybean.canonical.com> The example in the bug description is just an example. In my understanding, the point is if you specify an invalid choice which contains JS code for a choice field the specified value is returned as part of an error message. I am not sure how it has a potential risk of XSS. The case here is if an API user sends a crafted string he receives the crafted string. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From 1417762 at bugs.launchpad.net Tue Oct 24 21:14:15 2017 From: 1417762 at bugs.launchpad.net (Akihiro Motoki) Date: Tue, 24 Oct 2017 21:14:15 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <150887965583.27939.14328728023512682621.malone@soybean.canonical.com> The same thing was discussed above (around comment 5). The message is generated by Django (not by horizon), so this bug should be forwarded to Django (if it still exists in the latest version of Django like 1.11). -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From 1464750 at bugs.launchpad.net Wed Oct 25 19:53:44 2017 From: 1464750 at bugs.launchpad.net (Adam Young) Date: Wed, 25 Oct 2017 19:53:44 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <150896122426.18067.11055759756753753933.malone@chaenomeles.canonical.com> Would probably make sense to have a WebUser role that Member inherits. If a user has WebUser, they can log in to the ui, if they don't they can't. Horizon should not look for the absence of a role as a way to control UI. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Opinion 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 not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From 1702571 at bugs.launchpad.net Thu Oct 26 19:50:17 2017 From: 1702571 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 26 Oct 2017 19:50:17 -0000 Subject: [Openstack-security] [Bug 1702571] Fix included in openstack/ansible-hardening 17.0.0.0b1 References: <149928884089.15922.6070230979479956825.malonedeb@wampee.canonical.com> Message-ID: <150904741806.8561.10812513043841437457.malone@wampee.canonical.com> This issue was fixed in the openstack/ansible-hardening 17.0.0.0b1 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702571 Title: ansible-hardening docs are vague about using as standalone Status in openstack-ansible: Fix Released Bug description: The ansible-hardening docs are a bit vague about how to handle standalone deployments. Questions to answer: 1) How/where to provide variables? 2) What about roles in non standard locations? /home/myuser/ansible-hardening? 3) How do you install via ansible-galaxy from git? 4) What do you need to install first before running the role? 5) What would an inventory file look like? To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702571/+subscriptions From 1693343 at bugs.launchpad.net Thu Oct 26 19:50:25 2017 From: 1693343 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 26 Oct 2017 19:50:25 -0000 Subject: [Openstack-security] [Bug 1693343] Fix included in openstack/ansible-hardening 17.0.0.0b1 References: <149565524123.24782.9127842748680337701.malonedeb@soybean.canonical.com> Message-ID: <150904742604.3741.11873992683150782767.malone@gac.canonical.com> This issue was fixed in the openstack/ansible-hardening 17.0.0.0b1 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1693343 Title: V-71945 fails on CentOS 7 Status in openstack-ansible: Fix Released Bug description: 2017-05-24 17:35:21.290912 | TASK [openstack-ansible-security : V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked.] *** 2017-05-24 17:35:21.312253 | Wednesday 24 May 2017 17:35:21 +0000 (0:00:00.320) 0:00:19.083 ********* 2017-05-24 17:35:21.468598 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Path pam_password_file does not exist !", "rc": 257} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1693343/+subscriptions From 1686110 at bugs.launchpad.net Thu Oct 26 19:50:28 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 26 Oct 2017 19:50:28 -0000 Subject: [Openstack-security] [Bug 1686110] Fix included in openstack/ansible-hardening 17.0.0.0b1 References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <150904742904.4453.12586870909755949430.malone@gac.canonical.com> This issue was fixed in the openstack/ansible-hardening 17.0.0.0b1 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions