From 1668503 at bugs.launchpad.net Fri Jun 2 12:20:50 2017 From: 1668503 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 02 Jun 2017 12:20:50 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <149640605042.25087.8006782649306138740.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/438701 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8ad765e0230ceeb5ca7c36ec3ed6d25c57b22c9d Submitter: Jenkins Branch: master commit 8ad765e0230ceeb5ca7c36ec3ed6d25c57b22c9d Author: Morgan Fainberg Date: Mon Feb 27 13:06:07 2017 -0800 Support new hashing algorithms for securely storing password hashes Support bcrypt, pbkdf2_sha512, or scrypt in password hashing for passwords managed within keystone. sha512_crypt is insufficient to hash passwords in a secure way for storage in the DB. Keystone defaults now to using bcrypt but can handle scrypt and pbkdf2_sha512 with a number of tuning options if desired. Closes-bug: #1543048 Closes-bug: #1668503 Change-Id: Id05026720839d94de26d0e44631deb34bcc0e610 ** Changed in: keystone 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/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Incomplete Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From 1543048 at bugs.launchpad.net Fri Jun 2 12:20:43 2017 From: 1543048 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 02 Jun 2017 12:20:43 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <149640604332.22938.6281940883301842618.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/438701 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8ad765e0230ceeb5ca7c36ec3ed6d25c57b22c9d Submitter: Jenkins Branch: master commit 8ad765e0230ceeb5ca7c36ec3ed6d25c57b22c9d Author: Morgan Fainberg Date: Mon Feb 27 13:06:07 2017 -0800 Support new hashing algorithms for securely storing password hashes Support bcrypt, pbkdf2_sha512, or scrypt in password hashing for passwords managed within keystone. sha512_crypt is insufficient to hash passwords in a secure way for storage in the DB. Keystone defaults now to using bcrypt but can handle scrypt and pbkdf2_sha512 with a number of tuning options if desired. Closes-bug: #1543048 Closes-bug: #1668503 Change-Id: Id05026720839d94de26d0e44631deb34bcc0e610 ** Changed in: keystone 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/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): Fix Released Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From 1693343 at bugs.launchpad.net Wed Jun 7 12:01:52 2017 From: 1693343 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 07 Jun 2017 12:01:52 -0000 Subject: [Openstack-security] [Bug 1693343] Fix included in openstack/openstack-ansible-security 16.0.0.0b2 References: <149565524123.24782.9127842748680337701.malonedeb@soybean.canonical.com> Message-ID: <149683691221.2394.5633436186299855545.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible-security 16.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1693343 Title: V-71945 fails on CentOS 7 Status in openstack-ansible: Fix Released Bug description: 2017-05-24 17:35:21.290912 | TASK [openstack-ansible-security : V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked.] *** 2017-05-24 17:35:21.312253 | Wednesday 24 May 2017 17:35:21 +0000 (0:00:00.320) 0:00:19.083 ********* 2017-05-24 17:35:21.468598 | fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Path pam_password_file does not exist !", "rc": 257} To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1693343/+subscriptions From 1686110 at bugs.launchpad.net Wed Jun 7 12:01:55 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 07 Jun 2017 12:01:55 -0000 Subject: [Openstack-security] [Bug 1686110] Fix included in openstack/openstack-ansible-security 16.0.0.0b2 References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <149683691525.9795.677083766271600718.malone@wampee.canonical.com> This issue was fixed in the openstack/openstack-ansible-security 16.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions From 1663417 at bugs.launchpad.net Wed Jun 7 21:59:20 2017 From: 1663417 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 07 Jun 2017 21:59:20 -0000 Subject: [Openstack-security] [Bug 1663417] Fix included in openstack/trove 8.0.0.0b2 References: <20170209231702.6449.93775.malonedeb@wampee.canonical.com> Message-ID: <149687276055.2255.4053893129834332418.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/trove 8.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1663417 Title: Bandit issue B701:jinja2_autoescape_false Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): Fix Released 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 1445295 at bugs.launchpad.net Thu Jun 8 12:15:02 2017 From: 1445295 at bugs.launchpad.net (Amrith Kumar) Date: Thu, 08 Jun 2017 12:15:02 -0000 Subject: [Openstack-security] [Bug 1445295] Re: Guestagent config leaks rabbit password References: <20150417022721.14148.34459.malonedeb@wampee.canonical.com> Message-ID: <149692410447.8280.17908518377386729017.launchpad@gac.canonical.com> ** Changed in: trove Status: New => Invalid ** Changed in: trove Assignee: Amrith Kumar (amrith) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445295 Title: Guestagent config leaks rabbit password Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): Invalid Bug description: A running guest vm has the guestagent service running. Included in this is the trave-guestagent.conf file. This contains (at least) the rabbit password. It is pretty easy to extract this as an unprivileged user - given that the guest image is publicly available, it can be downloaded, and (if needed) converted to raw and mounted. From this either: - config can be immediately read if guestagent is pre-installed (or) - rsync command and ip + location of config files can be gleaned from the init script In the second case it is then pretty easy to boot a vm on the appropriate network and rsync the config files using the above gleaned command(s) as required (e.g add keys to the previously downloaded trove guest image, upload it to glance then run it directly from nova and ssh in...). I'm thinking that we need to setup the guestagent so it does *not* need to know this level of detail about the inner workings of Openstack. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1445295/+subscriptions From sean at dague.net Thu Jun 8 12:20:55 2017 From: sean at dague.net (Sean Dague) Date: Thu, 08 Jun 2017 12:20:55 -0000 Subject: [Openstack-security] [Bug 1516703] Re: crypto.py generates certs with SHA-1 digest References: <20151116164718.17403.87965.malonedeb@gac.canonical.com> Message-ID: <149692445590.2359.3853263011173880067.launchpad@chaenomeles.canonical.com> ** Tags added: windows -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1516703 Title: crypto.py generates certs with SHA-1 digest Status in OpenStack Compute (nova): New Bug description: nova/crypto.py:generate_winrm_x509_cert() generates certs with default SHA-1 digest. The call to 'openssl req' does not specify -digest option nor certificate config file sets digest, so certificates are generated with SHA-1 digest. SHA-1 is not considered to be a secure algorithm for certificates' digest. It would be preferable to: 1) let user specify digest algorithm via a config option 2) default to SHA-256 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1516703/+subscriptions From fungi at yuggoth.org Thu Jun 8 14:01:20 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 08 Jun 2017 14:01:20 -0000 Subject: [Openstack-security] [Bug 1686743] Re: Ceph credentials included in logs using older libvirt/qemu References: <20170427142747.26531.54657.malonedeb@gac.canonical.com> Message-ID: <149693048009.9950.10993700052247734016.malone@wampee.canonical.com> Triaged as class C2 (a vulnerability, but not in OpenStack supported code, e.g., in a dependency; won't fix OSSA; potential OSSN) based on prior discussion in this bug report. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public ** Tags added: security ** 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/1686743 Title: Ceph credentials included in logs using older libvirt/qemu Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New 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. Older versions of libvirt included network storage authentication information on the qemu command line. If libvirt raises an exception which logs the qemu command line it used, for example an error starting a domain, this authentication information will end up in the logs. There is an existing CVE for this issue here:   https://access.redhat.com/security/cve/CVE-2015-5160 Specifically, if a deployment is using ceph, a libvirt error starting a domain would log the cephx secret key and the monitor addresses on the qemu command line. The issue has been resolved upstream. Users running qemu version 2.6 or later, and libvirt version 2.2 or later, are not vulnerable. No change is required in Nova to resolve this issue. Red Hat users running RHEL 7.3 or later are not vulnerable. It's not 100% clear to me that an OpenStack CVE is required here as it's not a bug in an OpenStack component, and it's already fixed upstream. However, it did come to my attention after a user publicly posted their ceph credentials on IRC, so evidently some OpenStack users are running vulnerable systems, and this is a very common configuration. In Nova, we currently have: MIN_LIBVIRT_VERSION = (1, 2, 9) MIN_QEMU_VERSION = (2, 1, 0) so anybody running the minimum supported versions will be vulnerable. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1686743/+subscriptions From 1668503 at bugs.launchpad.net Thu Jun 8 21:53:55 2017 From: 1668503 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 08 Jun 2017 21:53:55 -0000 Subject: [Openstack-security] [Bug 1668503] Fix included in openstack/keystone 12.0.0.0b2 References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <149695883517.2645.6677824782574605759.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/keystone 12.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Incomplete Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From 1543048 at bugs.launchpad.net Thu Jun 8 21:53:53 2017 From: 1543048 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 08 Jun 2017 21:53:53 -0000 Subject: [Openstack-security] [Bug 1543048] Fix included in openstack/keystone 12.0.0.0b2 References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <149695883341.20211.607655291701165442.malone@soybean.canonical.com> This issue was fixed in the openstack/keystone 12.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): Fix Released Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From lbragstad at gmail.com Fri Jun 9 19:43:47 2017 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 09 Jun 2017 19:43:47 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <149703742944.9724.1341439049552791543.launchpad@wampee.canonical.com> ** Changed in: keystone/pike Milestone: None => pike-2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Incomplete Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From 1686110 at bugs.launchpad.net Mon Jun 12 13:36:22 2017 From: 1686110 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 12 Jun 2017 13:36:22 -0000 Subject: [Openstack-security] [Bug 1686110] Fix included in openstack/openstack-ansible-security 15.1.5 References: <20170425143229.16670.26982.malonedeb@wampee.canonical.com> Message-ID: <149727458233.19571.8714570545332369999.malone@soybean.canonical.com> This issue was fixed in the openstack/openstack-ansible-security 15.1.5 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1686110 Title: AIDE configuration is set AFTER the initial run Status in openstack-ansible: Fix Released Bug description: The "Configure AIDE to verify additional properties" task runs *after* the tasks which do the AIDE initialization. This isn't a problem on CentOS since the default properties meet the STIG requirements, but it does affect Ubuntu. The result is that Ubuntu users may see a huge AIDE update upon their second AIDE run. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1686110/+subscriptions From sean at dague.net Wed Jun 14 11:09:21 2017 From: sean at dague.net (Sean Dague) Date: Wed, 14 Jun 2017 11:09:21 -0000 Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens a DOS on compute hosts References: <20151001152652.22834.78736.malonedeb@gac.canonical.com> Message-ID: <149743856086.25293.7274816050922690946.malone@soybean.canonical.com> This is really a design decision, it's not really clear that changing the expected behavior here is going to provide a good experience for operators. We punt on various classes of potential DOS (like api rate limiting). ** Changed in: nova Status: In Progress => Won't Fix ** Changed in: nova Importance: High => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1501808 Title: Enabling soft-deletes opens a DOS on compute hosts Status in OpenStack Compute (nova): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: If the user sets reclaim_instance_interval to anything other than 0, then when a user requests an instance delete, it will instead be soft deleted. Soft delete explicitly releases the user's quota, but does not release the instance's resources until period task _reclaim_queued_deletes runs with a period of reclaim_instance_interval seconds. A malicious authenticated user can repeatedly create and delete instances without limit, which will consume resources on the host without consuming their quota. If done quickly enough, this will exhaust host resources. I'm not entirely sure what to suggest in remediation, as this seems to be a deliberate design. The most obvious fix would be to not release quota until the instance is reaped, but that would be a significant change in behaviour. This is very similar to https://bugs.launchpad.net/bugs/cve/2015-3280 , except that we do it deliberately. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1501808/+subscriptions From sean at dague.net Wed Jun 14 15:28:29 2017 From: sean at dague.net (Sean Dague) Date: Wed, 14 Jun 2017 15:28:29 -0000 Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring potential security issue References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com> Message-ID: <149745410894.8991.6532305753617617689.malone@wampee.canonical.com> There is really very low exposure here ** Changed in: nova Status: Confirmed => Opinion -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246160 Title: shuffle method bring potential security issue Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Invalid Bug description: In the /nova/utils.py, line 328, the source code is below r.shuffle(password) This code is using shuffle method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246160/+subscriptions From 1575913 at bugs.launchpad.net Fri Jun 16 09:00:14 2017 From: 1575913 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 16 Jun 2017 09:00:14 -0000 Subject: [Openstack-security] [Bug 1575913] Re: Generate and download keypair GET endpoint allows CSRF attacks References: <20160427202224.17621.97555.malonedeb@soybean.canonical.com> Message-ID: <149760361475.2938.381438482212970062.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/367629 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=d07fedc45f91449787d939a5bf4cc00a0d100652 Submitter: Jenkins Branch: master commit d07fedc45f91449787d939a5bf4cc00a0d100652 Author: Matt Borland Date: Thu Sep 8 14:50:23 2016 -0600 Use POST not GET for keypair generation This patch fixes the Cross-Site Request Forgery (CSRF) attack against the keypair generation pages: - HORIZON_URL/project/key_pairs/PAIRNAME/generate/ - HORIZON_URL/project/key_pairs/PAIRNAME/download/ These pages exposed creating and/or overwriting a keypair with a given name via a CSRF attack. This patch closes these holes by using only POST-based keypair creation, and exposing the keypair in the contents of a modal dialog instead of a download, which ultimately requires a GET. It uses the same client-side features for both the Launch Instance keypair creation and Compute / Key Pairs panel. Closes-Bug: 1575913 Change-Id: Ie5ca28ff2bd806eb1481eba6f419b797b68856b6 ** Changed in: horizon 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/1575913 Title: Generate and download keypair GET endpoint allows CSRF attacks Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Requests to create (and download) nova keypairs are made as GETs. As such the CSRF token is not sent nor validated on these requests. This breaks the principle Django's CSRF middleware relies upon which is that requests with side effects should not cause side effects. I'm told there was a reason for doing this related to being able to send the data back to the browser, and that this may not be trivial to fix. Filing this as a security bug since a malicious site could fool a user into creating keypairs. The attacker would not gain access to the contents, so the impact is not as serious as it might seem at first glance. See https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions From sean at dague.net Fri Jun 23 16:29:35 2017 From: sean at dague.net (Sean Dague) Date: Fri, 23 Jun 2017 16:29:35 -0000 Subject: [Openstack-security] [Bug 1563954] Re: use_forwarded_for exposes metadata References: <20160330160317.3139.18707.malonedeb@chaenomeles.canonical.com> Message-ID: <149823537786.29158.9051014463455618135.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: Tony Breeds (o-tony) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1563954 Title: use_forwarded_for exposes metadata Status in OpenStack Compute (nova): Confirmed Status in OpenStack Security Advisory: Opinion Status in OpenStack Security Notes: Fix Released Bug description: The nova metadata service uses the remote address to determine which metadata to retrieve. In order to work behind a proxy there is an option use_forwarded_for which will use the X-Forwarded-For header to determine the remote IP. If this option is set then anyone who can access the metadata port can request metadata for any instance if they know the IP. The user data is also exposed. $ echo 123456 > /tmp/data $ openstack server create --image CentOS7 --flavor fedora --user-data /tmp/data test $ curl -H 'X-Forwarded-For: 10.0.0.7' http://localhost:8775/latest/user-data/ 123456 At a minimum this side-effect isn't documented anywhere I could find. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1563954/+subscriptions From sean at dague.net Tue Jun 27 15:55:08 2017 From: sean at dague.net (Sean Dague) Date: Tue, 27 Jun 2017 15:55:08 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <149857890842.21782.6578498653333849557.malone@soybean.canonical.com> Automatically discovered version havana in description. If this is incorrect, please update the description to include 'nova version: ...' ** Tags added: openstack-version.havana -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1419577 Title: when live-migrate failed, lun-id couldn't be rollback in havana Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Hi, guys When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback. and failed VM can have others volume. my test environment is following : Openstack Version : Havana ( 2013.2.3) Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 1 cinder volume (vol01) 4) attach 1 volume to vm01 (/dev/vdb) 5) live-migrate vm01 from host#1 to host#2 6) live-migrate success      - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.        and the status of devices is "failed faulty"      - please check the lun-id of vol01 7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4) 8) live-migrate fail      - please check the mapper in host#1      - please check the lun-id of vol01, then you can find the lun hav "two" igroups      - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback This Bug is critical security issue because the failed VM can have others volume. and every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. I suggest below methods to solve issue : 1) when live-migrate is complete, nova should delete mapper devices at origin host 2) when live-migrate is failed, nova should rollback lun-id in connection_info column 3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...) 4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping please check this bug. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions From fungi at yuggoth.org Tue Jun 27 16:45:42 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Jun 2017 16:45:42 -0000 Subject: [Openstack-security] [Bug 1700501] Re: Insecure rootwrap usage References: <149847400077.21285.859787175293982985.malonedeb@soybean.canonical.com> Message-ID: <149858194252.29005.182362973298252920.malone@wampee.canonical.com> In a private E-mail reply, Benjamin agreed with the suggestion to proceed with this report in public for now. As such, I'm triaging it as class B2 ("a vulnerability without a complete fix yet, security note for all versions, e.g., poor architecture / design"). The security note normally suggested by B2 is probably not warranted either given the existing treatment in the security guide, linked from the initial report. ** Information type changed from Private Security to Public ** 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. - - -- - Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow ** 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/1700501 Title: Insecure rootwrap usage Status in Cinder: New Status in Manila: New Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Incomplete Bug description: Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions From fungi at yuggoth.org Tue Jun 27 18:43:27 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Jun 2017 18:43:27 -0000 Subject: [Openstack-security] [Bug 1700501] Re: Insecure rootwrap usage References: <149847400077.21285.859787175293982985.malonedeb@soybean.canonical.com> Message-ID: <149858900947.3243.9816399799749786687.launchpad@chaenomeles.canonical.com> ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1700501 Title: Insecure rootwrap usage Status in Cinder: New Status in Manila: New Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Bug description: Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions From sean at dague.net Wed Jun 28 10:33:04 2017 From: sean at dague.net (Sean Dague) Date: Wed, 28 Jun 2017 10:33:04 -0000 Subject: [Openstack-security] [Bug 1700501] Re: Insecure rootwrap usage References: <149847400077.21285.859787175293982985.malonedeb@soybean.canonical.com> Message-ID: <149864598413.3407.18425649460933242016.malone@gac.canonical.com> This is too vague to be actionable. There is one example, and it's not clear where in the system the concern is. And the kinds of changes to make this be as restricted as one would like really don't lead well to a bug, but would require a more systematic push to really embrace something like privsep. In general, the use of root wrap on nova-compute is honestly pointless in my pov. Besides chmod, cat, dd and a few others are running more or less unrestricted. It just doesn't make for a useful security model. ** Changed in: nova Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1700501 Title: Insecure rootwrap usage Status in Cinder: New Status in Manila: New Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Won't Fix Bug description: Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions From sean at dague.net Wed Jun 28 12:10:50 2017 From: sean at dague.net (Sean Dague) Date: Wed, 28 Jun 2017 12:10: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: <149865185383.3553.12958547860538177665.launchpad@gac.canonical.com> ** Changed in: nova 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/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix 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 mikal at stillhq.com Wed Jun 28 12:43:21 2017 From: mikal at stillhq.com (Michael Still) Date: Wed, 28 Jun 2017 12:43:21 -0000 Subject: [Openstack-security] [Bug 1700501] Re: Insecure rootwrap usage References: <149847400077.21285.859787175293982985.malonedeb@soybean.canonical.com> <149864598413.3407.18425649460933242016.malone@gac.canonical.com> Message-ID: Well, there is proposed code is up to start moving to privsep, but it's not a priority right now... Michael On 28 Jun. 2017 8:41 pm, "Sean Dague" wrote: > This is too vague to be actionable. There is one example, and it's not > clear where in the system the concern is. And the kinds of changes to > make this be as restricted as one would like really don't lead well to a > bug, but would require a more systematic push to really embrace > something like privsep. > > In general, the use of root wrap on nova-compute is honestly pointless > in my pov. Besides chmod, cat, dd and a few others are running more or > less unrestricted. It just doesn't make for a useful security model. > > ** Changed in: nova > Status: New => Incomplete > > -- > You received this bug notification because you are a member of Nova Core > security contacts, which is subscribed to the bug report. > https://bugs.launchpad.net/bugs/1700501 > > Title: > Insecure rootwrap usage > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions > -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1700501 Title: Insecure rootwrap usage Status in Cinder: New Status in Manila: New Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Won't Fix Bug description: Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions From sean at dague.net Wed Jun 28 16:13:22 2017 From: sean at dague.net (Sean Dague) Date: Wed, 28 Jun 2017 16:13:22 -0000 Subject: [Openstack-security] [Bug 1516703] Re: crypto.py generates certs with SHA-1 digest References: <20151116164718.17403.87965.malonedeb@gac.canonical.com> Message-ID: <149866640448.26234.7159351335776744930.launchpad@gac.canonical.com> ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1516703 Title: crypto.py generates certs with SHA-1 digest Status in OpenStack Compute (nova): Confirmed Bug description: nova/crypto.py:generate_winrm_x509_cert() generates certs with default SHA-1 digest. The call to 'openssl req' does not specify -digest option nor certificate config file sets digest, so certificates are generated with SHA-1 digest. SHA-1 is not considered to be a secure algorithm for certificates' digest. It would be preferable to: 1) let user specify digest algorithm via a config option 2) default to SHA-256 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1516703/+subscriptions From sean at dague.net Thu Jun 29 11:47:18 2017 From: sean at dague.net (Sean Dague) Date: Thu, 29 Jun 2017 11:47:18 -0000 Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens a DOS on compute hosts References: <20151001152652.22834.78736.malonedeb@gac.canonical.com> Message-ID: <149873683824.6469.8936081158393532950.malone@gac.canonical.com> Found open reviews for this bug in gerrit, setting to In Progress. review: https://review.openstack.org/386756 in branch: master review: https://review.openstack.org/407877 in branch: master ** Changed in: nova Status: Won't Fix => In Progress ** Changed in: nova Assignee: Matt Riedemann (mriedem) => Chris Martin (cm876n) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1501808 Title: Enabling soft-deletes opens a DOS on compute hosts Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: If the user sets reclaim_instance_interval to anything other than 0, then when a user requests an instance delete, it will instead be soft deleted. Soft delete explicitly releases the user's quota, but does not release the instance's resources until period task _reclaim_queued_deletes runs with a period of reclaim_instance_interval seconds. A malicious authenticated user can repeatedly create and delete instances without limit, which will consume resources on the host without consuming their quota. If done quickly enough, this will exhaust host resources. I'm not entirely sure what to suggest in remediation, as this seems to be a deliberate design. The most obvious fix would be to not release quota until the instance is reaped, but that would be a significant change in behaviour. This is very similar to https://bugs.launchpad.net/bugs/cve/2015-3280 , except that we do it deliberately. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1501808/+subscriptions From 1685678 at bugs.launchpad.net Fri Jun 30 16:07:24 2017 From: 1685678 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 30 Jun 2017 16:07:24 -0000 Subject: [Openstack-security] [Bug 1685678] Re: swap volume operation may leak credentials into debug logs References: <20170424003200.1328.91704.malonedeb@gac.canonical.com> Message-ID: <149883884582.26100.10355179860637540188.launchpad@chaenomeles.canonical.com> ** Changed in: nova Assignee: Matt Riedemann (mriedem) => Dane Fichter (dane-fichter) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1685678 Title: swap volume operation may leak credentials into debug logs Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: The swap volume code in the compute service logs old and new volume connection_info dicts to debug here: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930 The new connection_info comes from Cinder: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901 That's a plain dict from the response which may contain credentials. The old connection_info comes from the nova.objects.block_device.BlockDeviceMapping object, which uses SensitiveStringField to sanitize the field's value when logged: https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904 https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280 The new connection_info could contain credentials though, so we should mask those when logging it, even at debug level. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1685678/+subscriptions