From 1575909 at bugs.launchpad.net Thu Mar 2 17:47:46 2017 From: 1575909 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Mar 2017 17:47:46 -0000 Subject: [Openstack-security] [Bug 1575909] Fix proposed to horizon (stable/ocata) References: <20160427201532.25434.8113.malonedeb@wampee.canonical.com> Message-ID: <20170302174746.7722.30987.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/ocata Review: https://review.openstack.org/440733 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions From 1575909 at bugs.launchpad.net Thu Mar 2 17:47:58 2017 From: 1575909 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Mar 2017 17:47:58 -0000 Subject: [Openstack-security] [Bug 1575909] Fix proposed to horizon (stable/newton) References: <20160427201532.25434.8113.malonedeb@wampee.canonical.com> Message-ID: <20170302174758.20639.64852.malone@soybean.canonical.com> Fix proposed to branch: stable/newton Review: https://review.openstack.org/440734 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions From 1575909 at bugs.launchpad.net Thu Mar 2 17:48:34 2017 From: 1575909 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Mar 2017 17:48:34 -0000 Subject: [Openstack-security] [Bug 1575909] Fix proposed to horizon (stable/mitaka) References: <20160427201532.25434.8113.malonedeb@wampee.canonical.com> Message-ID: <20170302174834.7202.45570.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/mitaka Review: https://review.openstack.org/440736 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions From 1662561 at bugs.launchpad.net Thu Mar 2 21:24:35 2017 From: 1662561 at bugs.launchpad.net (John Griffith) Date: Thu, 02 Mar 2017 21:24:35 -0000 Subject: [Openstack-security] [Bug 1662561] Re: Solidfire disabling certificate verification References: <20170207154946.3933.13220.malonedeb@chaenomeles.canonical.com> Message-ID: <20170302212435.20737.43982.malone@soybean.canonical.com> No current plans to change this, but thanks for logging the bug and we should keep it tracked here. ** Changed in: cinder Status: New => Triaged ** Changed in: cinder Importance: Undecided => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1662561 Title: Solidfire disabling certificate verification Status in Cinder: Triaged Bug description: Solidfire is making reqeust calls with verify=False which disables SSL certificate checks in the following files: cinder/volume/drivers/solidfire.py As suggested in this patch set (https://review.openstack.org/#/c/426385/), this bug is being opened in order to either fix the checks or add comments in the driver explaining why this is safe. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1662561/+subscriptions From 1575909 at bugs.launchpad.net Thu Mar 2 22:25:28 2017 From: 1575909 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Mar 2017 22:25:28 -0000 Subject: [Openstack-security] [Bug 1575909] Re: VPN shared PSK shown in plaintext References: <20160427201532.25434.8113.malonedeb@wampee.canonical.com> Message-ID: <20170302222528.5740.83030.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/440736 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=7a1a8b373935904ce0701f3c3758ec1f56c243ea Submitter: Jenkins Branch: stable/mitaka commit 7a1a8b373935904ce0701f3c3758ec1f56c243ea Author: Julie Gravel Date: Wed Feb 15 12:08:12 2017 -0800 Make VPN IPSec Site Connection PSK field hidden The Pre-Shared Key (PSK) field on the VPN IPSec Site Connection tab should not be displayed in plain text due to security concerns. Set the PSK field in the Add Connection and the Edit Connection dialogs to be a password field to provide the user some protection when entering the value. Remove the PSK field from the details page since this is the pattern used with the password field in Identity Users panel. Change-Id: I4dd713f01b02c29d9822efcb519de60fd9d035e6 Close-Bug: #1575909 (cherry picked from commit 5137dc4fdd19de3494293731abffdfb7e5b26449) ** Tags added: in-stable-mitaka ** Tags added: in-stable-newton -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions From 1575909 at bugs.launchpad.net Thu Mar 2 22:26:35 2017 From: 1575909 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Mar 2017 22:26:35 -0000 Subject: [Openstack-security] [Bug 1575909] Fix merged to horizon (stable/newton) References: <20160427201532.25434.8113.malonedeb@wampee.canonical.com> Message-ID: <20170302222635.20955.89999.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/440734 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=cb65d6b873482c518d602bc7e359dce1c5312454 Submitter: Jenkins Branch: stable/newton commit cb65d6b873482c518d602bc7e359dce1c5312454 Author: Julie Gravel Date: Wed Feb 15 12:08:12 2017 -0800 Make VPN IPSec Site Connection PSK field hidden The Pre-Shared Key (PSK) field on the VPN IPSec Site Connection tab should not be displayed in plain text due to security concerns. Set the PSK field in the Add Connection and the Edit Connection dialogs to be a password field to provide the user some protection when entering the value. Remove the PSK field from the details page since this is the pattern used with the password field in Identity Users panel. Change-Id: I4dd713f01b02c29d9822efcb519de60fd9d035e6 Close-Bug: #1575909 (cherry picked from commit 5137dc4fdd19de3494293731abffdfb7e5b26449) ** Tags added: in-stable-ocata -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions From 1575909 at bugs.launchpad.net Thu Mar 2 22:34:37 2017 From: 1575909 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Mar 2017 22:34:37 -0000 Subject: [Openstack-security] [Bug 1575909] Fix merged to horizon (stable/ocata) References: <20160427201532.25434.8113.malonedeb@wampee.canonical.com> Message-ID: <20170302223437.6144.60891.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/440733 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=03f78705e8e4756537b2da4bbada8101f9f16f3a Submitter: Jenkins Branch: stable/ocata commit 03f78705e8e4756537b2da4bbada8101f9f16f3a Author: Julie Gravel Date: Wed Feb 15 12:08:12 2017 -0800 Make VPN IPSec Site Connection PSK field hidden The Pre-Shared Key (PSK) field on the VPN IPSec Site Connection tab should not be displayed in plain text due to security concerns. Set the PSK field in the Add Connection and the Edit Connection dialogs to be a password field to provide the user some protection when entering the value. Remove the PSK field from the details page since this is the pattern used with the password field in Identity Users panel. Change-Id: I4dd713f01b02c29d9822efcb519de60fd9d035e6 Close-Bug: #1575909 (cherry picked from commit 5137dc4fdd19de3494293731abffdfb7e5b26449) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions From fungi at yuggoth.org Fri Mar 3 16:20:25 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 03 Mar 2017 16:20:25 -0000 Subject: [Openstack-security] [Bug 1666959] Re: ha_vrrp_auth_type defaults to PASS which is insecure References: <20170222154900.3995.72774.malonedeb@chaenomeles.canonical.com> Message-ID: <20170303162026.7826.2881.malone@chaenomeles.canonical.com> Thanks for digging into this. Looks like we can treat it as a public report of a potential security hardening opportunity (there are at least some in the community who would eventually like to see every service able to operate over untrusted backend/admin networks, but it should certainly not be an expectation as things stand today). ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - With l3_ha enabled, ha_vrrp_auth_type defaults to PASS authentication: https://github.com/openstack/neutron/blob/b90ec94dc3f83f63bdb505ace1e4c272435c494b/neutron/conf/agent/l3/ha.py#L28 which according to http://louwrentius.com/configuring-attacking-and- securing-vrrp-on-linux.html is totally insecure because the VRRP password is transmitted in the clear. I'm not sure if this is currently a serious issue, since if the VRRP network is untrusted, maybe there are already bigger problems. But I thought it was worth reporting, at least. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1666959 Title: ha_vrrp_auth_type defaults to PASS which is insecure Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: With l3_ha enabled, ha_vrrp_auth_type defaults to PASS authentication: https://github.com/openstack/neutron/blob/b90ec94dc3f83f63bdb505ace1e4c272435c494b/neutron/conf/agent/l3/ha.py#L28 which according to http://louwrentius.com/configuring-attacking-and- securing-vrrp-on-linux.html is totally insecure because the VRRP password is transmitted in the clear. I'm not sure if this is currently a serious issue, since if the VRRP network is untrusted, maybe there are already bigger problems. But I thought it was worth reporting, at least. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1666959/+subscriptions From gerrit2 at review.openstack.org Sat Mar 4 02:21:55 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 04 Mar 2017 02:21:55 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change I98dac99ba1c13825a56f386a48ee2ebe76b8947a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/441538 Log: commit 083cdecab2e59ecaa5ab7e664516f1c7a18da7d6 Author: Peter Hamilton Date: Fri Mar 3 21:17:27 2017 -0500 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 For more information on past revisions and discussions on this spec, see: https://review.openstack.org/#/c/357151 SecurityImpact DocImpact Change-Id: I98dac99ba1c13825a56f386a48ee2ebe76b8947a From openstack-security at lists.openstack.org Tue Mar 7 19:26:41 2017 From: openstack-security at lists.openstack.org (vlihezzri) Date: Wed, 8 Mar 2017 03:26:41 +0800 Subject: [Openstack-security] =?utf-8?q?openstack-security--=E5=AD=A6?= =?utf-8?b?5Lya6KeE6YG/5ZCI5LyZ5Lq66aOO6Zmp55qENOenjeaWueazlSAgMzoy?= =?utf-8?q?6=3A45?= Message-ID: <20170308032646401757@ds.com> openstack-security：您好！ 1、掌握合伙人的甄选、估值、分钱、退出机制。 2、掌握5种控制权丧失的有效处理方法。 3、学会规避合伙人风险的4种方法。 4、掌握合伙人与股权设计的区别。 了解更多详细内容，请查阅附件。。。 2017/3/8 星期三3:26:45 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 合伙人制度--郑指梁老师 2017.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 24847 bytes Desc: not available URL: From lhinds at redhat.com Thu Mar 9 10:53:07 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 09 Mar 2017 10:53:07 -0000 Subject: [Openstack-security] [Bug 1606495] Re: copy_from in api v1 allows network port scan References: <20160726093308.5782.75451.malonedeb@chaenomeles.canonical.com> Message-ID: <20170309105309.8499.37605.launchpad@chaenomeles.canonical.com> ** Changed in: ossn Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1606495 Title: copy_from in api v1 allows network port scan Status in Glance: New Status in OpenStack Security Advisory: Opinion Status in OpenStack Security Notes: In Progress Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. copy_from allows to create Images with an url like http://localhost:22 The remote content gets copied unverified in the defined glance store. E.g. after downloading the image with copy_from url http://localhost:22, you see the OpenSSH banner. This is a security issue, as it allows users to do network "scans" for open ports and it copies remote (potentially malicious) content unverified to your configured glance store. glance api v1 is still the default in horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1606495/+subscriptions From tdecacqu at redhat.com Wed Mar 15 05:02:26 2017 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 15 Mar 2017 05:02:26 -0000 Subject: [Openstack-security] [Bug 1649248] Re: Glance image upload wizard does not restrict invalid image files References: <20161212105812.12226.46755.malonedeb@wampee.canonical.com> Message-ID: <20170315050226.14906.77900.malone@soybean.canonical.com> Opening this report and adding an OSSN task based on above comments. ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - An unrestricted file upload exists when an application allows users to upload files without proper validation. glance fails to properly validate image files across four key factors including file extension, mime-type, size, and upload frequency. In addition, glance does not appear to scan uploaded files for known malware. Failing to restrict file uploads affects the security of the OpenStack environment in a number of ways. Attacker may commonly use file upload functionality to upload viruses or malware onto trusted servers. In addition to spreading malware, attacker can upload source code files (.aspx and .jsp for example) which may be rendered as valid application pages to end users. Additionally, if users are able to upload files of any size or at any frequency, an attacker may abuse this functionality to exhaust the server’s disk space. Steps To Reproduce: 1. Login to the OpenStack as an admin 2. Click on Images tab and create a new image by uploading a EICAR text file with anti-malware string (EICAR anti-malware test file can be downloaded from http://www.eicar.org/ ) 3. Observe that file is uploaded successfully without any pre-checks being done. The application should validate uploaded files for type and size, and limit how often the user is able to perform uploads. The following validation can be performed: a) If the application requires uploaded files to be of a specific type such as img, vmdk, the application should validate the extension. b) The first four bytes of the file i.e. Magic Numbers can be validated. These first few bytes are known as the file’s ‘Magic Number’ and will uniquely identify the file type. For example all PDF files start with the byte-sequence ‘%PDF’. c) An upper limit on file size can be enforced. In addition to the primary criteria above, all uploaded files should be scanned for known malware/viruses. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1649248 Title: Glance image upload wizard does not restrict invalid image files Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: An unrestricted file upload exists when an application allows users to upload files without proper validation. glance fails to properly validate image files across four key factors including file extension, mime-type, size, and upload frequency. In addition, glance does not appear to scan uploaded files for known malware. Failing to restrict file uploads affects the security of the OpenStack environment in a number of ways. Attacker may commonly use file upload functionality to upload viruses or malware onto trusted servers. In addition to spreading malware, attacker can upload source code files (.aspx and .jsp for example) which may be rendered as valid application pages to end users. Additionally, if users are able to upload files of any size or at any frequency, an attacker may abuse this functionality to exhaust the server’s disk space. Steps To Reproduce: 1. Login to the OpenStack as an admin 2. Click on Images tab and create a new image by uploading a EICAR text file with anti-malware string (EICAR anti-malware test file can be downloaded from http://www.eicar.org/ ) 3. Observe that file is uploaded successfully without any pre-checks being done. The application should validate uploaded files for type and size, and limit how often the user is able to perform uploads. The following validation can be performed: a) If the application requires uploaded files to be of a specific type such as img, vmdk, the application should validate the extension. b) The first four bytes of the file i.e. Magic Numbers can be validated. These first few bytes are known as the file’s ‘Magic Number’ and will uniquely identify the file type. For example all PDF files start with the byte-sequence ‘%PDF’. c) An upper limit on file size can be enforced. In addition to the primary criteria above, all uploaded files should be scanned for known malware/viruses. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1649248/+subscriptions From lhinds at redhat.com Wed Mar 15 10:16:56 2017 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 15 Mar 2017 10:16:56 -0000 Subject: [Openstack-security] [Bug 1649248] Re: Glance image upload wizard does not restrict invalid image files References: <20161212105812.12226.46755.malonedeb@wampee.canonical.com> Message-ID: <20170315101656.24018.91232.malone@gac.canonical.com> Hmm, I am not even sure this constitutes an OSSN. Its kind of obvious that if you publicly expose a service which can store objects, then its fair game for people to dump bad content there. This is going to be yet another 'rate limit / set rbac to admin' OSSN, which we are now doing on a monthly basis. This is covered in the security guide [1] https://docs.openstack.org/security-guide/api-endpoints/api-endpoint- configuration-recommendations.html I would say unless there is some sort of execution / escalation exploit like Ian describes, then this is wish list or recommend a patch to the sec guide. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1649248 Title: Glance image upload wizard does not restrict invalid image files Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: An unrestricted file upload exists when an application allows users to upload files without proper validation. glance fails to properly validate image files across four key factors including file extension, mime-type, size, and upload frequency. In addition, glance does not appear to scan uploaded files for known malware. Failing to restrict file uploads affects the security of the OpenStack environment in a number of ways. Attacker may commonly use file upload functionality to upload viruses or malware onto trusted servers. In addition to spreading malware, attacker can upload source code files (.aspx and .jsp for example) which may be rendered as valid application pages to end users. Additionally, if users are able to upload files of any size or at any frequency, an attacker may abuse this functionality to exhaust the server’s disk space. Steps To Reproduce: 1. Login to the OpenStack as an admin 2. Click on Images tab and create a new image by uploading a EICAR text file with anti-malware string (EICAR anti-malware test file can be downloaded from http://www.eicar.org/ ) 3. Observe that file is uploaded successfully without any pre-checks being done. The application should validate uploaded files for type and size, and limit how often the user is able to perform uploads. The following validation can be performed: a) If the application requires uploaded files to be of a specific type such as img, vmdk, the application should validate the extension. b) The first four bytes of the file i.e. Magic Numbers can be validated. These first few bytes are known as the file’s ‘Magic Number’ and will uniquely identify the file type. For example all PDF files start with the byte-sequence ‘%PDF’. c) An upper limit on file size can be enforced. In addition to the primary criteria above, all uploaded files should be scanned for known malware/viruses. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1649248/+subscriptions From fungi at yuggoth.org Wed Mar 15 20:09:00 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 15 Mar 2017 20:09:00 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170315200900.23223.71690.malone@gac.canonical.com> Given comment #4 and the public nature of the issue, I'm going to go ahead and triage this report as Class B1 (A vulnerability that can only be fixed in master, security note for stable branches, e.g., default config value is insecure): https://security.openstack.org/vmt- process.html#incident-report-taxonomy ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Won't Fix ** Information type changed from Private Security to Public ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From fungi at yuggoth.org Wed Mar 15 20:13:53 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 15 Mar 2017 20:13:53 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170315201354.23733.15025.malone@gac.canonical.com> I've added an OSSN task so the security note editors can decide if this is one they want to cover with some sort of warning for stable branches. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From lhinds at redhat.com Wed Mar 15 22:12:36 2017 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 15 Mar 2017 22:12:36 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170315221236.23223.98210.malone@gac.canonical.com> So if a backport is not possible, what would the full mitigation steps be for ocata and previous? additionalProperties=False -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From lhinds at redhat.com Thu Mar 16 10:39:01 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 16 Mar 2017 10:39:01 -0000 Subject: [Openstack-security] [Bug 1606495] Re: copy_from in api v1 allows network port scan References: <20160726093308.5782.75451.malonedeb@chaenomeles.canonical.com> Message-ID: <20170316103904.23913.24016.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/1606495 Title: copy_from in api v1 allows network port scan Status in Glance: New Status in OpenStack Security Advisory: Opinion Status in OpenStack Security Notes: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. copy_from allows to create Images with an url like http://localhost:22 The remote content gets copied unverified in the defined glance store. E.g. after downloading the image with copy_from url http://localhost:22, you see the OpenSSH banner. This is a security issue, as it allows users to do network "scans" for open ports and it copies remote (potentially malicious) content unverified to your configured glance store. glance api v1 is still the default in horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1606495/+subscriptions From lhinds at redhat.com Thu Mar 16 16:57:44 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 16 Mar 2017 16:57:44 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170316165744.32570.71291.malone@chaenomeles.canonical.com> Thanks Matt, so would I be right in saying there is no mitigation / recommended actions? For an OSSN we need to outline the problem, and more importantly provide recommended actions to take? >From what I can see, this is an issue that can only be addressed with code changes? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From lhinds at redhat.com Thu Mar 16 17:26:35 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 16 Mar 2017 17:26:35 -0000 Subject: [Openstack-security] [Bug 1649248] Re: Glance image upload wizard does not restrict invalid image files References: <20161212105812.12226.46755.malonedeb@wampee.canonical.com> Message-ID: <20170316172635.25318.293.malone@wampee.canonical.com> After discussing this in the OSSP meeting, I will mark this as won't fix for the OSSN, as we already have covered this the recommended actions in several previous OSSNs. There is also a good amount of info in the security guide around protecting end points and access controls available for glance. ** Changed in: ossn Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1649248 Title: Glance image upload wizard does not restrict invalid image files Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Bug description: An unrestricted file upload exists when an application allows users to upload files without proper validation. glance fails to properly validate image files across four key factors including file extension, mime-type, size, and upload frequency. In addition, glance does not appear to scan uploaded files for known malware. Failing to restrict file uploads affects the security of the OpenStack environment in a number of ways. Attacker may commonly use file upload functionality to upload viruses or malware onto trusted servers. In addition to spreading malware, attacker can upload source code files (.aspx and .jsp for example) which may be rendered as valid application pages to end users. Additionally, if users are able to upload files of any size or at any frequency, an attacker may abuse this functionality to exhaust the server’s disk space. Steps To Reproduce: 1. Login to the OpenStack as an admin 2. Click on Images tab and create a new image by uploading a EICAR text file with anti-malware string (EICAR anti-malware test file can be downloaded from http://www.eicar.org/ ) 3. Observe that file is uploaded successfully without any pre-checks being done. The application should validate uploaded files for type and size, and limit how often the user is able to perform uploads. The following validation can be performed: a) If the application requires uploaded files to be of a specific type such as img, vmdk, the application should validate the extension. b) The first four bytes of the file i.e. Magic Numbers can be validated. These first few bytes are known as the file’s ‘Magic Number’ and will uniquely identify the file type. For example all PDF files start with the byte-sequence ‘%PDF’. c) An upper limit on file size can be enforced. In addition to the primary criteria above, all uploaded files should be scanned for known malware/viruses. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1649248/+subscriptions From 1188189 at bugs.launchpad.net Mon Mar 20 04:20:29 2017 From: 1188189 at bugs.launchpad.net (Chris Suttles) Date: Mon, 20 Mar 2017 04:20:29 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20170320042029.19621.2221.malone@soybean.canonical.com> Current status: find cinder/cinder/volume/drivers -name '*.py' | while read file ; do echo "$file" ; nl $file | grep http_client ; done cinder/cinder/volume/drivers/blockbridge.py 24 from six.moves import http_client 128 connection = http_client.HTTPSConnection(cfg['host'], cfg['port']) cinder/cinder/volume/drivers/dell_emc/vmax/https.py 28 from six.moves import http_client 63 Supplies an additional 'makefile' method which http_client requires 74 class HTTPSConnection(http_client.HTTPSConnection): 86 http_client.HTTPSConnection.__init__(self, host, port, 222 response in XML. Uses Python's build-in http_client. x509 may be a 282 except http_client.BadStatusLine as arg: cinder/cinder/volume/drivers/falconstor/rest_proxy.py 23 from six.moves import http_client 821 connection = http_client.HTTPConnection(self.hostip, 80, timeout=60) cinder/cinder/volume/drivers/prophetstor/dplcommon.py 31 from six.moves import http_client 90 connection = http_client.HTTPSConnection(self.ip, 108 except http_client.CannotSendRequest as e: 111 connection = http_client.HTTPSConnection(self.ip, 131 if response.status == http_client.SERVICE_UNAVAILABLE: 140 except http_client.ResponseNotReady as e: 151 and response.status == http_client.NOT_FOUND): 158 'response': http_client.responses[response.status], 160 if response.status == http_client.UNAUTHORIZED: 164 elif retcode == 0 and response.status is http_client.NOT_FOUND: 166 elif retcode == 0 and response.status is http_client.ACCEPTED: 180 response.status in [http_client.OK, http_client.CREATED] and 181 http_client.NO_CONTENT not in expected_status): 211 [http_client.OK, http_client.ACCEPTED]) 233 [http_client.OK, http_client.ACCEPTED, 234 http_client.CREATED]) 253 [http_client.OK, http_client.ACCEPTED, 254 http_client.CREATED]) 264 [http_client.OK, http_client.ACCEPTED, 265 http_client.NOT_FOUND, http_client.NO_CONTENT]) 290 [http_client.OK, http_client.ACCEPTED, 291 http_client.CREATED]) 307 [http_client.OK, http_client.ACCEPTED, 308 http_client.CREATED]) 312 return self._execute(method, url, None, [http_client.OK]) 317 [http_client.OK, http_client.ACCEPTED]) 341 [http_client.OK, http_client.CREATED, 342 http_client.ACCEPTED]) 361 [http_client.OK, http_client.CREATED, 362 http_client.ACCEPTED]) 368 [http_client.OK, http_client.ACCEPTED, 369 http_client.NOT_FOUND]) 376 [http_client.OK, http_client.NOT_FOUND]) 383 [http_client.OK, http_client.NOT_FOUND]) 406 [http_client.OK, http_client.ACCEPTED, 407 http_client.CREATED]) 427 [http_client.OK, http_client.ACCEPTED, 428 http_client.CREATED]) 445 [http_client.OK, http_client.ACCEPTED, 446 http_client.NO_CONTENT, http_client.NOT_FOUND]) 462 [http_client.OK, http_client.ACCEPTED, 463 http_client.NO_CONTENT, http_client.NOT_FOUND]) 477 [http_client.OK, http_client.ACCEPTED, 478 http_client.NO_CONTENT, http_client.NOT_FOUND]) 486 [http_client.OK, http_client.ACCEPTED]) 497 [http_client.OK]) 508 [http_client.OK]) 524 return self._execute(method, url, params, [http_client.OK]) 528 return self._execute(method, url, None, [http_client.OK]) 534 [http_client.OK, http_client.ACCEPTED, 535 http_client.NOT_FOUND]) 543 return self._execute(method, url, None, [http_client.OK]) 551 return self._execute(method, url, params, [http_client.OK]) 570 [http_client.OK, http_client.ACCEPTED, 571 http_client.CREATED]) 578 return self._execute(method, url, None, [http_client.OK]) 582 return self._execute(method, url, None, [http_client.OK]) 591 [http_client.NO_CONTENT, http_client.NOT_FOUND]) 602 [http_client.OK, http_client.ACCEPTED]) 613 [http_client.OK, http_client.ACCEPTED]) cinder/cinder/volume/drivers/qnap.py 34 from six.moves import http_client 694 connection = http_client.HTTPSConnection(management_ip, 698 connection = http_client.HTTPSConnection(management_ip, 702 http_client.HTTPConnection(management_ip, management_port)) 721 connection = http_client.HTTPSConnection(nas_ip, 725 connection = http_client.HTTPSConnection( 728 connection = http_client.HTTPConnection(nas_ip, self.port) cinder/cinder/volume/drivers/zfssa/restclient.py 22 from six.moves import http_client 31 OK = http_client.OK 33 CREATED = http_client.CREATED 35 ACCEPTED = http_client.ACCEPTED 37 NO_CONTENT = http_client.NO_CONTENT 39 BAD_REQUEST = http_client.BAD_REQUEST 41 UNAUTHORIZED = http_client.UNAUTHORIZED 43 FORBIDDEN = http_client.FORBIDDEN 45 NOT_FOUND = http_client.NOT_FOUND 47 NOT_ALLOWED = http_client.METHOD_NOT_ALLOWED 49 TIMEOUT = http_client.REQUEST_TIMEOUT 51 CONFLICT = http_client.CONFLICT 53 BUSY = http_client.SERVICE_UNAVAILABLE 72 self.data = http_client.responses[self.status] 96 if status in http_client.responses: 97 self.msg = http_client.responses[status] 140 if result.status == http_client.CREATED: 146 elif result.status == http_client.NOT_FOUND: 243 if err.code == http_client.NOT_FOUND: 247 if err.code == http_client.SERVICE_UNAVAILABLE and \ 253 if (err.code == http_client.UNAUTHORIZED or 254 err.code == http_client.INTERNAL_SERVER_ERROR) and \ 275 (response.getcode() == http_client.SERVICE_UNAVAILABLE and cinder/cinder/volume/drivers/zfssa/webdavclient.py 19 from six.moves import http_client 28 http_client.UNAUTHORIZED: _('User not authorized to perform WebDAV ' 30 http_client.BAD_GATEWAY: bad_gateway_err, 31 http_client.FORBIDDEN: _('Check access permissions for the ZFS share ' 33 http_client.NOT_FOUND: _('The source volume for this WebDAV operation not ' 35 http_client.INSUFFICIENT_STORAGE: _('Not enough storage space in the ZFS ' 59 if error in http_client.responses: 60 msg = http_client.responses[error] 97 if err.code == http_client.INTERNAL_SERVER_ERROR: 112 except http_client.BadStatusLine as err: 114 code = 'http_client.BadStatusLine' -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: Triaged Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in oslo.vmware: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Mon Mar 20 04:23:14 2017 From: 1188189 at bugs.launchpad.net (Chris Suttles) Date: Mon, 20 Mar 2017 04:23:14 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20170320042314.18188.16901.malone@gac.canonical.com> Eek, I didn't realize that would be such a big wall of text. It looks like this has been stagnant for a while and the requirements are pretty simple, so I am going to reassign this to myself and start working through the drivers that are using six.moves.http_client and migrating them to requests instead. ** Changed in: cinder Assignee: Daniel Gollub (d-gollub) => Chris Suttles (killface007) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: Triaged Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in oslo.vmware: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From fungi at yuggoth.org Mon Mar 20 14:53:39 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 20 Mar 2017 14:53:39 -0000 Subject: [Openstack-security] [Bug 1664723] Re: replication_slave user and passwords exposed in logging References: <20170214213337.4535.90559.malonedeb@chaenomeles.canonical.com> Message-ID: <20170320145340.22074.12923.launchpad@chaenomeles.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1664723 Title: replication_slave user and passwords exposed in logging Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): New 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 fungi at yuggoth.org Mon Mar 20 18:06:43 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 20 Mar 2017 18:06:43 -0000 Subject: [Openstack-security] [Bug 1674191] Re: HTTPS connection and authentication are not supported between swift-proxy and swift-account-server/swift-container-server/swift-object-server. References: <20170320022807.21802.11760.malonedeb@chaenomeles.canonical.com> Message-ID: <20170320180643.30302.59137.malone@wampee.canonical.com> Based on John's input above, this is more a class D report (security hardening opportunity) with no need for embargo nor advisory. Triaging accordingly. ** Changed in: ossa Status: Incomplete => Won't Fix ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - HTTPS connection and authentication are not supported between swift- proxy and swift-account-server/swift-container-server/swift-object- server. The issue description as following: All the components of swift-proxy, swift-account-server, swift-container-server, swift-object-server can be deployed in multi-node. All the services of swift-store can be access without authentication, swift-proxy as a client, it communicates to the swift-store though clear http connection. If an attacker in internal-base network, he can get the transfered information easily, he also can attack the swift-store services with rest-api-command. The base-cvss-score of the issue is 6.3. ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1674191 Title: HTTPS connection and authentication are not supported between swift- proxy and swift-account-server/swift-container-server/swift-object- server. Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Object Storage (swift): Confirmed Bug description: HTTPS connection and authentication are not supported between swift- proxy and swift-account-server/swift-container-server/swift-object- server. The issue description as following: All the components of swift-proxy, swift-account-server, swift-container-server, swift-object-server can be deployed in multi-node. All the services of swift-store can be access without authentication, swift-proxy as a client, it communicates to the swift-store though clear http connection. If an attacker in internal-base network, he can get the transfered information easily, he also can attack the swift-store services with rest-api-command. The base-cvss-score of the issue is 6.3. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1674191/+subscriptions From fungi at yuggoth.org Tue Mar 21 15:08:07 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 21 Mar 2017 15:08:07 -0000 Subject: [Openstack-security] [Bug 1673569] Re: Failed notification payload is dumped in logs with auth secrets References: <20170316184124.23466.51016.malonedeb@gac.canonical.com> Message-ID: <20170321150807.17598.41379.malone@gac.canonical.com> Thanks Matt, I've switched this to Public Security and am moving forward with the CVE assignment request using the impact statement from comment #10. ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673569 Title: Failed notification payload is dumped in logs with auth secrets Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Released Status in OpenStack Compute (nova) newton series: Fix Released Status in OpenStack Compute (nova) ocata series: Fix Released Status in OpenStack Security Advisory: Confirmed Bug description: Noticed here: http://logs.openstack.org/08/445308/3/check/gate-tempest-dsvm-py35 -ubuntu- xenial/7bf0d72/logs/screen-n-api.txt.gz#_2017-03-16_05_31_09_399 I noticed this while investigating public nova bug 1673375, but it looks like that bug is caused by a ValueError coming from the oslo.messaging notification code, related to a circular reference in the json blob: 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging Traceback (most recent call last): 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/notify/messaging.py", line 70, in notify 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/transport.py", line 104, in _send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 509, in send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging envelope=(version == 2.0), notify=True, retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 457, in _send 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging msg = rpc_common.serialize_msg(msg) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/common.py", line 293, in serialize_msg 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging _MESSAGE_KEY: jsonutils.dumps(raw_msg)} 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_serialization/jsonutils.py", line 190, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return json.dumps(obj, default=default, **kwargs) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/__init__.py", line 237, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging **kw).encode(obj) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 198, in encode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging chunks = self.iterencode(o, _one_shot=True) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 256, in iterencode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return _iterencode(o, 0) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging ValueError: Circular reference detected 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging The security issue here is that the notification payload that's logged has all kinds of auth secrets in it, like tokens and passwords. From logstash it looks like this is only hitting master (pike) right now. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673569/+subscriptions From tdecacqu at redhat.com Tue Mar 21 15:13:22 2017 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 21 Mar 2017 15:13:22 -0000 Subject: [Openstack-security] [Bug 1673569] Re: Failed notification payload is dumped in logs with auth secrets References: <20170316184124.23466.51016.malonedeb@gac.canonical.com> Message-ID: <20170321151323.22178.49795.launchpad@chaenomeles.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - Noticed here: http://logs.openstack.org/08/445308/3/check/gate-tempest-dsvm-py35 -ubuntu-xenial/7bf0d72/logs/screen-n-api.txt.gz#_2017-03-16_05_31_09_399 I noticed this while investigating public nova bug 1673375, but it looks like that bug is caused by a ValueError coming from the oslo.messaging notification code, related to a circular reference in the json blob: 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging Traceback (most recent call last): 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/notify/messaging.py", line 70, in notify 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/transport.py", line 104, in _send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 509, in send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging envelope=(version == 2.0), notify=True, retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 457, in _send 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging msg = rpc_common.serialize_msg(msg) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/common.py", line 293, in serialize_msg 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging _MESSAGE_KEY: jsonutils.dumps(raw_msg)} 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_serialization/jsonutils.py", line 190, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return json.dumps(obj, default=default, **kwargs) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/__init__.py", line 237, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging **kw).encode(obj) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 198, in encode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging chunks = self.iterencode(o, _one_shot=True) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 256, in iterencode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return _iterencode(o, 0) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging ValueError: Circular reference detected 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging The security issue here is that the notification payload that's logged has all kinds of auth secrets in it, like tokens and passwords. From logstash it looks like this is only hitting master (pike) right now. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673569 Title: Failed notification payload is dumped in logs with auth secrets Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Released Status in OpenStack Compute (nova) newton series: Fix Released Status in OpenStack Compute (nova) ocata series: Fix Released Status in OpenStack Security Advisory: Confirmed Bug description: Noticed here: http://logs.openstack.org/08/445308/3/check/gate-tempest-dsvm-py35 -ubuntu- xenial/7bf0d72/logs/screen-n-api.txt.gz#_2017-03-16_05_31_09_399 I noticed this while investigating public nova bug 1673375, but it looks like that bug is caused by a ValueError coming from the oslo.messaging notification code, related to a circular reference in the json blob: 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging Traceback (most recent call last): 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/notify/messaging.py", line 70, in notify 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/transport.py", line 104, in _send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 509, in send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging envelope=(version == 2.0), notify=True, retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 457, in _send 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging msg = rpc_common.serialize_msg(msg) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/common.py", line 293, in serialize_msg 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging _MESSAGE_KEY: jsonutils.dumps(raw_msg)} 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_serialization/jsonutils.py", line 190, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return json.dumps(obj, default=default, **kwargs) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/__init__.py", line 237, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging **kw).encode(obj) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 198, in encode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging chunks = self.iterencode(o, _one_shot=True) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 256, in iterencode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return _iterencode(o, 0) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging ValueError: Circular reference detected 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging The security issue here is that the notification payload that's logged has all kinds of auth secrets in it, like tokens and passwords. From logstash it looks like this is only hitting master (pike) right now. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673569/+subscriptions From fungi at yuggoth.org Tue Mar 21 17:10:11 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 21 Mar 2017 17:10:11 -0000 Subject: [Openstack-security] [Bug 1673569] Re: Failed notification payload is dumped in logs with auth secrets References: <20170316184124.23466.51016.malonedeb@gac.canonical.com> Message-ID: <20170321171013.21967.30551.launchpad@chaenomeles.canonical.com> ** Changed in: ossa Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673569 Title: Failed notification payload is dumped in logs with auth secrets Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Released Status in OpenStack Compute (nova) newton series: Fix Released Status in OpenStack Compute (nova) ocata series: Fix Released Status in OpenStack Security Advisory: In Progress Bug description: Noticed here: http://logs.openstack.org/08/445308/3/check/gate-tempest-dsvm-py35 -ubuntu- xenial/7bf0d72/logs/screen-n-api.txt.gz#_2017-03-16_05_31_09_399 I noticed this while investigating public nova bug 1673375, but it looks like that bug is caused by a ValueError coming from the oslo.messaging notification code, related to a circular reference in the json blob: 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging Traceback (most recent call last): 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/notify/messaging.py", line 70, in notify 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/transport.py", line 104, in _send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 509, in send_notification 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging envelope=(version == 2.0), notify=True, retry=retry) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 457, in _send 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging msg = rpc_common.serialize_msg(msg) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_messaging/_drivers/common.py", line 293, in serialize_msg 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging _MESSAGE_KEY: jsonutils.dumps(raw_msg)} 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/local/lib/python3.5/dist-packages/oslo_serialization/jsonutils.py", line 190, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return json.dumps(obj, default=default, **kwargs) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/__init__.py", line 237, in dumps 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging **kw).encode(obj) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 198, in encode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging chunks = self.iterencode(o, _one_shot=True) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging File "/usr/lib/python3.5/json/encoder.py", line 256, in iterencode 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging return _iterencode(o, 0) 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging ValueError: Circular reference detected 2017-03-16 05:31:09.399 23355 ERROR oslo_messaging.notify.messaging The security issue here is that the notification payload that's logged has all kinds of auth secrets in it, like tokens and passwords. From logstash it looks like this is only hitting master (pike) right now. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673569/+subscriptions From openstack-security at lists.openstack.org Wed Mar 22 18:37:55 2017 From: openstack-security at lists.openstack.org (bn) Date: Thu, 23 Mar 2017 02:37:55 +0800 Subject: [Openstack-security] =?utf-8?q?openstack-security=3A=E5=90=88?= =?utf-8?b?5LyZ5Lq65Yi25bqm5rOo5oSP5LqL6aG5ICA2aHpucw==?= Message-ID: <20170323023800565273@qgy.com> openstack-security：您好！ 1、掌握合伙人的甄选、估值、分钱、退出机制。 2、掌握5种控制权丧失的有效处理方法。 3、学会规避合伙人风险的4种方法。 4、掌握合伙人与股权设计的区别。 了解更多详细内容，请查阅附件。。。 2017-3-232:37:59 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 合伙人制度--郑指梁老师 2017.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 24915 bytes Desc: not available URL: From gerrit2 at review.openstack.org Wed Mar 22 21:24:28 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 22 Mar 2017 21:24:28 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit 6ed65dcf31b6c109bd69401dc22fb82b1e843955 Author: Peter Hamilton Date: Wed Mar 22 17:16:26 2017 -0400 Add support for certificate validation This spec describes changes that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of Nova API changes allows Nova users to control the certificates which are allowed to sign images. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 APIImpact DocImpact SecurityImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73 From lhinds at redhat.com Thu Mar 23 16:55:50 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 23 Mar 2017 16:55:50 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170323165550.30778.37418.malone@soybean.canonical.com> Its looking like this cannot be resolved with an OSSN. I will give this another week, and unless shown otherwise will mark it as wont' fix only under OpenStack Security Notes. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From 1673085 at bugs.launchpad.net Thu Mar 23 17:17:06 2017 From: 1673085 at bugs.launchpad.net (Robert Clark) Date: Thu, 23 Mar 2017 17:17:06 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170323171707.30932.93716.malone@wampee.canonical.com> Looks to me like like B1 + OSSA (public) is the most appropriate path? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From fungi at yuggoth.org Thu Mar 23 18:25:13 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 23 Mar 2017 18:25:13 -0000 Subject: [Openstack-security] [Bug 1673085] Re: scheduler hints are unbounded and never deleted References: <20170315141937.32150.35944.malonedeb@chaenomeles.canonical.com> Message-ID: <20170323182513.30525.38062.malone@wampee.canonical.com> OSSA are specific to issues fixed in supported stable branches. If they can only be fixed in master (and so future major releases), we don't issue advisories because there is no fix for operators to apply. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+subscriptions From gerrit2 at review.openstack.org Thu Mar 23 18:38:45 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 23 Mar 2017 18:38:45 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit 13d7a4a7ba428e24b2becb0b25facb3a1588cd4f Author: Peter Hamilton Date: Wed Mar 22 17:16:26 2017 -0400 Add support for certificate validation This spec describes changes that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of Nova API changes allows Nova users to control the certificates which are allowed to sign images. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 APIImpact DocImpact SecurityImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73 From openstack-security at lists.openstack.org Thu Mar 23 21:36:58 2017 From: openstack-security at lists.openstack.org (vhtswqja) Date: Fri, 24 Mar 2017 05:36:58 +0800 Subject: [Openstack-security] =?utf-8?b?b3BlbnN0YWNrLXNlY3VyaXR577ya6Ie0?= =?utf-8?b?5omA5pyJSFLnmoTkuIDlsIHkv6EgIDU6Mzc6MDY=?= Message-ID: <20170324053708558388@wain.com> 人力资源效能方程式 【时间地点】 2017年 4月14-15日杭州 【学习费用】4980元/人（包含教材，午餐，茶点。。。） 【参加对象】 HR经理、总监；中高层领导、基础管理人员及对本课程感兴趣的人士 【授课方式】 讲师讲授 + 视频演绎 + 案例研讨 +角色扮演 + 讲师点评 + 落地工具 【联系方式】 021-31006787, 13381601000 (许先生) 【QQ/微信】320588808 【课程特色】 1、全国第一个HR与财务相结合的课程； 2、原创提出人力资源效能方程式的概念； 3、系统地提出HR资产负债表、HR价值转化表及HR现金流向表； 4、原创性提出HR数据预警指标的概念； 5、结合个税筹划，提出HR开源和人工成本降低的方法。 【课程收益】 1、HR与财务同频：去六大模块思维，把财务数据转化为工具，形成产品化思维； 2、HR与业务实现：了解财务与经营，更好地支持业务部门工作的开展； 3、HR与数据分析：理解财务报表背后的数据信息，减少与业务部门沟通的成本； 4、HR与绩效改进：掌握绩效数据间的勾稽关系，从财务角度理解KPI指标设定； 5、HR与价值创造：学会个税筹划的技巧，及降本提效的方法。 【工具包】 工具1：HR效能方程式 工具2：业务的量本利分析法 工具3：杜邦分析法在HR中的运用 工具4：HR业务数据分析图 工具5：年终奖计税 工具6： HR价值表 【场景应用】 应用1：盈亏平衡点用在HR的编制管理上 应用2：毛利率如何用在HR的绩效考核上 应用3：利润表上的净利润在HR考核中的误区 应用4：如何从财务角度来做HR成本表 应用5：杜邦分析法用在HR的绩效改进上 应用6：业务仪表盘—预警业务进展 【课程大纲】 第一部分 新时代赋予HR的新使命（第一天上午，上午0.5小时） 一、互联网对HR的新挑战 二、新时代对HR的新定义 工具1：HR效能方程式 第二部分 HR经营化 （第一天上午， 2.5小时+第一天下午2小时） 一、看业务 （一）HR如何理解销售收入？-案例1：卖多少包子店才盈亏平衡？ 工具2：业务的量本利分析法 场景应用1：盈亏平衡点用在HR的编制管理上 （二）HR如何理解毛利率？ 场景应用2：毛利率如何用在HR的绩效考核上 案例2：某公司的基于业务毛利率考核方案 二、看财务 （一）跨界打劫－财务是HR门口的“野蛮人”吗？ （二）同频对话－HR如何看懂财务的三张报表？ 1、HR的地盘能自己做主吗？ 场景应用3：利润表上的净利润在HR考核中的误区 2、大部分HR不知道财务数据之间的勾稽关系 场景应用4：如何从财务角度来做HR成本表 （三）杜邦分析法－HR与财务的结合点（实操演练，带笔记本电脑） 案例3：某企业ROE由28.6%下降至9.82%，经分析是人工成本过高造成的，HR是如何做绩改改进的 应用5：杜邦分析法用在HR的绩效改进上 第三部分 HR数据化（第一天下午，2小时+第二天上午2小时） 一、看关联 （一）HR数据间关联－HR的静态存量数据 某IT企业骨干员工离职率由39%下降到8%，销售收入增长55%？ 案例4：某企业如何通过三定数据分析减少3人？ （二）HR与业务关联－HR的动态增量数据 1、HR拿到的数据和呈现给领导的数据是两回事，如何处理？ 案例5：去年人工成本率是8.3%，今年是9.2%，人工成本增加在哪些科目上，对业务是什么影响？ 2、人工成本结构数据。 工具4： HR业务数据分析图 二、看预警 （一）HR指标预警 1、业务仪表盘—预警业务进展（应用5）---实操演练，带笔记本电脑 2、KPI仪表盘－预警项目进展的指标 3、人工成本率－预警人效提升的指标 （二）HR人才预警 第四部分 HR价值化（第二天下午，1.5小时，实操演练，带笔记本电脑） 一、看开源 （一）HR贡献 案例6：HR部门的贡献如何测算？ （二）个税筹划 工具5：年终奖计税 二、看节流 案例7：华为公司如何让一个企业实现员工下降50%，人均劳动力增长80%，而销售收入增长20%？ 第五部分 HR"才"报化（第二天下午，1.5小时） 现场演练：HR价值表 工具6： HR价值表 讲师简介：郑指梁 实战人力资源＆财务管理专家 管理学硕士、注册会计师、注册税务师 浙江大学、中山大学总裁班特邀讲师 浙江省企业培训师协会副会长 国家人力资源管理师一级辅导师 曾任美国Bel Fuse Inc.中国区人力资源经理、财务总监 曾任世界500强人力资源总监、财务总监 国内人力资源与财务管理结合专家 个人经历 具有近20年的HR、财务、税务、投行、资本运作等从业经验，曾服务于世界500强企业及中国民营500强企业；熟悉跨国公司与民营企业管理的规律与特点。是业内不多的能同时把人力资源与财务、投行有效结合起来的专家。 熟悉私募基金运营、资本运作、投融资、股权融资、收购兼并。参与并主导多家企业的IPO（主板与新三板）上市工作，并积累丰富的投行经验。 原创性提出私募基金在合伙人制度当中的运用，HR效能方式方程式等思路与模式。他在多年HR和财务工作实践经验中总结提炼而成的《合伙人制度》、《人力资源效能方程式》、《非财务经理的财务管理》课程多次面向社会开设公开课，获得学员高度认可和广泛运用。 主讲课程 《合伙人制度》《人力资源效能方程式》《HR如何有效支持业务伙伴》《非财务经理的财务管理》《绩效管理实操及落地提升》 《人力资源经理的财务管理》《绩效平衡与落地》《基于smart原理的薪酬体系设计》 -------------- next part -------------- An HTML attachment was scrubbed... URL: From major at mhtx.net Tue Mar 28 12:56:17 2017 From: major at mhtx.net (Major Hayden) Date: Tue, 28 Mar 2017 12:56:17 -0000 Subject: [Openstack-security] [Bug 1676865] [NEW] RHEL 7 STIG final version released with renumbering Message-ID: <20170328125617.10482.27035.malonedeb@wampee.canonical.com> Public bug reported: The final version of the RHEL 7 STIG was recently released and the content has changed along with the numbering. The old-style numbering (RHEL-07-010040) has been replaced with the V-##### numbering standard. ** Affects: openstack-ansible Importance: High Assignee: Major Hayden (rackerhacker) Status: Confirmed ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1676865 Title: RHEL 7 STIG final version released with renumbering Status in openstack-ansible: Confirmed Bug description: The final version of the RHEL 7 STIG was recently released and the content has changed along with the numbering. The old-style numbering (RHEL-07-010040) has been replaced with the V-##### numbering standard. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1676865/+subscriptions From 1676865 at bugs.launchpad.net Tue Mar 28 13:45:09 2017 From: 1676865 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 28 Mar 2017 13:45:09 -0000 Subject: [Openstack-security] [Bug 1676865] Related fix proposed to openstack-ansible-security (master) References: <20170328125617.10482.27035.malonedeb@wampee.canonical.com> Message-ID: <20170328134509.25688.23402.malone@chaenomeles.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/450790 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1676865 Title: RHEL 7 STIG final version released with renumbering Status in openstack-ansible: Confirmed Bug description: The final version of the RHEL 7 STIG was recently released and the content has changed along with the numbering. The old-style numbering (RHEL-07-010040) has been replaced with the V-##### numbering standard. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1676865/+subscriptions From fungi at yuggoth.org Thu Mar 30 13:24:52 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 30 Mar 2017 13:24:52 -0000 Subject: [Openstack-security] [Bug 1674954] Re: trove log-enable causes unnecessary file permission change References: <20170322104835.30899.5431.malonedeb@wampee.canonical.com> Message-ID: <20170330132452.25876.90709.malone@chaenomeles.canonical.com> Thanks Amrith, I'll switch this bug to public and triage it as a potential hardening opportunity in that case. ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - When log-enable called, Guestagent try to change log directory permission to readable. Unfortunately, it changes permission in recursively like below. This is security issue that allow any of OS users to read the database data files. I believe that we should fix this line. https://github.com/openstack/trove/blob/master/trove/guestagent/guest_log.py#L115 [samitani at samitani-mi02-member-2 ~]$ sudo grep 'Running cmd' /var/log/trove/guestagent.log 2017-03-22 19:21:47.070 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpoJ2r5O execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.078 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpoJ2r5O execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.117 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.136 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp0AhUIT execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.142 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp0AhUIT execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.153 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.177 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.183 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.190 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.196 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.202 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.209 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.216 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.222 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.228 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.235 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.241 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.743 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/lib/mysql/data execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.760 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/lib/mysql/data execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.769 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/log/trove execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.777 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.846 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-disable_general_log\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.853 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpNUmZt6 execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.860 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpNUmZt6 execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.883 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.890 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp7MujEH execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.897 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp7MujEH execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.905 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-enable_general_log\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.912 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.920 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /tmp/tmpTVRVmR /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.926 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.932 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.939 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpCzeJfw execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.945 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpCzeJfw execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.988 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.995 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp7O4zdM execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.002 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp7O4zdM execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.010 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-002-enable_general_log.cnf /tmp/tmp_Kw0Ju execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.016 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp_Kw0Ju execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:47.599 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): /usr/bin/mysqladmin ping execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1674954 Title: trove log-enable causes unnecessary file permission change Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): New Bug description: When log-enable called, Guestagent try to change log directory permission to readable. Unfortunately, it changes permission in recursively like below. This is security issue that allow any of OS users to read the database data files. I believe that we should fix this line. https://github.com/openstack/trove/blob/master/trove/guestagent/guest_log.py#L115 [samitani at samitani-mi02-member-2 ~]$ sudo grep 'Running cmd' /var/log/trove/guestagent.log 2017-03-22 19:21:47.070 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpoJ2r5O execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.078 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpoJ2r5O execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.117 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.136 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp0AhUIT execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.142 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp0AhUIT execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.153 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.177 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.183 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.190 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.196 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.202 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.209 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.216 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.222 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.228 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.235 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.241 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.743 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/lib/mysql/data execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.760 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/lib/mysql/data execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.769 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/log/trove execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.777 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.846 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-disable_general_log\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.853 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpNUmZt6 execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.860 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpNUmZt6 execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.883 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.890 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp7MujEH execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.897 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp7MujEH execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.905 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-enable_general_log\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.912 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.920 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /tmp/tmpTVRVmR /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.926 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.932 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.939 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpCzeJfw execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.945 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpCzeJfw execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.988 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.995 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp7O4zdM execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.002 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp7O4zdM execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.010 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-002-enable_general_log.cnf /tmp/tmp_Kw0Ju execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.016 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp_Kw0Ju execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:47.599 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): /usr/bin/mysqladmin ping execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1674954/+subscriptions From fungi at yuggoth.org Thu Mar 30 13:23:15 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 30 Mar 2017 13:23:15 -0000 Subject: [Openstack-security] [Bug 1663417] Re: Bandit issue B701:jinja2_autoescape_false References: <20170209231702.6449.93775.malonedeb@wampee.canonical.com> Message-ID: <20170330132315.10385.18477.malone@wampee.canonical.com> Thanks Amrith, I'll switch this bug to public and triage it as a potential hardening opportunity in that case. ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - After running bandit it found an issue of Severity and Confidence High. Test results: >> Issue: [B701:jinja2_autoescape_false] By default, jinja2 sets autoescape to False. Consider using autoescape=True to mitigate XSS vulnerabilities.    Severity: High Confidence: High    Location: trove/common/utils.py:53 51 52 def build_jinja_environment(): 53 env = jinja2.Environment(loader=jinja2.ChoiceLoader([ 54 jinja2.FileSystemLoader(CONF.template_path), 55 jinja2.PackageLoader("trove", "templates") 56 ])) 57 # Add some basic operation not built-in. simply adding the argument autoescape=True to the function call will fix the issue. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1663417 Title: Bandit issue B701:jinja2_autoescape_false Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): New Bug description: After running bandit it found an issue of Severity and Confidence High. Test results: >> Issue: [B701:jinja2_autoescape_false] By default, jinja2 sets autoescape to False. Consider using autoescape=True to mitigate XSS vulnerabilities.    Severity: High Confidence: High    Location: trove/common/utils.py:53 51 52 def build_jinja_environment(): 53 env = jinja2.Environment(loader=jinja2.ChoiceLoader([ 54 jinja2.FileSystemLoader(CONF.template_path), 55 jinja2.PackageLoader("trove", "templates") 56 ])) 57 # Add some basic operation not built-in. simply adding the argument autoescape=True to the function call will fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1663417/+subscriptions From gerrit2 at review.openstack.org Thu Mar 30 17:04:46 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Mar 2017 17:04:46 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/401808 Log: commit c51f1cc90589d47511d4155f4a5b69377944160b Author: Adam Young Date: Thu Nov 3 20:13:07 2016 -0400 URL pattern based RBAC Management Interface A new entity in the Role backend that maps from VERB URL-Pattern to ROle. I.E. from GET /v2/users to Member Beyond the backend and CRUD API for URL patterns there is also a Bulk Upload and management API. No RBAC enforcement is done in this commit, just management of the data that will be used in Keystone middleware. blueprint token-verify-role-check SecurityImpact APIImpact Change-Id: I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb From gerrit2 at review.openstack.org Thu Mar 30 17:56:27 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Mar 2017 17:56:27 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/401808 Log: commit 7ccfd156185af3a272fbf7cd914f632a8becc5d1 Author: Adam Young Date: Thu Nov 3 20:13:07 2016 -0400 URL pattern based RBAC Management Interface A new entity in the Role backend that maps from VERB URL-Pattern to ROle. I.E. from GET /v2/users to Member Beyond the backend and CRUD API for URL patterns there is also a Bulk Upload and management API. No RBAC enforcement is done in this commit, just management of the data that will be used in Keystone middleware. blueprint role-check-from-middleware SecurityImpact APIImpact Change-Id: I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb From gerrit2 at review.openstack.org Thu Mar 30 20:15:48 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Mar 2017 20:15:48 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change 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 6e62bab0694d9f49c175615cd88b13fd3a69d863 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/357151/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From gerrit2 at review.openstack.org Fri Mar 31 14:03:32 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 31 Mar 2017 14:03:32 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/401808 Log: commit fc87a5b49fc979f4a383fd1fb6828f7733b66419 Author: Adam Young Date: Thu Nov 3 20:13:07 2016 -0400 URL pattern based RBAC Management Interface A new entity in the Role backend that maps from VERB URL-Pattern to ROle. I.E. from GET /v2/users to Member Beyond the backend and CRUD API for URL patterns there is also a Bulk Upload and management API. No RBAC enforcement is done in this commit, just management of the data that will be used in Keystone middleware. blueprint token-verify-role-check SecurityImpact APIImpact Change-Id: I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb From gerrit2 at review.openstack.org Fri Mar 31 15:00:52 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 31 Mar 2017 15:00:52 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/401808 Log: commit 5e3fed342ed844dc410c1b28ae6aaf9d710cad97 Author: Adam Young Date: Thu Nov 3 20:13:07 2016 -0400 URL pattern based RBAC Management Interface A new entity in the Role backend that maps from VERB URL-Pattern to ROle. I.E. from GET /v2/users to Member Beyond the backend and CRUD API for URL patterns there is also a Bulk Upload and management API. No RBAC enforcement is done in this commit, just management of the data that will be used in Keystone middleware. blueprint role-check-from-middleware SecurityImpact APIImpact Change-Id: I4cc3fd9e0958c3f7fda83ad696807a7c8f63cecb From gerrit2 at review.openstack.org Fri Mar 31 18:21:09 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 31 Mar 2017 18:21:09 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Id2304adeb9490a630e1979bb70037ad8a2656d73 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357151 Log: commit 5212836fd402fe2460c9a73290699a74200cbc5c Author: Peter Hamilton Date: Wed Mar 22 17:16:26 2017 -0400 Add support for certificate validation This spec describes changes that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of Nova API changes allows Nova users to control the certificates which are allowed to sign images. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 APIImpact DocImpact SecurityImpact Change-Id: Id2304adeb9490a630e1979bb70037ad8a2656d73