From 1737207 at bugs.launchpad.net Wed May 2 12:01:40 2018 From: 1737207 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 02 May 2018 12:01:40 -0000 Subject: [Openstack-security] [Bug 1737207] Fix included in openstack/nova 15.1.1 References: <151275282506.3764.13107222303228891439.malonedeb@gac.canonical.com> Message-ID: <152526250076.15108.6513570949810940351.malone@wampee.canonical.com> This issue was fixed in the openstack/nova 15.1.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1737207 Title: Guest admin password and network information is logged at debug if libvirt.inject_partition != -2 Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: Fix Committed Status in OpenStack Compute (nova) pike series: Fix Committed Status in OpenStack Compute (nova) queens series: Fix Committed Bug description: When using the libvirt driver and the inject_partition config option is != -2 (disabled), the driver will log the network information and admin password about the guest during disk injection: http://logs.openstack.org/50/524750/1/check/legacy-tempest-dsvm- neutron-full- centos-7/a7f051e/logs/screen-n-cpu.txt.gz#_Dec_04_13_42_41_311316 Dec 04 13:42:41.311316 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Checking root disk injection InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3115}} Dec 04 13:42:41.314687 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Injecting InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3146}} This was introduced in Ocata (15.0.0): https://review.openstack.org/#/c/337790/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1737207/+subscriptions From 1713783 at bugs.launchpad.net Wed May 2 12:00:53 2018 From: 1713783 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 02 May 2018 12:00:53 -0000 Subject: [Openstack-security] [Bug 1713783] Fix included in openstack/nova 15.1.1 References: <150402703560.19393.11649471063519714290.malonedeb@chaenomeles.canonical.com> Message-ID: <152526245331.2091.12628966953947949087.malone@gac.canonical.com> This issue was fixed in the openstack/nova 15.1.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, 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) ocata series: Fix Committed 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 1757300 at bugs.launchpad.net Tue May 8 04:25:36 2018 From: 1757300 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 May 2018 04:25:36 -0000 Subject: [Openstack-security] [Bug 1757300] Fix included in openstack/heat 10.0.1 References: <152159262637.18509.15861333391173783708.malonedeb@chaenomeles.canonical.com> Message-ID: <152575353655.15607.5597911624993051518.malone@wampee.canonical.com> This issue was fixed in the openstack/heat 10.0.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1757300 Title: RandomString may have less entropy than expected Status in OpenStack Heat(please use StoryBoard instead!!!https://storyboard.openstack.org/#!/project/989 )(All your existing bugs are in SB now)(see https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info ): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: When generating a random string, once we have selected from the various required pools, we continue by selecting a pool at random and then selecting a character from that pool at random. This does not take into account the differing sizes of the available pools, nor the fact that the same character could appear in multiple pools. This results in a non-uniform probability distribution of characters. For example, in the following resource: type: OS::Heat::RandomString properties: length: 66 character_classes: - class: lettersdigits character_sequences: - sequence: "*$" one might reasonably expect to find an average of 3 '*' or '$' characters in the output, but in fact there would be an average of 33. Since users mostly make use of this feature to generate default passwords for services they are deploying, this would result in the generated passwords having slightly less entropy than expected. Pathological cases where the entropy is massively reduced (like the one above - where it is only 229.5 bits vs. the expected 391 bits) are possible, although it's probably unlikely that users would encounter them by accident. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1757300/+subscriptions From 1744609 at bugs.launchpad.net Tue May 8 13:17:05 2018 From: 1744609 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 May 2018 13:17:05 -0000 Subject: [Openstack-security] [Bug 1744609] Fix included in openstack/horizon 12.0.3 References: <151657896392.10939.14763313588978932571.malonedeb@soybean.canonical.com> Message-ID: <152578542542.15651.12384338000093865397.malone@wampee.canonical.com> This issue was fixed in the openstack/horizon 12.0.3 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1744609 Title: operation log: user passwords are logged by default setting Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: If the operation log is enabled (disabled by default) and the default value of OPERATION_LOG_OPTIONS['mask_fields'] is used, when a user tries to change his/her password from "Change Password" panel (http:///settings/password/), both current and new passwords will be logged in the operation log like below. The same thing happens in "Change Password" action in the Identity User panel. ---- [None] [None] [demo] [d65075f0e4964b8d9ccb57ddcce8fbbb] [admin] [c90eec6eb48d4bcc988e8cebf9ce80fa] [http] [/settings/password/] [/settings/password/] [error: Unauthorized: Unable to change password., error: Unauthorized. Please try logging in again.] [POST] [403] [{"fake_email": "", "fake_password": "", "new_password": "NEW-PASSWORD", "confirm_password": "NEW-PASSWORD", "current_password": "CURRENT-PASSWORD", "csrfmiddlewaretoken": "SEuuWLJlUPNUZzC6aCQkIQxyFuQPCjcahqnuZ8CYthDd4GNr76UC5EQYTAZzbdeo"}] ---- The default value of OPERATION_LOG_OPTIONS['mask_fields'] should include "current_password", "new_password" and "confirm_password". Operators who enable the operation log feature are recommended to set OPERATION_LOG_OPTIONS['mask_fields'] to ['password', 'current_password', 'new_password', 'confirm_password'] in local_settings.py. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1744609/+subscriptions From 1703369 at bugs.launchpad.net Tue May 8 13:16:45 2018 From: 1703369 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 May 2018 13:16:45 -0000 Subject: [Openstack-security] [Bug 1703369] Fix included in openstack/horizon 13.0.1 References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com> Message-ID: <152578540595.21509.1320835019827707933.malone@soybean.canonical.com> This issue was fixed in the openstack/horizon 13.0.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) newton series: Fix Committed Status in OpenStack Identity (keystone) ocata series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider and the code is setup to check for identity:get_identity_provider (singular). See https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112 found in master (pike) The ocata default policy.json also has this problem. Unless someone manually overrode policy to specify identity:get_identity_provider (singular), the result would be that the default rule was actually used for that check instead of identity:get_identity_providers. We could go back and fix the default policy.json for past releases, but the default actually has the same value as identity:get_identity_providers, and if nobody has complained it's probably safer to just leave it. It is, after all, just defaults there and anyone can override by specifying the correct value. But we must fix in pike to go along with the shift of policy into code. Policy defaults in code definitely need to match up with what the code actually checks. There should no longer be any reliance on the default rule. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703369/+subscriptions From 1765734 at bugs.launchpad.net Sat May 12 12:46:36 2018 From: 1765734 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 12 May 2018 12:46:36 -0000 Subject: [Openstack-security] [Bug 1765734] Re: one can bypass filters and execute arbitrary commands on namespaces References: <152423487153.12104.2470817010626300498.malonedeb@gac.canonical.com> Message-ID: <152612919705.24730.2305153033000799181.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/564555 Committed: https://git.openstack.org/cgit/openstack/oslo.rootwrap/commit/?id=ed125c0c1cd6168cbf529c94ef81173dedce2726 Submitter: Zuul Branch: master commit ed125c0c1cd6168cbf529c94ef81173dedce2726 Author: Daniel Alvarez Date: Thu Apr 26 18:33:21 2018 +0200 Make IpNetnsExecFilter more strict to detect aliases Currently, this filter only takes into account 'ip netns exec' as input but this command accepts different aliases like 'ip net e' or 'ip netn ex', etcetera. This is a security issue since bypassing this filter basically allows anyone to execute arbitary commands because IpFilter will get hit and there's not going to be any further checks against CommandFilters. Change-Id: I2f6e55de4e60f2d3a6166c2fefbc31e9afc6c26f Closes-Bug: 1765734 Co-Authored-By: Jakub Libosvar Signed-off-by: Daniel Alvarez ** Changed in: oslo.rootwrap Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1765734 Title: one can bypass filters and execute arbitrary commands on namespaces Status in oslo.rootwrap: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: When this filter [0] is enabled in conjunction with IpNetnsExecFilter, only commands allowed explicitly through the CommandFilter should get to execute in the specified namespace. However, due to the fact that these two commands are exactly the same: ip netns exec $namespace echo $my_ssh_key >> /root/.ssh/authorized_keys ip net exec $namespace echo $my_ssh_key >> /root/.ssh/authorized_keys One can execute the latter without any CommandFilter for the 'echo' command. This is a big security issue since anyone can make changes to the filesystem and execute arbitrary commands bypassing the IpNetnsExecFilter. The solution is simply patching this code [1] by checking that the second element starts with 'net', and the third one starts with 'e'. [0] ip: IpFilter, ip, root [1] https://github.com/openstack/oslo.rootwrap/blob/0fa59b04e89ad94085780550466368e6f351a9e1/oslo_rootwrap/filters.py#L376 To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.rootwrap/+bug/1765734/+subscriptions From 1765734 at bugs.launchpad.net Tue May 15 04:11:53 2018 From: 1765734 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 15 May 2018 04:11:53 -0000 Subject: [Openstack-security] [Bug 1765734] Fix included in openstack/oslo.rootwrap 5.14.1 References: <152423487153.12104.2470817010626300498.malonedeb@gac.canonical.com> Message-ID: <152635751331.25175.12084342019419806136.malone@soybean.canonical.com> This issue was fixed in the openstack/oslo.rootwrap 5.14.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1765734 Title: one can bypass filters and execute arbitrary commands on namespaces Status in oslo.rootwrap: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: When this filter [0] is enabled in conjunction with IpNetnsExecFilter, only commands allowed explicitly through the CommandFilter should get to execute in the specified namespace. However, due to the fact that these two commands are exactly the same: ip netns exec $namespace echo $my_ssh_key >> /root/.ssh/authorized_keys ip net exec $namespace echo $my_ssh_key >> /root/.ssh/authorized_keys One can execute the latter without any CommandFilter for the 'echo' command. This is a big security issue since anyone can make changes to the filesystem and execute arbitrary commands bypassing the IpNetnsExecFilter. The solution is simply patching this code [1] by checking that the second element starts with 'net', and the third one starts with 'e'. [0] ip: IpFilter, ip, root [1] https://github.com/openstack/oslo.rootwrap/blob/0fa59b04e89ad94085780550466368e6f351a9e1/oslo_rootwrap/filters.py#L376 To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.rootwrap/+bug/1765734/+subscriptions From 1757300 at bugs.launchpad.net Fri May 18 02:03:03 2018 From: 1757300 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 18 May 2018 02:03:03 -0000 Subject: [Openstack-security] [Bug 1757300] Re: RandomString may have less entropy than expected References: <152159262637.18509.15861333391173783708.malonedeb@chaenomeles.canonical.com> Message-ID: <152660898377.16193.15842628596632931907.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/559188 Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=8ce005cc0e309938f9d0fbdae65c92a406348936 Submitter: Zuul Branch: stable/ocata commit 8ce005cc0e309938f9d0fbdae65c92a406348936 Author: Zane Bitter Date: Tue Mar 20 20:48:38 2018 -0400 Fix entropy problems with OS::Random::String When generating a random string, once we had selected from the various required pools, we continued by selecting a pool at random and then selecting a character from that pool at random. This did not take into account the differing sizes of the available pools, nor the fact that the same character could appear in multiple pools, which resulted in a non-uniform probability distribution of characters. Since users mostly make use of this feature to generate default passwords for services they are deploying, this would result in the generated passwords having slightly less entropy than expected (and pathological cases were possible). Rectify this by always selecting non-constrained characters from a single combined pool, and by ensuring that each character appears only once in any pool we're selecting from. Since we also want to use this method to generate passwords for OpenStack Users, the new implementation is in a separate module in heat.common rather than mixed in with the resource's logic. Also, use a StringIO object to collect the characters rather than repeatedly appending to a string. Change-Id: Ia7b63e72c1e3c0649290caf4fea8a32f7f89560b Closes-Bug: #1757300 Related-Bug: #1666129 Related-Bug: #1444429 (cherry picked from commit 6e16c051ba9c2fc409c82fda19467d9ee1aaf484) ** Tags added: in-stable-ocata -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1757300 Title: RandomString may have less entropy than expected Status in OpenStack Heat: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: When generating a random string, once we have selected from the various required pools, we continue by selecting a pool at random and then selecting a character from that pool at random. This does not take into account the differing sizes of the available pools, nor the fact that the same character could appear in multiple pools. This results in a non-uniform probability distribution of characters. For example, in the following resource: type: OS::Heat::RandomString properties: length: 66 character_classes: - class: lettersdigits character_sequences: - sequence: "*$" one might reasonably expect to find an average of 3 '*' or '$' characters in the output, but in fact there would be an average of 33. Since users mostly make use of this feature to generate default passwords for services they are deploying, this would result in the generated passwords having slightly less entropy than expected. Pathological cases where the entropy is massively reduced (like the one above - where it is only 229.5 bits vs. the expected 391 bits) are possible, although it's probably unlikely that users would encounter them by accident. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1757300/+subscriptions From 1761054 at bugs.launchpad.net Thu May 31 18:24:31 2018 From: 1761054 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 31 May 2018 18:24:31 -0000 Subject: [Openstack-security] [Bug 1761054] Re: nova log expose password when swapvolume References: <152281951978.29145.13868060795008433631.malonedeb@chaenomeles.canonical.com> Message-ID: <152779107206.4482.11819674874960808741.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/561850 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=978066fe31a5331f143a05e1fd753c729b2dcf09 Submitter: Zuul Branch: stable/pike commit 978066fe31a5331f143a05e1fd753c729b2dcf09 Author: jichenjc Date: Wed Apr 4 13:26:01 2018 +0800 Avoid showing password in log per bug indicated, the password is shown in the log. https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L295 indicated auth_password can be masked through mask_password method. Conflicts: nova/compute/manager.py NOTE(lyarwood): Conflicts caused by Ica323b87fa85a454fca9d46ada3677f18fe50022 and Ifc01dbf98545104c998ab96f65ff8623a6db0f28 not being present in Pike. Additionally If12e7860baad2899380f06144a0270784a5466b8 was not present in Queens but landed in Pike and Ocata as a stable only change. Change-Id: I725eea1866642b40cc6b065ed0e8aefb91ca2889 Closes-Bug: 1761054 (cherry picked from commit 1b61d6c08c7c86834acab45320230824b88d529c) (cherry picked from commit df90dfd5cdf76c65b8d8a539d79e384c82c8428c) ** Tags added: in-stable-pike -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1761054 Title: nova log expose password when swapvolume Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: http://logs.openstack.org/50/557150/6/check/tempest- full/1f9c9f2/controller/logs/screen-n-cpu.txt.gz#_Mar_30_08_37_13_371323 u'auth_password': u'8KigD3KKykJkJixs', u'auth_username': u'6m4wAHCZVqFfTQaF4eZu', To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1761054/+subscriptions From 1761054 at bugs.launchpad.net Thu May 31 23:11:08 2018 From: 1761054 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 31 May 2018 23:11:08 -0000 Subject: [Openstack-security] [Bug 1761054] Re: nova log expose password when swapvolume References: <152281951978.29145.13868060795008433631.malonedeb@chaenomeles.canonical.com> Message-ID: <152780826847.4557.17726987772938329749.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/561851 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c17516f3999447ad0d4ec7ecd8f223f6468b693a Submitter: Zuul Branch: stable/ocata commit c17516f3999447ad0d4ec7ecd8f223f6468b693a Author: jichenjc Date: Wed Apr 4 13:26:01 2018 +0800 Avoid showing password in log per bug indicated, the password is shown in the log. https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L295 indicated auth_password can be masked through mask_password method. Conflicts: nova/compute/manager.py NOTE(lyarwood): Conflicts caused by Ica323b87fa85a454fca9d46ada3677f18fe50022 and Ifc01dbf98545104c998ab96f65ff8623a6db0f28 not being present in Pike. Additionally If12e7860baad2899380f06144a0270784a5466b8 was not present in Queens but landed in Pike and Ocata as a stable only change. Change-Id: I725eea1866642b40cc6b065ed0e8aefb91ca2889 Closes-Bug: 1761054 (cherry picked from commit 1b61d6c08c7c86834acab45320230824b88d529c) (cherry picked from commit df90dfd5cdf76c65b8d8a539d79e384c82c8428c) (cherry picked from commit 978066fe31a5331f143a05e1fd753c729b2dcf09) ** Tags added: in-stable-ocata -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1761054 Title: nova log expose password when swapvolume Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: http://logs.openstack.org/50/557150/6/check/tempest- full/1f9c9f2/controller/logs/screen-n-cpu.txt.gz#_Mar_30_08_37_13_371323 u'auth_password': u'8KigD3KKykJkJixs', u'auth_username': u'6m4wAHCZVqFfTQaF4eZu', To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1761054/+subscriptions