From gerrit2 at review.openstack.org Tue Jul 1 05:42:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 01 Jul 2014 05:42:39 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/103736 Log: commit 2f1d9c644757f7b3b3e2843d1d2a5a46a5fe3682 Author: guang-yee Date: Mon Jun 30 22:38:50 2014 -0700 X.509 SSL certificate authentication plugin Add a plugin for X.509 SSL certification authentication. This is similar to Kerberos auth plugin. It must be used in conjunction with Apache mod_ssl. This is still a WIP patch. Need documentation and unit tests. I've tested in Apache and the basics seem to be working fine. DocImpact SecurityImpact Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 From 1320056 at bugs.launchpad.net Tue Jul 1 10:14:47 2014 From: 1320056 at bugs.launchpad.net (Robert Clark) Date: Tue, 01 Jul 2014 10:14:47 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140701101448.7989.37356.malone@wampee.canonical.com> OSSN issued, congratulations Tim! https://wiki.openstack.org/wiki/OSSN/OSSN-0019 ** Changed in: ossn Importance: Undecided => High ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From 1316271 at bugs.launchpad.net Tue Jul 1 10:15:36 2014 From: 1316271 at bugs.launchpad.net (Robert Clark) Date: Tue, 01 Jul 2014 10:15:36 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140701101536.2663.67947.malone@chaenomeles.canonical.com> OSSN Published, congratulations Stan! https://wiki.openstack.org/wiki/OSSN/OSSN-0018 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From 1316271 at bugs.launchpad.net Tue Jul 1 12:09:20 2014 From: 1316271 at bugs.launchpad.net (David Hill) Date: Tue, 01 Jul 2014 12:09:20 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140701120921.2245.30156.malone@chaenomeles.canonical.com> Fixing this bug by binding all services to a specific IP adress can be teadious ... Since we're talking about automating everything, I would sugggest to adress this issue by filtering it instead. Otherwise, each operator will have to end with its own set off solutions in order to secure their network. Ie: NFS, ssh, xinetd (inetd), ftp, etc -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From 1320028 at bugs.launchpad.net Tue Jul 1 19:14:36 2014 From: 1320028 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 01 Jul 2014 19:14:36 -0000 Subject: [Openstack-security] [Bug 1320028] Fix proposed to nova (master) References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140701191436.2663.78273.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/103974 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From shohel_csdu at yahoo.com Wed Jul 2 08:16:16 2014 From: shohel_csdu at yahoo.com (Shohel Ahmed) Date: Wed, 2 Jul 2014 01:16:16 -0700 Subject: [Openstack-security] Fw: [openstack-dev] [Keystone] [Swift] Question re. keystone domains In-Reply-To: References: Message-ID: <1404288976.30652.YahooMailNeo@web164804.mail.gq1.yahoo.com> Bringing this to OSSG attention.  The second one seems a security critical assumption. Without input/output validation in keystone/Swift for domain_id or good documentation in place, this assumption can be exploited later on by some attacker to break Swift. ...shohel On Tuesday, July 1, 2014 10:19 PM, Dolph Mathews wrote: On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair wrote: We have a change [1] under review in Swift to make access control lists compatible with migration to keystone v3 domains. The change makes two assumptions that I’d like to double-check with keystone folks: >  >1.      That a project can never move from one domain to another. We're moving in this direction, at least. In Grizzly and Havana, we made no such restriction. In Icehouse, we introduced such a restriction by default, but it can be disabled. So far, we haven't gotten any complaints about adding the restriction, so maybe we should just add additional help text to the option in our config about why you would never want to disable the restriction, citing how it would break swift? 2.      That the underscore character cannot appear in a valid domain id – more specifically, that the string ‘_unknown’ cannot be confused with a domain id. That's fairly sound. All of our domain ID's are system-assigned as UUIDs, except for the "default" domain which has an explicit id='default'. We don't do anything to validate the assumption, though.   >Are those safe assumptions? >  >Thanks, >Alistair >  >[1] https://review.openstack.org/86430 >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Wed Jul 2 09:14:13 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 2 Jul 2014 09:14:13 +0000 Subject: [Openstack-security] [OSSG] Meetup. Message-ID: All. Please confirm that you will be attending the OSSG meetup by updating the etherpad below https://etherpad.openstack.org/p/ossg-juno-meetup Cheers -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From matt at nycresistor.com Wed Jul 2 09:25:48 2014 From: matt at nycresistor.com (matt) Date: Wed, 2 Jul 2014 05:25:48 -0400 Subject: [Openstack-security] [OSSG] Meetup. In-Reply-To: References: Message-ID: I won't make it. But if anyone is at toorcamp the week before... hunt me down. -matt On Wed, Jul 2, 2014 at 5:14 AM, Clark, Robert Graham wrote: > All. > > Please confirm that you will be attending the OSSG meetup by updating > the etherpad below > > https://etherpad.openstack.org/p/ossg-juno-meetup > > Cheers > -Rob > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.chivers at hp.com Wed Jul 2 09:48:18 2014 From: doug.chivers at hp.com (Chivers, Douglas) Date: Wed, 2 Jul 2014 09:48:18 +0000 Subject: [Openstack-security] [OSSG] Meetup. In-Reply-To: References: Message-ID: <78669F4C-A707-473D-BB0F-B20EDE50CB5D@hp.com> Sore point Sent from my iPhone > On 2 Jul 2014, at 10:19, "Clark, Robert Graham" wrote: > > All. > > Please confirm that you will be attending the OSSG meetup by updating > the etherpad below > > https://etherpad.openstack.org/p/ossg-juno-meetup > > Cheers > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From fungi at yuggoth.org Wed Jul 2 10:56:17 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 02 Jul 2014 10:56:17 -0000 Subject: [Openstack-security] [Bug 1336225] Re: Password is exposed in the log file References: <20140701103304.7888.77002.malonedeb@wampee.canonical.com> Message-ID: <20140702105617.23780.6919.malone@soybean.canonical.com> Removing the advisory task and tagging this as a security hardening/strengthening measure. ** Information type changed from Public Security to Public ** Tags added: security ** No longer affects: ossa -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1336225 Title: Password is exposed in the log file Status in Orchestration API (Heat): In Progress Bug description: heat-keystone-setup-domain is logging the password to the log file. This defect is filed to remove the logging statement as its security concerns To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1336225/+subscriptions From 1320028 at bugs.launchpad.net Wed Jul 2 13:03:26 2014 From: 1320028 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 02 Jul 2014 13:03:26 -0000 Subject: [Openstack-security] [Bug 1320028] Change abandoned on nova (master) References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140702130326.2318.92205.malone@chaenomeles.canonical.com> Change abandoned by Brad Pokorny (bpokorny at linux.vnet.ibm.com) on branch: master Review: https://review.openstack.org/103974 Reason: Abandoning this one due to Sean's review. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From nkinder at redhat.com Wed Jul 2 15:17:17 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 02 Jul 2014 08:17:17 -0700 Subject: [Openstack-security] Fw: [openstack-dev] [Keystone] [Swift] Question re. keystone domains In-Reply-To: <1404288976.30652.YahooMailNeo@web164804.mail.gq1.yahoo.com> References: <1404288976.30652.YahooMailNeo@web164804.mail.gq1.yahoo.com> Message-ID: <53B4227D.2000600@redhat.com> On 07/02/2014 01:16 AM, Shohel Ahmed wrote: > Bringing this to OSSG attention. > > The second one seems a security critical assumption. Without > input/output validation in keystone/Swift for domain_id or good > documentation in place, this assumption can be exploited later on by > some attacker to break Swift. Yeah, I'm a bit concerned as well. Making assumptions about the domain names that are allowed is bad. If there is a need for a special string that can't be used for a valid domain, Keystone should enforce that restriction. That said, I haven't looked at the proposed Swift changes in detail yet to fully understand the approach. -NGK > > ...shohel > > > > > On Tuesday, July 1, 2014 10:19 PM, Dolph Mathews > wrote: > > On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair > wrote: > > We have a change [1] under review in Swift to make access control > lists compatible with migration to keystone v3 domains. The change > makes two assumptions that I’d like to double-check with keystone > folks:____ > __ __ > __1. __That a project can never move from one domain to another. > > We're moving in this direction, at least. In Grizzly and Havana, we made > no such restriction. In Icehouse, we introduced such a restriction by > default, but it can be disabled. So far, we haven't gotten any > complaints about adding the restriction, so maybe we should just add > additional help text to the option in our config about why you would > never want to disable the restriction, citing how it would break swift? > > ____ > __2. __That the underscore character cannot appear in a valid > domain id – more specifically, that the string ‘_unknown’ cannot be > confused with a domain id. > > That's fairly sound. All of our domain ID's are system-assigned as > UUIDs, except for the "default" domain which has an explicit > id='default'. We don't do anything to validate the assumption, though. > > > > > > > ____ > __ __ > Are those safe assumptions?____ > __ __ > Thanks,____ > Alistair____ > __ __ > [1] https://review.openstack.org/86430____ > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From robert.clark at hp.com Wed Jul 2 18:14:46 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 2 Jul 2014 18:14:46 +0000 Subject: [Openstack-security] Fw: [openstack-dev] [Keystone] [Swift] Question re. keystone domains In-Reply-To: <53B4227D.2000600@redhat.com> References: <1404288976.30652.YahooMailNeo@web164804.mail.gq1.yahoo.com> <53B4227D.2000600@redhat.com> Message-ID: It's ugly from a design point of view, unless Keystone had some call that Swift could make to _verify_ what is, or isn't restricted - which would decouple the security assumption somewhat but introduce more complexity into Keystone of course. ^ Not suggesting that's sensible but better than just hoping/assuming Keystone is configured the way you expect it to be. -Rob > -----Original Message----- > From: Nathan Kinder [mailto:nkinder at redhat.com] > Sent: 02 July 2014 16:17 > To: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] Fw: [openstack-dev] [Keystone] [Swift] > Question re. keystone domains > > > > On 07/02/2014 01:16 AM, Shohel Ahmed wrote: > > Bringing this to OSSG attention. > > > > The second one seems a security critical assumption. Without > > input/output validation in keystone/Swift for domain_id or good > > documentation in place, this assumption can be exploited later on by > > some attacker to break Swift. > > Yeah, I'm a bit concerned as well. Making assumptions about the domain > names that are allowed is bad. If there is a need for a special string that > can't be used for a valid domain, Keystone should enforce that restriction. > That said, I haven't looked at the proposed Swift changes in detail yet to > fully understand the approach. > > -NGK > > > > > ...shohel > > > > > > > > > > On Tuesday, July 1, 2014 10:19 PM, Dolph Mathews > > wrote: > > > > On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair > > > wrote: > > > > We have a change [1] under review in Swift to make access control > > lists compatible with migration to keystone v3 domains. The change > > makes two assumptions that I'd like to double-check with keystone > > folks:____ > > __ __ > > __1. __That a project can never move from one domain to another. > > > > We're moving in this direction, at least. In Grizzly and Havana, we > > made no such restriction. In Icehouse, we introduced such a > > restriction by default, but it can be disabled. So far, we haven't > > gotten any complaints about adding the restriction, so maybe we should > > just add additional help text to the option in our config about why > > you would never want to disable the restriction, citing how it would break > swift? > > > > ____ > > __2. __That the underscore character cannot appear in a valid > > domain id - more specifically, that the string '_unknown' cannot be > > confused with a domain id. > > > > That's fairly sound. All of our domain ID's are system-assigned as > > UUIDs, except for the "default" domain which has an explicit > > id='default'. We don't do anything to validate the assumption, though. > > > > > > > > > > > > > > ____ > > __ __ > > Are those safe assumptions?____ > > __ __ > > Thanks,____ > > Alistair____ > > __ __ > > [1] https://review.openstack.org/86430____ > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev at lists.openstack.org > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev at lists.openstack.org > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From jason.hullinger at hp.com Wed Jul 2 18:58:25 2014 From: jason.hullinger at hp.com (Hullinger, Jason (Cloud Services)) Date: Wed, 2 Jul 2014 18:58:25 +0000 Subject: [Openstack-security] [OSSG] Meetup. Message-ID: FYI, I'm not sure if there is another event in Seattle that week or if it's just summer time tourism, but I booked travel this morning and found that a lot of hotels are sold out, including the Westin. People might want to make travel arrangements sooner than later if possible. On 7/2/14, 2:14 AM, "Clark, Robert Graham" wrote: >All. > >Please confirm that you will be attending the OSSG meetup by updating >the etherpad below > >https://etherpad.openstack.org/p/ossg-juno-meetup > >Cheers >-Rob > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From sriram at sriramhere.com Thu Jul 3 00:04:10 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Wed, 2 Jul 2014 17:04:10 -0700 Subject: [Openstack-security] Congrats Rob! Message-ID: Dear OSSG, Big round of applause to our Rob, who has been promoted to Distinguished Technologist at HP. I came to know of just now through LI, hopefully not an old news! Congrats Rob! -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at windisch.us Thu Jul 3 00:44:40 2014 From: eric at windisch.us (Eric Windisch) Date: Wed, 2 Jul 2014 20:44:40 -0400 Subject: [Openstack-security] Congrats Rob! In-Reply-To: References: Message-ID: Congrats Rob! Well deserved. On Jul 2, 2014 8:07 PM, "Sriram Subramanian" wrote: > Dear OSSG, > > Big round of applause to our Rob, who has been promoted to Distinguished > Technologist at HP. I came to know of just now through LI, hopefully not an > old news! > > Congrats Rob! > > -- > Thanks, > -Sriram > 425-610-8465 > www.sriramhere.com | www.clouddon.com > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Thu Jul 3 16:13:21 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 3 Jul 2014 09:13:21 -0700 Subject: [Openstack-security] Today's meetup Message-ID: Team - I will be missing today's IRC meeting:( Apart from finalizing social event during the Seattle meetup, I don't have any action item. I will watch for any other action items in the logs. FYI: The GSOC intern working on the Fuzz testing framework didn't pass the mid term evaluation, unfortunately. We can transfer the work done so far to anyone (Mark?) to pickup. Please email me offline if you need more details regarding the same. -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1175905 at bugs.launchpad.net Thu Jul 3 17:21:47 2014 From: 1175905 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 03 Jul 2014 17:21:47 -0000 Subject: [Openstack-security] [Bug 1175905] Change abandoned on keystone (master) References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140703172147.10276.49569.malone@soybean.canonical.com> Change abandoned by Morgan Fainberg (morgan.fainberg at gmail.com) on branch: master Review: https://review.openstack.org/98296 Reason: Based upon discussions with David Stanek, This should just be setting a max in oslo.config which is waiting for a fix to be released. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): Triaged Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From morgan.fainberg at gmail.com Thu Jul 3 17:21:54 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 03 Jul 2014 17:21:54 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140703172156.9557.78449.launchpad@wampee.canonical.com> ** Changed in: keystone Status: In Progress => Triaged ** Changed in: keystone Assignee: Morgan Fainberg (mdrnstm) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): Triaged Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From gerrit2 at review.openstack.org Thu Jul 3 20:24:50 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 03 Jul 2014 20:24:50 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit c845fce9394384bacf1200cefc02d9e52b7f8e48 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From thierry.carrez+lp at gmail.com Mon Jul 7 14:21:39 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 07 Jul 2014 14:21:39 -0000 Subject: [Openstack-security] [Bug 1335208] Re: Shell injection possibility in cmd/control.py References: <20140627163123.19133.62950.malonedeb@gac.canonical.com> Message-ID: <20140707142141.10184.28171.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Invalid ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1335208 Title: Shell injection possibility in cmd/control.py Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Advisories: Invalid Bug description: The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. This may not be a major security concern at this time because the only place that I found for 'server' to come from is a Glance configuration file, which should be locked down. Only privileged users should have write access to the config file, and if they want to do bad things on the system there are easier ways. Still, 'shell=True' appears to be completely unnecessary for this call. Simply omitting the shell parameter here will cause it to revert to the default behavior, which requires that the command to be run be specified in a separate parameter than the arguments to the command. This effectively prevents shell injection vulnerabilities. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1335208/+subscriptions From 1334926 at bugs.launchpad.net Mon Jul 7 15:01:14 2014 From: 1334926 at bugs.launchpad.net (Kyle Mestery) Date: Mon, 07 Jul 2014 15:01:14 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140707150117.29518.51013.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From michael.xin at RACKSPACE.COM Mon Jul 7 16:36:14 2014 From: michael.xin at RACKSPACE.COM (Michael Xin) Date: Mon, 7 Jul 2014 16:36:14 +0000 Subject: [Openstack-security] [OSSG] Meetup. In-Reply-To: References: Message-ID: Sorry that I will not be able to make it. Enjoy it. Thanks and have a great day. Yours, Michael ----------------------------------------------------------------------------- Michael Xin | Software Security Developer IV Product Security |Rackspace Hosting Office #: 501-7341 or 210-312-7341 Mobile #: 210-284-8674 5000 Walzem Road, San Antonio, Tx 78218 ---------------------------------------------------------------------------- Experience fanatical support From: matt > Date: Wednesday, July 2, 2014 at 4:25 AM To: "Clark, Robert Graham" > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] [OSSG] Meetup. I won't make it. But if anyone is at toorcamp the week before... hunt me down. -matt On Wed, Jul 2, 2014 at 5:14 AM, Clark, Robert Graham > wrote: All. Please confirm that you will be attending the OSSG meetup by updating the etherpad below https://etherpad.openstack.org/p/ossg-juno-meetup Cheers -Rob _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Jul 7 19:11:49 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 07 Jul 2014 19:11:49 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140707191149.26824.88010.malone@gac.canonical.com> After discussing with Andrew and Thierry, I'm convinced that the potential behavior change introduced by a backport of that mitigating commit, when weighed against the amount of social engineering needed to exploit this in Havana, means this bug is probably better just documented as a known behavior. Removed the advisory task and tagged security in case the OSSG has any interest in documenting this. ** Tags added: security ** Information type changed from Public Security to Public ** No longer affects: ossa -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From nkinder at redhat.com Tue Jul 8 05:01:09 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 08 Jul 2014 05:01:09 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140708050109.29518.48645.launchpad@chaenomeles.canonical.com> ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: New Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From gerrit2 at review.openstack.org Tue Jul 8 07:21:21 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 08 Jul 2014 07:21:21 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/103736 Log: commit 6bb86fe7971f250163395d450ccac06f7bafa789 Author: guang-yee Date: Mon Jun 30 22:38:50 2014 -0700 X.509 SSL certificate authentication plugin Add a plugin for X.509 SSL certification authentication. This is similar to Kerberos auth plugin. It must be used in conjunction with Apache mod_ssl. DocImpact SecurityImpact Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 From tristan.cacqueray at enovance.com Tue Jul 8 15:00:55 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 08 Jul 2014 15:00:55 -0000 Subject: [Openstack-security] [Bug 1308727] Re: XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140708150056.29385.8431.launchpad@chaenomeles.canonical.com> ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From noloader at gmail.com Tue Jul 8 15:28:16 2014 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 8 Jul 2014 11:28:16 -0400 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 In-Reply-To: References: Message-ID: >From tests/apache_fixtures.py: > 'SSL_CLIENT_S_DN': ('CN=localhost,emailAddress=keystone at openstack.org,'70 > 'OU=Keystone,O=OpenStack,L=Sunnyvale,ST=CA,C=US'),71 > 'SSL_CLIENT_I_DN': ('CN=Self Signed,emailAddress=keystone at openstack.org,'72 > 'OU=Keystone,O=OpenStack,L=Sunnyvale,ST=CA,C=US,'73 > 'serialNumber=5'), SSL_CLIENT_S_DN appears to be Subject Distinguished Name. A hostname in the Common Name (CN) (i.e., CN=localhost) is deprecated by both the IETF and the CA/Browser Forums [1,2]. Most CAs in the wild follow the CA/Browser Forums, and *not* the IETF. (And which standard libraries use is a whole 'nother debate). It would probably be a good idea to have a couple of test cases that place the hostname in the Subject Alt Name (SAN), and not the Common Name (CN). Both the IETF and CA/B want the hostname there. Also, a negative test case to consider uses a hostname of (1) "*.com", and (2) "*.uk.com". (1) is a wildcarded gTLD, and (2) is a wildcarded ccTLD. Both should probably be rejected because they claim perview over the entire top level domain. Intuitively, we know this is not possible. Additioanlly, its prohibited CA/B Baseline Requirements (which most CAs issue against). A final negative test case with hostname tricks would be (1) "keystone.*.com", and (2) "keystone.*.uk.com". In this test case, the asterisk is *not* in the leftmost label. This suffers the same basic fault of the previous test case. And its a violation of the CA/B BR. I know how Python, PERL, OpenSSL, .Net, Cocoa/CocoaTouch, Ruby, etc responds to the negative test cases. For the first test case, ("*.com", and "*.uk.com"), OpenStack will probably need an additional security control because Python does not handle it correctly. If its OpenSSL based, then *no* hostname matching currently occurs, so OpenStack will need to implement it (or find a library with it). What I'm not clear on: how does Apache respond to them (because I've never programmed Apache). (Sorry to post to the list. I recently learned Gerrit was not saving most of my comments. I want to ensure this is documented). Jeff [1] RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, http://www.ietf.org/rfc/rfc5280.txt. [2] RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS), http://www.ietf.org/rfc/rfc6125.txt. [3] CA/Broswer Forums Baseline Requirements Documents, https://cabforum.org/baseline-requirements-documents/. On Tue, Jul 8, 2014 at 3:21 AM, wrote: > > Hi, I'd like you to take a look at this patch for potential > SecurityImpact. > https://review.openstack.org/103736 > > Log: > commit 6bb86fe7971f250163395d450ccac06f7bafa789 > Author: guang-yee > Date: Mon Jun 30 22:38:50 2014 -0700 > > X.509 SSL certificate authentication plugin > > Add a plugin for X.509 SSL certification authentication. This is similar to > Kerberos auth plugin. It must be used in conjunction with Apache mod_ssl. > > DocImpact > SecurityImpact > > Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 From tristan.cacqueray at enovance.com Tue Jul 8 15:38:30 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 08 Jul 2014 15:38:30 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140708153831.10721.19186.launchpad@soybean.canonical.com> ** Summary changed: - XSS in Horizon Heat template - resource name (CVE-2014-3473) + [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From gerrit2 at review.openstack.org Tue Jul 8 19:14:09 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 08 Jul 2014 19:14:09 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/103736 Log: commit e18c85ffaa6d72bc7b93dc9d9be6d52eb18b8fbc Author: guang-yee Date: Mon Jun 30 22:38:50 2014 -0700 X.509 SSL certificate authentication plugin Add a plugin for X.509 SSL certification authentication. This is similar to Kerberos auth plugin. It must be used in conjunction with Apache mod_ssl. DocImpact SecurityImpact Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 From 1319639 at bugs.launchpad.net Wed Jul 9 16:11:27 2014 From: 1319639 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 09 Jul 2014 16:11:27 -0000 Subject: [Openstack-security] [Bug 1319639] Re: Standard random number generators (using shuffle ) should not be used to generate randomness References: <20140515051014.31551.82176.malonedeb@soybean.canonical.com> Message-ID: <20140709161127.12186.95863.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/105779 ** Changed in: cinder Status: Triaged => In Progress ** Changed in: cinder Assignee: (unassigned) => Ivan Kolodyazhny (e0ne) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319639 Title: Standard random number generators (using shuffle ) should not be used to generate randomness Status in Cinder: In Progress Bug description: In cinder code : /cinder/utils.py . Below two lines of code used shuffle to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it?  # If length < len(symbolgroups), the leading characters will only  # be from the first length groups. Try our best to not be predictable  # by shuffling and then truncating.  r.shuffle(password) ----------------> This line of code has described issue.  password = password[:length]  length -= len(password) # finally shuffle to ensure first x characters aren't from a # predictable group r.shuffle(password) ----------------> This line of code has described issue. return ''.join(password) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319639/+subscriptions From sriram at sriramhere.com Wed Jul 9 16:30:17 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Wed, 9 Jul 2014 09:30:17 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: References: Message-ID: Dear OSSG: Do we have a good idea of the schedule yet? While we will have parallel tracks, it probably is better if we pack a certain topic in least # of days as possible (for instance, if OSSG Book Cleanup is going to take 16 hours, 2 full days might be better than 4 half days). Thoughts? I am sure we will discuss more tomorrow, but opening it up. Thanks, -Sriram On Thu, Jun 5, 2014 at 11:51 AM, Sriram Subramanian wrote: > Rob/ OSSG: > > Per our discussions today at the weekly meetup, I would like to start > discussions on the meetup agendas. I am listing out with the projects that > I am aware of, please add/ edit appropriately. I might be completely wrong, > i filled in to get things rolling. > > *Etherpad* > > https://etherpad.openstack.org/p/ossg-juno-meetup > > *List of Projects* > > Topic Importance Size Interested > On Going (OSSNs, OSSAs) > High Medium > Baseline Security Review of Projects (not sure if I imagined this, or it > was talked about anywhere) > Medium Medium > OSSG Book Cleanup > High Large > Threat Modeling > High Medium > Security Anti-Patterns > Medium Small > Library Audit > Medium Medium > Fuzz Testing > Medium Small > > Please chime in (need help in formatting in to a table at etherpad please) > > -- > Thanks, > -Sriram > 425-610-8465 > www.sriramhere.com | www.clouddon.com > -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Wed Jul 9 16:36:28 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 9 Jul 2014 09:36:28 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: References: Message-ID: Speaking to just the book cleanup, I believe that effort will fill the week. I had kind of imagined that their other tasks would be the same way. But perhaps not? This would be a good discussion topic at the meeting tomorrow. bryan On Wed, Jul 9, 2014 at 9:30 AM, Sriram Subramanian wrote: > Dear OSSG: > > Do we have a good idea of the schedule yet? While we will have parallel > tracks, it probably is better if we pack a certain topic in least # of days > as possible (for instance, if OSSG Book Cleanup is going to take 16 hours, > 2 full days might be better than 4 half days). > > Thoughts? I am sure we will discuss more tomorrow, but opening it up. > > Thanks, > -Sriram > > > On Thu, Jun 5, 2014 at 11:51 AM, Sriram Subramanian > wrote: > >> Rob/ OSSG: >> >> Per our discussions today at the weekly meetup, I would like to start >> discussions on the meetup agendas. I am listing out with the projects that >> I am aware of, please add/ edit appropriately. I might be completely wrong, >> i filled in to get things rolling. >> >> *Etherpad* >> >> https://etherpad.openstack.org/p/ossg-juno-meetup >> >> *List of Projects* >> >> Topic Importance Size Interested >> On Going (OSSNs, OSSAs) >> High Medium >> Baseline Security Review of Projects (not sure if I imagined this, or it >> was talked about anywhere) >> Medium Medium >> OSSG Book Cleanup >> High Large >> Threat Modeling >> High Medium >> Security Anti-Patterns >> Medium Small >> Library Audit >> Medium Medium >> Fuzz Testing >> Medium Small >> >> Please chime in (need help in formatting in to a table at etherpad please) >> >> -- >> Thanks, >> -Sriram >> 425-610-8465 >> www.sriramhere.com | www.clouddon.com >> > > > > -- > Thanks, > -Sriram > 425-610-8465 > www.sriramhere.com | www.clouddon.com > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From todd at privatecore.com Wed Jul 9 18:24:32 2014 From: todd at privatecore.com (Todd Thiemann) Date: Wed, 9 Jul 2014 11:24:32 -0700 Subject: [Openstack-security] OpenStack Security Meetup in San Francisco (31 July) Call for Papers Message-ID: This message is a Call For Papers (CFP) for a meetup happening on the evening of 31 July in San Francisco to enjoy a few brief security-focused talks. If you are in the area, please feel free to register and attend. We now have 95+ people signed up to attend the "OpenStack Security Meetup" with presentations by Oded Horovitz (PrivateCore) and Remo Mattei (Red Hat). (check out *http://www.meetup.com/openstack/events/189851642/ * ) We have a presentation/demo slot available for those with OpenStack security insights. This slot provides a platform to briefly (25 minutes) cover a topic of interest to the OpenStack security community. This is intended to be a technical presentation that educates on a given OpenStack security topic (no sales pitches please!). We may also have the time for brief demos or breakout discussions. If you have an interest in presenting or demo-ing, please send me an email ( todd at privatecore.com) with a summary of the topic and 2-3 bullet points that the audience will take away. I look forward to seeing you at the OpenStack Security Meetup in San Francisco on 31 July! Cheers, Todd -- Todd Thiemann VP - Marketing +1.650.352.3547 | todd at privatecore.com | www.privatecore.com Visit our blog at http://privatecore.com/blogs/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.carrez+lp at gmail.com Wed Jul 9 19:12:58 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 09 Jul 2014 19:12:58 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140709191259.11249.18296.launchpad@soybean.canonical.com> ** Also affects: horizon/havana Importance: Undecided Status: New ** Also affects: horizon/icehouse Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Dashboard (Horizon) havana series: New Status in OpenStack Dashboard (Horizon) icehouse series: New Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1192971 at bugs.launchpad.net Wed Jul 9 23:49:12 2014 From: 1192971 at bugs.launchpad.net (Joe Gordon) Date: Wed, 09 Jul 2014 23:49:12 -0000 Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need to be strengthened References: <20130620133506.19620.30523.malonedeb@gac.canonical.com> Message-ID: <20140709234915.11676.97760.launchpad@gac.canonical.com> ** Changed in: nova Status: In Progress => Confirmed ** Changed in: nova Assignee: Lance Bragstad (lbragstad) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1192971 Title: Command execution cases need to be strengthened Status in Cinder: In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Grant Murphy from Red Hat Product Security Team reports the following potential vulnerability: For the most part OpenStack seems to do command execution safely using subprocess.Popen. There are two instances where things become a little dubious. The first is when shell=True is used with subprocess. This doesn't prevent arguments being supplied that allow for multiple commands to be executed. e.g. '; cat /etc/passwd'. The second case is where commands are made to an external ssh host. See attached file for a lit of potential injections: we should double- check them (even if I expect most of them to turn false positive) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions From 1319639 at bugs.launchpad.net Thu Jul 10 08:46:04 2014 From: 1319639 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Jul 2014 08:46:04 -0000 Subject: [Openstack-security] [Bug 1319639] Re: Standard random number generators (using shuffle ) should not be used to generate randomness References: <20140515051014.31551.82176.malonedeb@soybean.canonical.com> Message-ID: <20140710084604.12431.92703.malone@gac.canonical.com> Reviewed: https://review.openstack.org/105779 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=063e515e780c241ddac755b0b9a2414316d983f5 Submitter: Jenkins Branch: master commit 063e515e780c241ddac755b0b9a2414316d983f5 Author: Ivan Kolodyazhny Date: Wed Jul 9 19:08:18 2014 +0300 Use PyCrypto to generate randomness passwords Standard random generator is not secure enouph. Use PyCrypto instead. Updated requirements.txt with pycrypto>=2.6 according to global-requirements Change-Id: I38fd47a30893a946de30fad95c57759781312be6 Closes: bug #1319639 ** Changed in: cinder Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319639 Title: Standard random number generators (using shuffle ) should not be used to generate randomness Status in Cinder: Fix Committed Bug description: In cinder code : /cinder/utils.py . Below two lines of code used shuffle to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it?  # If length < len(symbolgroups), the leading characters will only  # be from the first length groups. Try our best to not be predictable  # by shuffling and then truncating.  r.shuffle(password) ----------------> This line of code has described issue.  password = password[:length]  length -= len(password) # finally shuffle to ensure first x characters aren't from a # predictable group r.shuffle(password) ----------------> This line of code has described issue. return ''.join(password) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319639/+subscriptions From 1336225 at bugs.launchpad.net Wed Jul 2 12:23:25 2014 From: 1336225 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 02 Jul 2014 12:23:25 -0000 Subject: [Openstack-security] [Bug 1336225] Re: Password is exposed in the log file References: <20140701103304.7888.77002.malonedeb@wampee.canonical.com> Message-ID: <20140702122325.10667.81557.malone@gac.canonical.com> Reviewed: https://review.openstack.org/103842 Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=35cf2f7a3beb6ac5fd198aa6ce1cdb492a099cf2 Submitter: Jenkins Branch: master commit 35cf2f7a3beb6ac5fd198aa6ce1cdb492a099cf2 Author: Kanagaraj Manickam Date: Tue Jul 1 16:34:21 2014 +0530 Don't expose password in heat-keystone-setup-domain logs heat-keystone-setup-domain is logging the password to the log file. This patch removes the logging as it's security concerns Change-Id: I0f017a9c114ac60ea9f5e0df012334ead8cb434a Closes-bug: #1336225 ** Changed in: heat Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1336225 Title: Password is exposed in the log file Status in Orchestration API (Heat): Fix Committed Bug description: heat-keystone-setup-domain is logging the password to the log file. This defect is filed to remove the logging statement as its security concerns To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1336225/+subscriptions From anthony.chow at alcatel-lucent.com Thu Jul 3 18:17:37 2014 From: anthony.chow at alcatel-lucent.com (Chow, Anthony T (Anthony)) Date: Thu, 3 Jul 2014 18:17:37 +0000 Subject: [Openstack-security] Congrats Rob! Message-ID: <066DBCC674B90C41B7B82FE2DB3EDDFD350D0ACC@US70UWXCHMBA05.zam.alcatel-lucent.com> Congratulations. Fully agree with Eric Windisch (eric at windisch.us)-> Well deserved. Have a nice weekend, Anthony. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1308727 at bugs.launchpad.net Tue Jul 8 15:02:41 2014 From: 1308727 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 Jul 2014 15:02:41 -0000 Subject: [Openstack-security] [Bug 1308727] Re: XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140708150241.27082.53819.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/105476 ** Changed in: horizon Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1308727 at bugs.launchpad.net Tue Jul 8 15:03:04 2014 From: 1308727 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 Jul 2014 15:03:04 -0000 Subject: [Openstack-security] [Bug 1308727] Fix proposed to horizon (stable/icehouse) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140708150304.29453.57603.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/105477 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1308727 at bugs.launchpad.net Tue Jul 8 15:04:52 2014 From: 1308727 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 Jul 2014 15:04:52 -0000 Subject: [Openstack-security] [Bug 1308727] Fix proposed to horizon (stable/havana) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140708150452.27605.32342.malone@gac.canonical.com> Fix proposed to branch: stable/havana Review: https://review.openstack.org/105478 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From guang.yee at hp.com Tue Jul 8 18:05:35 2014 From: guang.yee at hp.com (Yee, Guang) Date: Tue, 8 Jul 2014 18:05:35 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 In-Reply-To: References: Message-ID: Hi Jeff, Thanks for the review. Please see my response inline. Guang > -----Original Message----- > From: Jeffrey Walton [mailto:noloader at gmail.com] > Sent: Tuesday, July 08, 2014 8:28 AM > To: openstack-security at lists.openstack.org > Cc: Yee, Guang > Subject: Re: [Openstack-security] [openstack/keystone] SecurityImpact > review request change I695e8deeb89826717ec859461ab2339d8af20805 > > From tests/apache_fixtures.py: > > > 'SSL_CLIENT_S_DN': > > ('CN=localhost,emailAddress=keystone at openstack.org,'70 > > 'OU=Keystone,O=OpenStack,L=Sunnyvale,ST=CA,C=US'),71 > > 'SSL_CLIENT_I_DN': ('CN=Self > > Signed,emailAddress=keystone at openstack.org,'72 > > 'OU=Keystone,O=OpenStack,L=Sunnyvale,ST=CA,C=US,'73 > > 'serialNumber=5'), > > SSL_CLIENT_S_DN appears to be Subject Distinguished Name. A hostname in > the Common Name (CN) (i.e., CN=localhost) is deprecated by both the > IETF and the CA/Browser Forums [1,2]. Most CAs in the wild follow the > CA/Browser Forums, and *not* the IETF. (And which standard libraries > use is a whole 'nother debate). > > It would probably be a good idea to have a couple of test cases that > place the hostname in the Subject Alt Name (SAN), and not the Common > Name (CN). Both the IETF and CA/B want the hostname there. [gyee] this is SSL client certificate. My understanding is that only SSL server certificate need to follow the IETF (HTTPS) standard. This patch is for SSL authentication using SSL client certificate. SSL server certificate is to be validated by the client application. > > Also, a negative test case to consider uses a hostname of (1) "*.com", > and (2) "*.uk.com". (1) is a wildcarded gTLD, and (2) is a wildcarded > ccTLD. Both should probably be rejected because they claim perview over > the entire top level domain. Intuitively, we know this is not possible. > Additioanlly, its prohibited CA/B Baseline Requirements (which most CAs > issue against). [gyee] Wildcard chars are not used in this patch. It must be case-sensitive match of client certificate attributes. > > A final negative test case with hostname tricks would be (1) > "keystone.*.com", and (2) "keystone.*.uk.com". In this test case, the > asterisk is *not* in the leftmost label. This suffers the same basic > fault of the previous test case. And its a violation of the CA/B BR. [gyee] Same as above. We are using the SSL client certificate attributes conveyed by Apache mod_ssl. > > I know how Python, PERL, OpenSSL, .Net, Cocoa/CocoaTouch, Ruby, etc > responds to the negative test cases. For the first test case, ("*.com", > and "*.uk.com"), OpenStack will probably need an additional security > control because Python does not handle it correctly. If its OpenSSL > based, then *no* hostname matching currently occurs, so OpenStack will > need to implement it (or find a library with it). What I'm not clear > on: how does Apache respond to them (because I've never programmed > Apache). > > (Sorry to post to the list. I recently learned Gerrit was not saving > most of my comments. I want to ensure this is documented). > > Jeff > > [1] RFC 5280, Internet X.509 Public Key Infrastructure Certificate and > Certificate Revocation List (CRL) Profile, > http://www.ietf.org/rfc/rfc5280.txt. > [2] RFC 6125, Representation and Verification of Domain-Based > Application Service Identity within Internet Public Key Infrastructure > Using X.509 (PKIX) Certificates in the Context of Transport Layer > Security (TLS), http://www.ietf.org/rfc/rfc6125.txt. > [3] CA/Broswer Forums Baseline Requirements Documents, > https://cabforum.org/baseline-requirements-documents/. > > > On Tue, Jul 8, 2014 at 3:21 AM, wrote: > > > > Hi, I'd like you to take a look at this patch for potential > > SecurityImpact. > > https://review.openstack.org/103736 > > > > Log: > > commit 6bb86fe7971f250163395d450ccac06f7bafa789 > > Author: guang-yee > > Date: Mon Jun 30 22:38:50 2014 -0700 > > > > X.509 SSL certificate authentication plugin > > > > Add a plugin for X.509 SSL certification authentication. This is > similar to > > Kerberos auth plugin. It must be used in conjunction with Apache > mod_ssl. > > > > DocImpact > > SecurityImpact > > > > Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6183 bytes Desc: not available URL: From 1308727 at bugs.launchpad.net Wed Jul 9 12:07:46 2014 From: 1308727 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 09 Jul 2014 12:07:46 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140709120746.11346.30231.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/105476 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=de4466d88b816437fb29eff5ab23b9b964cd3985 Submitter: Jenkins Branch: master commit de4466d88b816437fb29eff5ab23b9b964cd3985 Author: Julie Pichon Date: Thu May 22 16:45:03 2014 +0100 Fix multiple Cross-Site Scripting (XSS) vulnerabilities. * Ensure user emails are properly escaped User emails in the Users and Groups panel are being passed through the urlize filter to transform them into clickable links. However, urlize expects input to be already escaped and safe. We should make sure to escape the strings first as email addresses are not validated and can contain any type of string. Closes-Bug: #1320235 * Ensure network names are properly escaped in the Launch Instance menu Closes-Bug: #1322197 * Escape the URLs generated for the Horizon tables When generating the Horizon tables, there was an assumption that only the anchor text needed to be escaped. However some URLs are generated based on user-provided data and should be escaped as well. * Use 'reverse' to generate the Resource URLs in the stacks tables Closes-Bug: #1308727 Change-Id: Ic8a92e69f66c2d265a802f350e30f091181aa42e ** Changed in: horizon Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1308727 at bugs.launchpad.net Wed Jul 9 14:59:47 2014 From: 1308727 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 09 Jul 2014 14:59:47 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140709145947.26522.91113.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/105477 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=32a7b713468161282f2ea01d5e2faff980d924cd Submitter: Jenkins Branch: stable/icehouse commit 32a7b713468161282f2ea01d5e2faff980d924cd Author: Julie Pichon Date: Thu May 22 16:45:03 2014 +0100 Fix multiple Cross-Site Scripting (XSS) vulnerabilities. * Ensure user emails are properly escaped User emails in the Users and Groups panel are being passed through the urlize filter to transform them into clickable links. However, urlize expects input to be already escaped and safe. We should make sure to escape the strings first as email addresses are not validated and can contain any type of string. Closes-Bug: #1320235 * Ensure network names are properly escaped in the Launch Instance menu Closes-Bug: #1322197 * Escape the URLs generated for the Horizon tables When generating the Horizon tables, there was an assumption that only the anchor text needed to be escaped. However some URLs are generated based on user-provided data and should be escaped as well. Also escape the link attributes for good measure. * Use 'reverse' to generate the Resource URLs in the stacks tables Closes-Bug: #1308727 Change-Id: Ic8a92e69f66c2d265a802f350e30f091181aa42e ** Tags added: in-stable-icehouse -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From tristan.cacqueray at enovance.com Thu Jul 10 10:55:47 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Thu, 10 Jul 2014 10:55:47 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140710105549.12045.2476.launchpad@gac.canonical.com> ** Changed in: horizon/icehouse Status: New => Fix Committed ** Changed in: horizon/havana Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Dashboard (Horizon) havana series: In Progress Status in OpenStack Dashboard (Horizon) icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Committed Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1322766 at bugs.launchpad.net Thu Jul 10 13:29:19 2014 From: 1322766 at bugs.launchpad.net (git-harry) Date: Thu, 10 Jul 2014 13:29:19 -0000 Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open References: <20140523222522.10305.61680.malonedeb@gac.canonical.com> Message-ID: <20140710132921.12395.98252.launchpad@gac.canonical.com> *** This bug is a duplicate of bug 1225194 *** https://bugs.launchpad.net/bugs/1225194 ** This bug has been marked a duplicate of bug 1225194 LVM clear_volume should raise exc. if volume_clear opt is invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1322766 Title: Cinder wipe/shred fails open Status in Cinder: New Status in OpenStack Security Notes: Fix Released Bug description: Previously, lvm_type=default signified a volume should be zero'd or wiped when deleting the volume. Zeroization could be avoided with lvm_type=thin. At https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20, the following was added: volume_clear = none, zero, shred volume_clear_size = size_in_MiB Looking at the code from the commit, the default behavior of wiping was changed, and the change resulted in a "fail open". That is, no wipe occurs on configuration errors or typos: + LOG.info(_("Performing secure delete on volume: %s") % volume['id']) + + if FLAGS.volume_clear == 'zero': + if size_in_m == 0: + return self._copy_volume('/dev/zero', vol_path, size_in_g) + else: + clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m] + elif FLAGS.volume_clear == 'shred': + clear_cmd = ['shred', '-n3'] + if size_in_m: + clear_cmd.append('-s%dMiB' % size_in_m) + else: + LOG.error(_("Error unrecognized volume_clear option: %s"), + FLAGS.volume_clear) + return Perhaps previous behavior should be restored: * default = one pass of 0's * a valid config changes the behavior * an invalid config still uses default behavior I think it s important to ensure cinder serves zero'ized block among tenants in the common case to ensure no data leaks of sensitive or highly sensitive data. Its going to be an important safeguard, especially in industries like US Financial and US Federal. Operators that don't handle sensitive or highly sensitive data can 'volume_clear = none'. And the unexpected case of a configuration error or typo ensures the system fails safe. In fact, specifying 'volume_clear = 1' or 'volume_clear = true' or 'volume_clear = yes' should trigger the unexpected fail open. From the low hanging fruit department.... Feel free to release it at any time. The "security vulnerability" was checked to ensure the security folks had an opportunity to provide feedback. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1322766/+subscriptions From sriram at sriramhere.com Thu Jul 10 16:41:07 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 10 Jul 2014 09:41:07 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: References: Message-ID: <53bec237.819f420a.2c82.ffffae88@mx.google.com> Thanks Bryan. Running little late for the meeting today, FYI. -----Original Message----- From: "Bryan D. Payne" Sent: ‎7/‎9/‎2014 9:36 AM To: "Sriram Subramanian" Cc: "openstack-security at lists.openstack.org" Subject: Re: [Openstack-security] OSSG Mid Cycle Meetup Agenda Speaking to just the book cleanup, I believe that effort will fill the week. I had kind of imagined that their other tasks would be the same way. But perhaps not? This would be a good discussion topic at the meeting tomorrow. bryan On Wed, Jul 9, 2014 at 9:30 AM, Sriram Subramanian wrote: Dear OSSG: Do we have a good idea of the schedule yet? While we will have parallel tracks, it probably is better if we pack a certain topic in least # of days as possible (for instance, if OSSG Book Cleanup is going to take 16 hours, 2 full days might be better than 4 half days). Thoughts? I am sure we will discuss more tomorrow, but opening it up. Thanks, -Sriram On Thu, Jun 5, 2014 at 11:51 AM, Sriram Subramanian wrote: Rob/ OSSG: Per our discussions today at the weekly meetup, I would like to start discussions on the meetup agendas. I am listing out with the projects that I am aware of, please add/ edit appropriately. I might be completely wrong, i filled in to get things rolling. Etherpad https://etherpad.openstack.org/p/ossg-juno-meetup List of Projects TopicImportanceSizeInterested On Going (OSSNs, OSSAs)HighMedium Baseline Security Review of Projects (not sure if I imagined this, or it was talked about anywhere)MediumMedium OSSG Book CleanupHighLarge Threat ModelingHighMedium Security Anti-PatternsMediumSmall Library AuditMediumMedium Fuzz TestingMediumSmall Please chime in (need help in formatting in to a table at etherpad please) -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1290486 at bugs.launchpad.net Thu Jul 10 17:10:54 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Thu, 10 Jul 2014 17:10:54 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140710171058.6905.83428.launchpad@soybean.canonical.com> ** Changed in: neutron Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Incomplete Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From thang.g.pham at gmail.com Thu Jul 10 18:59:40 2014 From: thang.g.pham at gmail.com (Thang Pham) Date: Thu, 10 Jul 2014 18:59:40 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20140710185942.31681.4284.launchpad@chaenomeles.canonical.com> ** Changed in: nova Assignee: (unassigned) => Thang Pham (thang-pham) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From 1308727 at bugs.launchpad.net Thu Jul 10 20:19:46 2014 From: 1308727 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Jul 2014 20:19:46 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140710201946.31397.28388.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/105478 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=c844bd692894353c60b320005b804970605e910f Submitter: Jenkins Branch: stable/havana commit c844bd692894353c60b320005b804970605e910f Author: Julie Pichon Date: Thu May 22 16:45:03 2014 +0100 Fix multiple Cross-Site Scripting (XSS) vulnerabilities * Ensure user emails are properly escaped User emails in the Users and Groups panel are being passed through the urlize filter to transform them into clickable links. However, urlize expects input to be already escaped and safe. We should make sure to escape the strings first as email addresses are not validated and can contain any type of string. Closes-Bug: #1320235 * Ensure network names are properly escaped in the Launch Instance menu Closes-Bug: #1322197 * Escape the URLs generated for the Horizon tables When generating the Horizon tables, there was an assumption that only the anchor text needed to be escaped. However some URLs are generated based on user-provided data and should be escaped as well. Also escape the link attributes for good measure. * Use 'reverse' to generate the Resource URLs in the stacks tables Closes-Bug: #1308727 Conflicts: horizon/tables/base.py openstack_dashboard/dashboards/admin/users/tables.py Change-Id: Ic8a92e69f66c2d265a802f350e30f091181aa42e ** Changed in: horizon/havana Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Dashboard (Horizon) havana series: Fix Committed Status in OpenStack Dashboard (Horizon) icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From tristan.cacqueray at enovance.com Thu Jul 10 20:21:52 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Thu, 10 Jul 2014 20:21:52 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140710202155.31498.5436.launchpad@chaenomeles.canonical.com> ** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Dashboard (Horizon) havana series: Fix Committed Status in OpenStack Dashboard (Horizon) icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From gerrit2 at review.openstack.org Fri Jul 11 01:48:54 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 11 Jul 2014 01:48:54 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit f4a21fed6e0fd283d1f3e40083d374864a56cd51 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Fri Jul 11 01:49:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 11 Jul 2014 01:49:37 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit eb61479bcfd7a24318b894cb7f718c670dcc5cf5 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Fri Jul 11 01:51:33 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 11 Jul 2014 01:51:33 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit af9ac50db0b5450ed0240c91a6417045ff131fc7 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1334938 at bugs.launchpad.net Fri Jul 11 05:51:16 2014 From: 1334938 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 11 Jul 2014 05:51:16 -0000 Subject: [Openstack-security] [Bug 1334938] Re: established floating ip connection won't get disconnected after disassociating floating ip References: <20140627031928.26375.32794.malonedeb@wampee.canonical.com> Message-ID: <20140711055116.31604.19598.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/103023 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=7028f074202a59111f461b9fa935f44b6d118f41 Submitter: Jenkins Branch: master commit 7028f074202a59111f461b9fa935f44b6d118f41 Author: stanzgy Date: Fri Jun 27 13:38:09 2014 +0800 Clean conntrack records when removing floating ip Established connections via floating ip won't get disconnected after disassociating. This patch move clean_conntrack from migration code to remove_floating_ip to make sure that established connections on floating ip will get interrupted immediately after disassociating. Change-Id: I88d258ea39ea7c76e4cc60a636eb1e3e6aaa6f22 Closes-Bug: #1334938 ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334938 Title: established floating ip connection won't get disconnected after disassociating floating ip Status in OpenStack Compute (Nova): Fix Committed Bug description: Established connections via floating ip won't get disconnected after we disassociating that floating ip. As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to remove_floating_ip. https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334938/+subscriptions From 1290486 at bugs.launchpad.net Fri Jul 11 07:10:06 2014 From: 1290486 at bugs.launchpad.net (James Polley) Date: Fri, 11 Jul 2014 07:10:06 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140711071006.31566.49309.malone@chaenomeles.canonical.com> I've tried to follow Roman's steps above, but I can't reproduce this problem. I'm not sure if this is because I didn't quite do exactly the same thing though. I ran a standard devtest build from trunk, but with --no-undercloud, so I've only got a seed and the overcloud. 9:04:17 0 130 polleyj at bill:~/.cache/tripleo (master)$ nova list +--------------------------------------+-------------------------------------+--------+------------+-------------+--------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+-------------------------------------+--------+------------+-------------+--------------------+ | 2ccc4069-7801-4de2-8d22-a4da62aacb42 | overcloud-NovaCompute0-pok6xaae4p2j | ACTIVE | - | Running | ctlplane=192.0.2.3 | | 4d99893a-be5f-48f9-8932-1123cdcaf3e0 | overcloud-NovaCompute1-fci7it3qq57q | ACTIVE | - | Running | ctlplane=192.0.2.6 | | ba8dd7db-6189-4426-909d-84e63ec44c7b | overcloud-controller0-vyxuppnmkdf2 | ACTIVE | - | Running | ctlplane=192.0.2.4 | +--------------------------------------+-------------------------------------+--------+------------+-------------+--------------------+ I sshed to 192.0.2.4 and used: sudo ip netns exec qdhcp-8b8a6df3-f19f-4fa5-bed5-b13e5cbbe70c ping 192.0.2.3 to try to ping out the right interface. To restart the OVS, I sshed into 192.0.2.3 and ran "service openvswitch- switch restart" The ping running on the controller node didn't see any packets get dropped. Roman, am I missing some step from your process? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Incomplete Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1290486 at bugs.launchpad.net Fri Jul 11 13:59:25 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Fri, 11 Jul 2014 13:59:25 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140711135925.31335.16941.malone@wampee.canonical.com> Thanks for trying this out James! Roman, I'm also keen to see what we may have missed in your steps to reproduce, as I can't reproduce this either. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Incomplete Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1274034 at bugs.launchpad.net Fri Jul 11 16:45:49 2014 From: 1274034 at bugs.launchpad.net (Kevin Bringard) Date: Fri, 11 Jul 2014 16:45:49 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140711164552.2140.1632.launchpad@gac.canonical.com> ** Changed in: neutron Assignee: Kevin Bringard (kbringard) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From robert.clark at hp.com Sat Jul 12 15:08:59 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Sat, 12 Jul 2014 15:08:59 +0000 Subject: [Openstack-security] [OSSG][Meetup] Sunday social? Message-ID: Hi Guys, I know many of you are filtering in over the weekend, if you want to meet up over the weekend just reply on thread and say so :) I’m tied up for most of today but should be available tomorrow. If you need me for anything I should be reachable on +44 5601 090629 Cheers -Rob From sriram at sriramhere.com Sun Jul 13 06:52:25 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Sat, 12 Jul 2014 23:52:25 -0700 Subject: [Openstack-security] [OSSG][Meetup] Sunday social? In-Reply-To: References: Message-ID: Welcome to Seattle Rob! I'd love to, my brother's family is in town visiting. I will try my best though thanks, -Sriram On Sat, Jul 12, 2014 at 8:08 AM, Clark, Robert Graham wrote: > Hi Guys, > > I know many of you are filtering in over the weekend, if you want to meet > up over the weekend just reply on thread and say so :) > > I’m tied up for most of today but should be available tomorrow. > > If you need me for anything I should be reachable on +44 5601 090629 > > Cheers > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1118194 at bugs.launchpad.net Sun Jul 13 03:56:48 2014 From: 1118194 at bugs.launchpad.net (Tom Fifield) Date: Sun, 13 Jul 2014 03:56:48 -0000 Subject: [Openstack-security] [Bug 1118194] Re: Security Documentation for Horizon References: <20130207100009.11250.38496.malonedeb@chaenomeles.canonical.com> Message-ID: <20140713035648.6511.19331.malone@soybean.canonical.com> This is fixed by http://docs.openstack.org/security- guide/content/dashboard.html -- You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. https://bugs.launchpad.net/bugs/1118194 Title: Security Documentation for Horizon Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Manuals: Confirmed Bug description: Horizon's documentation doesn't contain much in terms of guidelines for securing a deployment. The following should be documented somewhere: When implementing Horizon for public usage, with the website served through HTTPS, the following recommendations apply. In the Apache global configuration ensure that the following directive is configured to prevent the server from sharing its name, version and any other information that could be used for an attack: ServerSignature Off In the Apache global configuration ensure that the following directive is configured to prevent cross-site tracing [1]: TraceEnable Off In the Apache virtual host configuration: 1) Ensure that the "Indexes" option is not included in the Options directive. 2) Protect the server from BEAST attacks [2] by implementing the following options:   SSLHonorCipherOrder on   SSLProtocol -ALL +SSLv3 +TLSv1   SSLCipherSuite RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!ADH:!AESGCM:!AES In local_settings.py, implement the following settings in order to help protect the cookies from cross-site scripting [3]: CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True SESSION_COOKIE_HTTPONLY = True Note that the CSRF_COOKIE_SECURE option is only available from Django 1.4 and will therefore not work for most packaged Essex deployments. Also, since a recent patch [4], you can disable browser autocompletion [5] for the authentication form by changing the 'password_autocomplete' attribute to 'off' in horizon/conf/default.py. [1] http://www.kb.cert.org/vuls/id/867593 [2] http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack [3] https://www.owasp.org/index.php/HttpOnly [4] https://review.openstack.org/21349 [5] https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1118194/+subscriptions From robert.clark at hp.com Mon Jul 14 13:46:34 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 14 Jul 2014 13:46:34 +0000 Subject: [Openstack-security] [OSSG] No OSSG IRC meeting this week Message-ID: Most of us are at the OSSG meet up so no IRC meeting this week. Cheers -Rob From 1334926 at bugs.launchpad.net Mon Jul 14 18:52:37 2014 From: 1334926 at bugs.launchpad.net (Robert Clark) Date: Mon, 14 Jul 2014 18:52:37 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140714185240.6656.8787.launchpad@soybean.canonical.com> ** Changed in: ossn Status: New => In Progress ** Changed in: ossn Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: In Progress Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From 1316822 at bugs.launchpad.net Mon Jul 14 18:53:11 2014 From: 1316822 at bugs.launchpad.net (Doug Chivers) Date: Mon, 14 Jul 2014 18:53:11 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140714185313.2312.1099.launchpad@gac.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Doug Chivers (doug-chivers) ** Changed in: ossn Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From malini.k.bhandaru at intel.com Mon Jul 14 20:25:54 2014 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Mon, 14 Jul 2014 20:25:54 +0000 Subject: [Openstack-security] threat analysis of keystone -- notes Message-ID: Getting started .. https://etherpad.openstack.org/p/juno-keystone-threat-analysis From matt at nycresistor.com Mon Jul 14 22:11:24 2014 From: matt at nycresistor.com (matt) Date: Mon, 14 Jul 2014 18:11:24 -0400 Subject: [Openstack-security] [OSSG][Meetup] Sunday social? In-Reply-To: References: Message-ID: Sorry I missed you guys... was coming off a bit of an exhaustive camping vacation so... we probably passed some of each other in the air port. I leave you with a single tip. Elysian Bar, it's down near market off of pike. Walking distance from the OSSG meetup. Not too expensive... but, best beer in the hood and wholely acceptable cost amazing food. Try the berliner weiss sour on tap. Ultimate summer beer. Or don't everything else is amazing too. Cheers, and good luck securing OpenStack. -Matt Joyce On Sun, Jul 13, 2014 at 2:52 AM, Sriram Subramanian wrote: > Welcome to Seattle Rob! > > I'd love to, my brother's family is in town visiting. I will try my best > though > > thanks, > -Sriram > > > On Sat, Jul 12, 2014 at 8:08 AM, Clark, Robert Graham > wrote: > >> Hi Guys, >> >> I know many of you are filtering in over the weekend, if you want to meet >> up over the weekend just reply on thread and say so :) >> >> I’m tied up for most of today but should be available tomorrow. >> >> If you need me for anything I should be reachable on +44 5601 090629 >> >> Cheers >> -Rob >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > > > > -- > Thanks, > -Sriram > 425-610-8465 > www.sriramhere.com | www.clouddon.com > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Mon Jul 14 22:56:55 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 14 Jul 2014 22:56:55 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ifeca3056b8552d4b78845e97ddc25f00c49950de Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/106890 Log: commit f39399276762369fd232b28a7bd5a42a999a00ff Author: Brant Knudson Date: Mon Jul 14 17:08:07 2014 -0500 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unprivileged source (e.g. lower priv log watchers, centralized logging, etc). The main use case is to ensure that it is possible to correlate a token to the various requests made. In some cases this has shown where a token has expired (tokens weren't properly refreshed). This use case for debugging eliminates simple redaction of the token id from the logs. SHA1 is no longer allowed as a hashing mode for CMS token hashing. This is because SHA1 is being used to obscure tokens in the session object debug. This is done to prevent the debug output from being potentially exposing a valid token (PKI->sha1-short-id) in some configurations of Keystone / auth_token middleware. The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: Ifeca3056b8552d4b78845e97ddc25f00c49950de From gerrit2 at review.openstack.org Tue Jul 15 00:29:29 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 15 Jul 2014 00:29:29 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ifeca3056b8552d4b78845e97ddc25f00c49950de Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/106890 Log: commit b7a34b2a155f2bf719df8001b2f69dee26e77d92 Author: Brant Knudson Date: Mon Jul 14 17:08:07 2014 -0500 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unprivileged source (e.g. lower priv log watchers, centralized logging, etc). The main use case is to ensure that it is possible to correlate a token to the various requests made. In some cases this has shown where a token has expired (tokens weren't properly refreshed). This use case for debugging eliminates simple redaction of the token id from the logs. SHA1 is no longer allowed as a hashing mode for CMS token hashing. This is because SHA1 is being used to obscure tokens in the session object debug. This is done to prevent the debug output from being potentially exposing a valid token (PKI->sha1-short-id) in some configurations of Keystone / auth_token middleware. The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: Ifeca3056b8552d4b78845e97ddc25f00c49950de From 1252519 at bugs.launchpad.net Tue Jul 15 00:58:11 2014 From: 1252519 at bugs.launchpad.net (haruka tanizawa) Date: Tue, 15 Jul 2014 00:58:11 -0000 Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed because of file permission changed References: <20131119003108.27374.76789.malonedeb@gac.canonical.com> Message-ID: <20140715005811.31573.55926.malone@wampee.canonical.com> Hi Barrow Kwan, How do you think about Maldonado's comment? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1252519 Title: Live migration failed because of file permission changed Status in OpenStack Compute (Nova): Triaged Bug description: Openstack : Havana OS : CentOS 6.4 Shared storage with GlusterFS : /var/lib/nova/instances mounted on glusterfs shared Instance start up fine on node01. When live migration happen, it moved to node02 but failed with the following error 2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command. Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk Exit code: 1 Stdout: '' Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n" 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last): 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task task(self, context) The problem is with the file ownership of "console.log" and "disk". Those file should be owned by user "qemu" and group "qemu" but after the migration, both files are owned by root drwxr-xr-x 2 nova nova 53 Nov 18 13:40 . drwxr-xr-x 6 nova nova 110 Nov 18 13:43 .. -rw-rw---- 1 root root 1546 Nov 18 13:43 console.log -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk -rw-r--r-- 1 nova nova 1569 Nov 18 13:42 libvirt.xml To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1252519/+subscriptions From 1004114 at bugs.launchpad.net Tue Jul 15 18:09:14 2014 From: 1004114 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 15 Jul 2014 18:09:14 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140715180917.6975.96847.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Assignee: Wei Wang (damon-devops) => David Stanek (dstanek) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From 1004114 at bugs.launchpad.net Wed Jul 16 01:13:01 2014 From: 1004114 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 16 Jul 2014 01:13:01 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140716011303.7143.8805.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Assignee: David Stanek (dstanek) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From jokke at hp.com Tue Jul 15 09:34:36 2014 From: jokke at hp.com (Erno Kuvaja) Date: Tue, 15 Jul 2014 09:34:36 -0000 Subject: [Openstack-security] [Bug 1192966] Re: Potentially insecure dependency loading References: <20130620132537.19232.33035.malonedeb@gac.canonical.com> Message-ID: <20140715093436.6872.16332.malone@soybean.canonical.com> This has been set in Glance since Jan 2012 commit 804396204e23ebb6c29c396396027bc3b09b0eab ** Changed in: glance Status: New => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1192966 Title: Potentially insecure dependency loading Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Status in OpenStack Object Storage (Swift): New Bug description: Grant Murphy and Dhiru Kholia from Red Hat Product Security Team reported the following potential issue. This is actually a setuptools issue but which we may be able to workaround, if we end up being affected: --- A security flaw was found in the way Python Setuptools, a collection of enhancements to the Python distutils module, that allows more easily to build and distribute Python packages, performed integrity checks when loading external resources, previously extracted from zipped Python Egg archives(formerly if the timestamp and file size of a particular resource expanded from the archive matched the original values, the resource was successfully loaded). A local attacker, with write permission into the Python's EGG cache (directory) could use this flaw to provide a specially-crafted resource (in expanded form) that, when loaded in an application requiring that resource to (be able to) run, would lead to arbitrary code execution with the privileges of the user running the application. It seems to be pretty common for Python applications to do something like os.evironment['PYTHON_EGG_CACHE'] = /tmp, prior to importing dependencies. If the dependency contains a .so Python must unpack it into the cache directory to be able to load it. However if an attacker pre-emptively places a .so in the same location as long as the file has the same timestamp and file size it will be loaded. --- Glance and Swift both set PYTHON_EGG_CACHE to '/tmp' : ./glance/glance/cmd/control.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' ./swift/swift/common/manager.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' If we are immediately vulnerable to this (i.e. if stuff loaded from those commands contains an .so, if I understand correctly), we could workaround it by setting it to /tmp/secure-dir-XXXXXX/ until setuptools upstream fixes this. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1192966/+subscriptions From sriram at sriramhere.com Wed Jul 16 15:58:24 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Wed, 16 Jul 2014 08:58:24 -0700 Subject: [Openstack-security] I'll be late this morning, in around 11. Thx Message-ID: <53c6a122.23db440a.5def.78fe@mx.google.com> An HTML attachment was scrubbed... URL: From 1316822 at bugs.launchpad.net Thu Jul 17 12:41:11 2014 From: 1316822 at bugs.launchpad.net (Doug Chivers) Date: Thu, 17 Jul 2014 12:41:11 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140717124111.32557.8302.malone@chaenomeles.canonical.com> Does this impact systems using Neutron, or only systems using nova networking? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From gerrit2 at review.openstack.org Thu Jul 17 16:52:32 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 17 Jul 2014 16:52:32 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 1be97be53f5d88ed8dedcc46cf59fd49afb2a16d Author: Daniel Genin Date: Wed May 21 13:52:09 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From 1316822 at bugs.launchpad.net Thu Jul 17 17:34:50 2014 From: 1316822 at bugs.launchpad.net (Doug Chivers) Date: Thu, 17 Jul 2014 17:34:50 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140717173450.32557.50981.malone@chaenomeles.canonical.com> Answering my own question: no, this only impacts nova networking. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From 1316822 at bugs.launchpad.net Thu Jul 17 17:34:53 2014 From: 1316822 at bugs.launchpad.net (Robert Clark) Date: Thu, 17 Jul 2014 17:34:53 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140717173456.8889.27121.launchpad@soybean.canonical.com> ** Changed in: ossn Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From travis_mcpeak at symantec.com Fri Jul 18 18:24:09 2014 From: travis_mcpeak at symantec.com (Travis McPeak) Date: Fri, 18 Jul 2014 18:24:09 -0000 Subject: [Openstack-security] [Bug 1335208] Re: Shell injection possibility in cmd/control.py References: <20140627163123.19133.62950.malonedeb@gac.canonical.com> Message-ID: <20140718182411.32557.7974.launchpad@chaenomeles.canonical.com> ** Changed in: glance Assignee: (unassigned) => Travis McPeak (travis-mcpeak) ** Changed in: glance Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1335208 Title: Shell injection possibility in cmd/control.py Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Invalid Bug description: The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. This may not be a major security concern at this time because the only place that I found for 'server' to come from is a Glance configuration file, which should be locked down. Only privileged users should have write access to the config file, and if they want to do bad things on the system there are easier ways. Still, 'shell=True' appears to be completely unnecessary for this call. Simply omitting the shell parameter here will cause it to revert to the default behavior, which requires that the command to be run be specified in a separate parameter than the arguments to the command. This effectively prevents shell injection vulnerabilities. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1335208/+subscriptions From 1320028 at bugs.launchpad.net Sat Jul 19 01:57:48 2014 From: 1320028 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 19 Jul 2014 01:57:48 -0000 Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140719015748.32588.28829.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/93850 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=54458334136b284bb0c45373e7cacf5c1fa0ab99 Submitter: Jenkins Branch: master commit 54458334136b284bb0c45373e7cacf5c1fa0ab99 Author: Brad Pokorny Date: Fri May 16 03:59:36 2014 +0000 Mask node.session.auth.password in volume.py _run_iscsiadm debug logs The iscsi_command object passed to _run_iscsiadm can contain passwords that get logged at debug level, so we need to sanitize the message getting logged. Adds a test to ensure the logged message is properly sanitized. Closes-Bug: #1320028 Change-Id: I33f1a5b698368504721b41e56266162a713b3ce6 ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From 1335208 at bugs.launchpad.net Fri Jul 18 18:29:22 2014 From: 1335208 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 18 Jul 2014 18:29:22 -0000 Subject: [Openstack-security] [Bug 1335208] Fix proposed to glance (master) References: <20140627163123.19133.62950.malonedeb@gac.canonical.com> Message-ID: <20140718182922.9317.80649.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/108127 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1335208 Title: Shell injection possibility in cmd/control.py Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Invalid Bug description: The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. This may not be a major security concern at this time because the only place that I found for 'server' to come from is a Glance configuration file, which should be locked down. Only privileged users should have write access to the config file, and if they want to do bad things on the system there are easier ways. Still, 'shell=True' appears to be completely unnecessary for this call. Simply omitting the shell parameter here will cause it to revert to the default behavior, which requires that the command to be run be specified in a separate parameter than the arguments to the command. This effectively prevents shell injection vulnerabilities. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1335208/+subscriptions From gerrit2 at review.openstack.org Mon Jul 21 11:35:26 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 21 Jul 2014 11:35:26 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I2912ad7efc10b065c954fd198325305f81a8c6ec Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/108215 Log: commit d409b3a7e5ee666dc6c932dc286470f129f749ff Author: Amrith Kumar Date: Sat Jul 19 19:15:48 2014 -0400 Mask any password in exception command string Currently the command executed by processutils.execute is included in the exception (if one is generated). This could contain passwords and other information that could represent a security vulnerability. Also added a test for this, ensuring that stdout and stderr contain the expected text, and that the password is obscured from the command that is part of the exception. OSSO is aware of this change. Change-Id: I2912ad7efc10b065c954fd198325305f81a8c6ec Closes-Bug: #1343604 SecurityImpact: From gerrit2 at review.openstack.org Mon Jul 21 13:23:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 21 Jul 2014 13:23:48 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I2912ad7efc10b065c954fd198325305f81a8c6ec Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/108215 Log: commit 6aa696cba21fc2b45c940958a0569e8ed995a496 Author: Amrith Kumar Date: Sat Jul 19 19:15:48 2014 -0400 Mask any password in exception command string Currently the command executed by processutils.execute is included in the exception (if one is generated). This could contain passwords and other information that could represent a security vulnerability. Also added a test for this, ensuring that stdout and stderr contain the expected text, and that the password is obscured from the command that is part of the exception. OSSO is aware of this change. Change-Id: I2912ad7efc10b065c954fd198325305f81a8c6ec Closes-Bug: #1343604 SecurityImpact: From gerrit2 at review.openstack.org Mon Jul 21 17:43:23 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 21 Jul 2014 17:43:23 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 1954a0d4e62d1950700f52d05d7a2f7070a91ef3 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Mon Jul 21 22:33:42 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 21 Jul 2014 22:33:42 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/103736 Log: commit 181075ba9d0ebccc7db9f10a2193e104c73eec95 Author: guang-yee Date: Mon Jun 30 22:38:50 2014 -0700 X.509 SSL certificate authentication plugin Add a plugin for X.509 SSL certification authentication. This is similar to Kerberos auth plugin. It must be used in conjunction with Apache mod_ssl. DocImpact SecurityImpact Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 From gerrit2 at review.openstack.org Tue Jul 22 02:58:20 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 22 Jul 2014 02:58:20 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I2912ad7efc10b065c954fd198325305f81a8c6ec Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/108215 Log: commit 25a29c2a6c74b9819fe37e14ac2dfc308e93d6d3 Author: Amrith Kumar Date: Sat Jul 19 19:15:48 2014 -0400 Mask any password in exception command string Currently the command executed by processutils.execute is included in the exception (if one is generated). This could contain passwords and other information that could represent a security vulnerability. Also added a test for this, ensuring that stdout and stderr contain the expected text, and that the password is obscured from the command that is part of the exception. Before merging this change into other projects, it is important to understand that the command being returned in a ProcessExecutionError exception (should one be thrown) is one where passwords will have been masked using strutils.mask_password(). Therefore the command may no longer be executable. This may break some existing code that may have a construct such as: except ProcessExecutionError as err: # retry the command processutils.execute(err.cmd) OSSO is aware of this change. DocImpact: The documentation for the execute command should include a note about the change in behavior described in the message as above. SecurityImpact: Change-Id: I2912ad7efc10b065c954fd198325305f81a8c6ec Closes-Bug: #1343604 From gerrit2 at review.openstack.org Tue Jul 22 06:10:50 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 22 Jul 2014 06:10:50 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I695e8deeb89826717ec859461ab2339d8af20805 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/103736 Log: commit b978d176f30d87b1b3947a53fbc9ac4ab20ce2f8 Author: guang-yee Date: Mon Jun 30 22:38:50 2014 -0700 X.509 SSL certificate authentication plugin Add a plugin for X.509 SSL certification authentication. This is similar to Kerberos auth plugin. It must be used in conjunction with Apache mod_ssl. DocImpact SecurityImpact Change-Id: I695e8deeb89826717ec859461ab2339d8af20805 From 1335208 at bugs.launchpad.net Tue Jul 22 07:05:36 2014 From: 1335208 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 22 Jul 2014 07:05:36 -0000 Subject: [Openstack-security] [Bug 1335208] Re: Shell injection possibility in cmd/control.py References: <20140627163123.19133.62950.malonedeb@gac.canonical.com> Message-ID: <20140722070536.20439.42560.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/108127 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=63c606f696170ebf0a38e7650b242c0727342547 Submitter: Jenkins Branch: master commit 63c606f696170ebf0a38e7650b242c0727342547 Author: tmcpeak Date: Fri Jul 18 11:23:16 2014 -0700 Security hardening: fix possible shell injection vulnerability The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. The fix is to parameterize the input so that the command run here can only be 'logger'. Change-Id: If48106ceea1dd582bcec9d03e056d88591bcba8d Closes-bug: 1335208 ** Changed in: glance Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1335208 Title: Shell injection possibility in cmd/control.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in OpenStack Security Advisories: Invalid Bug description: The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. This may not be a major security concern at this time because the only place that I found for 'server' to come from is a Glance configuration file, which should be locked down. Only privileged users should have write access to the config file, and if they want to do bad things on the system there are easier ways. Still, 'shell=True' appears to be completely unnecessary for this call. Simply omitting the shell parameter here will cause it to revert to the default behavior, which requires that the command to be run be specified in a separate parameter than the arguments to the command. This effectively prevents shell injection vulnerabilities. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1335208/+subscriptions From gerrit2 at review.openstack.org Tue Jul 22 15:39:52 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 22 Jul 2014 15:39:52 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit f040bf827db19cb77e106c4b27ab7cd85b4c561b Author: Daniel Genin Date: Tue Jul 22 09:22:27 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From 1334926 at bugs.launchpad.net Tue Jul 22 19:19:38 2014 From: 1334926 at bugs.launchpad.net (Kyle Mestery) Date: Tue, 22 Jul 2014 19:19:38 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140722191940.9350.20746.launchpad@gac.canonical.com> ** Changed in: neutron Milestone: juno-2 => juno-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: In Progress Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From gerrit2 at review.openstack.org Tue Jul 22 22:31:29 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 22 Jul 2014 22:31:29 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit fc7e6c9828087b5a561f5c0c0292d0959333231a Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Tue Jul 22 23:42:40 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 22 Jul 2014 23:42:40 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I2912ad7efc10b065c954fd198325305f81a8c6ec Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/108215 Log: commit fc1e98e5326f1671bca4853f765040b3add07b71 Author: Amrith Kumar Date: Sat Jul 19 19:15:48 2014 -0400 Mask any password in exception command string Currently the command executed by processutils.execute is included in the exception (if one is generated). This could contain passwords and other information that could represent a security vulnerability. Also added a test for this, ensuring that stdout and stderr contain the expected text, and that the password is obscured from the command that is part of the exception. Before merging this change into other projects, it is important to understand that the command being returned in a ProcessExecutionError exception (should one be thrown) is one where passwords will have been masked using strutils.mask_password(). Therefore the command may no longer be executable. This may break some existing code that may have a construct such as: except ProcessExecutionError as err: # retry the command processutils.execute(err.cmd) OSSO is aware of this change. DocImpact: The documentation for the execute command should include a note about the change in behavior described in the message as above. SecurityImpact: Change-Id: I2912ad7efc10b065c954fd198325305f81a8c6ec Closes-Bug: #1343604 From 1004114 at bugs.launchpad.net Wed Jul 23 00:29:23 2014 From: 1004114 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 23 Jul 2014 00:29:23 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140723002925.9483.80169.launchpad@gac.canonical.com> ** Changed in: python-keystoneclient Assignee: Brant Knudson (blk-u) => Jamie Lennox (jamielennox) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From 1335208 at bugs.launchpad.net Wed Jul 23 14:06:07 2014 From: 1335208 at bugs.launchpad.net (Russell Bryant) Date: Wed, 23 Jul 2014 14:06:07 -0000 Subject: [Openstack-security] [Bug 1335208] Re: Shell injection possibility in cmd/control.py References: <20140627163123.19133.62950.malonedeb@gac.canonical.com> Message-ID: <20140723140610.8374.39622.launchpad@soybean.canonical.com> ** Changed in: glance Status: Fix Committed => Fix Released ** Changed in: glance Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1335208 Title: Shell injection possibility in cmd/control.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. This may not be a major security concern at this time because the only place that I found for 'server' to come from is a Glance configuration file, which should be locked down. Only privileged users should have write access to the config file, and if they want to do bad things on the system there are easier ways. Still, 'shell=True' appears to be completely unnecessary for this call. Simply omitting the shell parameter here will cause it to revert to the default behavior, which requires that the command to be run be specified in a separate parameter than the arguments to the command. This effectively prevents shell injection vulnerabilities. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1335208/+subscriptions From 1335208 at bugs.launchpad.net Wed Jul 23 14:23:40 2014 From: 1335208 at bugs.launchpad.net (Robert Clark) Date: Wed, 23 Jul 2014 14:23:40 -0000 Subject: [Openstack-security] [Bug 1335208] Re: Shell injection possibility in cmd/control.py References: <20140627163123.19133.62950.malonedeb@gac.canonical.com> Message-ID: <20140723142340.9110.81782.malone@gac.canonical.com> I have a general concern around this. In large deployments, the people that configure the service are often not those who run it. Some developers write the configuration files for Glance etc and store them in their chosen config management system, which a 'deployer' later uses to deploy the service etc. Due to this separation of concerns there is possibility for an attacker who does not have production access (ie some developer) to gain it through abuse of a cmd injection vulnerability such as this one. The risk is pretty low and I have no objection to this being opened up for public review but it's worth keeping in mind that it's entirely possible that your admin-owned config files running in production were crafted by developers without production access... -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1335208 Title: Shell injection possibility in cmd/control.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: The glance/cmd/control.py file contains a possible shell injection vulnerability: https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134 . Setting 'shell=True' here opens the possibility of shell injection by setting server to something like '; rm -rf /'. This will cause the command 'rm -rf /' to be run with the privileges of the user that ran Glance. This may not be a major security concern at this time because the only place that I found for 'server' to come from is a Glance configuration file, which should be locked down. Only privileged users should have write access to the config file, and if they want to do bad things on the system there are easier ways. Still, 'shell=True' appears to be completely unnecessary for this call. Simply omitting the shell parameter here will cause it to revert to the default behavior, which requires that the command to be run be specified in a separate parameter than the arguments to the command. This effectively prevents shell injection vulnerabilities. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1335208/+subscriptions From 1334938 at bugs.launchpad.net Wed Jul 23 15:00:24 2014 From: 1334938 at bugs.launchpad.net (Russell Bryant) Date: Wed, 23 Jul 2014 15:00:24 -0000 Subject: [Openstack-security] [Bug 1334938] Re: established floating ip connection won't get disconnected after disassociating floating ip References: <20140627031928.26375.32794.malonedeb@wampee.canonical.com> Message-ID: <20140723150028.20470.84381.launchpad@wampee.canonical.com> ** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334938 Title: established floating ip connection won't get disconnected after disassociating floating ip Status in OpenStack Compute (Nova): Fix Released Bug description: Established connections via floating ip won't get disconnected after we disassociating that floating ip. As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to remove_floating_ip. https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334938/+subscriptions From 1320028 at bugs.launchpad.net Wed Jul 23 15:07:52 2014 From: 1320028 at bugs.launchpad.net (Russell Bryant) Date: Wed, 23 Jul 2014 15:07:52 -0000 Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140723150755.32484.54865.launchpad@chaenomeles.canonical.com> ** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From gerrit2 at review.openstack.org Wed Jul 23 15:36:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 23 Jul 2014 15:36:37 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 07e7ba2ad3f208ea6fff9254ce73a1828e6b37f5 Author: Daniel Genin Date: Wed Jul 23 11:36:14 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From 1336225 at bugs.launchpad.net Wed Jul 23 16:00:37 2014 From: 1336225 at bugs.launchpad.net (Russell Bryant) Date: Wed, 23 Jul 2014 16:00:37 -0000 Subject: [Openstack-security] [Bug 1336225] Re: Password is exposed in the log file References: <20140701103304.7888.77002.malonedeb@wampee.canonical.com> Message-ID: <20140723160040.20827.90759.launchpad@wampee.canonical.com> ** Changed in: heat Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1336225 Title: Password is exposed in the log file Status in Orchestration API (Heat): Fix Released Bug description: heat-keystone-setup-domain is logging the password to the log file. This defect is filed to remove the logging statement as its security concerns To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1336225/+subscriptions From gerrit2 at review.openstack.org Wed Jul 23 17:51:56 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 23 Jul 2014 17:51:56 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 47f73aa02e98f6c98afbe012fc201cd956cefaf4 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1308727 at bugs.launchpad.net Wed Jul 23 19:36:10 2014 From: 1308727 at bugs.launchpad.net (Russell Bryant) Date: Wed, 23 Jul 2014 19:36:10 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140723193613.8854.49618.launchpad@soybean.canonical.com> ** Changed in: horizon Status: Fix Committed => Fix Released ** Changed in: horizon Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) havana series: Fix Committed Status in OpenStack Dashboard (Horizon) icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From gerrit2 at review.openstack.org Wed Jul 23 21:07:58 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 23 Jul 2014 21:07:58 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie1a0c286ff7e513cd964d4a93855230c78b98c6c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/109120 Log: commit f83a8ce9eca018b9c31c48d602e0822752ad217c Author: Nathan Kinder Date: Wed Jul 23 12:06:22 2014 -0700 Trust unit tests should target additional threat scenarios This adds unit tests for two threat scenarios around the trust functionality that are not currently tested. The first scenario is related to deletion of a grant that has been previously delegated via a trust. We need to ensure that executing a trust for a role that the trustor no longer has is rejected. The second scenario is related to an attempt to use a trust token with impersonation to execute another trust as the impersonated user. We need to ensure that a trust token can't be used to execute another trust. SecurityImpact Closes-Bug: #1347909 Change-Id: Ie1a0c286ff7e513cd964d4a93855230c78b98c6c From 1320028 at bugs.launchpad.net Wed Jul 23 21:04:33 2014 From: 1320028 at bugs.launchpad.net (Russell Bryant) Date: Wed, 23 Jul 2014 21:04:33 -0000 Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140723210437.627.99002.launchpad@chaenomeles.canonical.com> ** Changed in: oslo Status: Fix Committed => Fix Released ** Changed in: oslo Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Released Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From 1004114 at bugs.launchpad.net Wed Jul 23 23:58:30 2014 From: 1004114 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 23 Jul 2014 23:58:30 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140723235833.32453.74094.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Assignee: Jamie Lennox (jamielennox) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Thu Jul 24 00:20:46 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 24 Jul 2014 00:20:46 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie1a0c286ff7e513cd964d4a93855230c78b98c6c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/109120 Log: commit 9a40c92a3f561470dea13ce844133604a630df87 Author: Nathan Kinder Date: Wed Jul 23 12:06:22 2014 -0700 Trust unit tests should target additional threat scenarios This adds unit tests for two threat scenarios around the trust functionality that are not currently tested. The first scenario is related to deletion of a grant that has been previously delegated via a trust. We need to ensure that executing a trust for a role that the trustor no longer has is rejected. The second scenario is related to an attempt to use a trust token with impersonation to execute another trust as the impersonated user. We need to ensure that a trust token can't be used to execute another trust. SecurityImpact Closes-Bug: #1347909 Change-Id: Ie1a0c286ff7e513cd964d4a93855230c78b98c6c From 1175904 at bugs.launchpad.net Thu Jul 24 12:11:08 2014 From: 1175904 at bugs.launchpad.net (Russell Bryant) Date: Thu, 24 Jul 2014 12:11:08 -0000 Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password MAX_PASSWORD_LENGTH password truncation References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140724121112.20381.10517.launchpad@wampee.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): Fix Released Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From 1319639 at bugs.launchpad.net Thu Jul 24 12:25:05 2014 From: 1319639 at bugs.launchpad.net (Russell Bryant) Date: Thu, 24 Jul 2014 12:25:05 -0000 Subject: [Openstack-security] [Bug 1319639] Re: Standard random number generators (using shuffle ) should not be used to generate randomness References: <20140515051014.31551.82176.malonedeb@soybean.canonical.com> Message-ID: <20140724122507.32453.23379.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319639 Title: Standard random number generators (using shuffle ) should not be used to generate randomness Status in Cinder: Fix Released Bug description: In cinder code : /cinder/utils.py . Below two lines of code used shuffle to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it?  # If length < len(symbolgroups), the leading characters will only  # be from the first length groups. Try our best to not be predictable  # by shuffling and then truncating.  r.shuffle(password) ----------------> This line of code has described issue.  password = password[:length]  length -= len(password) # finally shuffle to ensure first x characters aren't from a # predictable group r.shuffle(password) ----------------> This line of code has described issue. return ''.join(password) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319639/+subscriptions From gerrit2 at review.openstack.org Thu Jul 24 14:50:14 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 24 Jul 2014 14:50:14 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change I3dabb94ab047e86b8730e73416c1a1c333688489 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/101792 Log: commit 0e9ecaa1547306f7af6527126fb88f8151908498 Author: Jamie Lennox Date: Wed Jun 18 10:22:10 2014 +1000 Don't log sensitive auth data Add the ability to turn off logging from the session object and then handle logging of auth requests within their own sections. This is a very simplistic ability to completely disable logging. Logging more filtered debugging can be added later. This new ability is utilized in this patch to prevent logging of requests that include passwords. This covers authenticate, password change, and user update requests that include passwords. SecurityImpact Change-Id: I3dabb94ab047e86b8730e73416c1a1c333688489 Closes-Bug: #1004114 Closes-Bug: #1327019 From bdpayne at acm.org Thu Jul 24 17:57:44 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 24 Jul 2014 17:57:44 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140724175744.32689.25153.malone@chaenomeles.canonical.com> Sorry that I'm a little late to the party here. I was just made aware of this issue today. Bottom line is that I strongly believe that this should be an OSSA. Security controls are expected to be in place and they are not. That is pretty clear cut to me. The fact that this takes an uncommon path to happen shouldn't mitigate that. I see that the discussion went back and forth above. And perhaps it's too late to do anything. But, if not, I would encourage reopening an OSSA on this issue. Thanks! -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From gerrit2 at review.openstack.org Thu Jul 24 18:09:10 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 24 Jul 2014 18:09:10 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 904c0f31baf4719c9d3e55bbb32854751919d0ad Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1004114 at bugs.launchpad.net Thu Jul 24 21:31:00 2014 From: 1004114 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 24 Jul 2014 21:31:00 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140724213101.20624.92442.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/101792 Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=0e9ecaa1547306f7af6527126fb88f8151908498 Submitter: Jenkins Branch: master commit 0e9ecaa1547306f7af6527126fb88f8151908498 Author: Jamie Lennox Date: Wed Jun 18 10:22:10 2014 +1000 Don't log sensitive auth data Add the ability to turn off logging from the session object and then handle logging of auth requests within their own sections. This is a very simplistic ability to completely disable logging. Logging more filtered debugging can be added later. This new ability is utilized in this patch to prevent logging of requests that include passwords. This covers authenticate, password change, and user update requests that include passwords. SecurityImpact Change-Id: I3dabb94ab047e86b8730e73416c1a1c333688489 Closes-Bug: #1004114 Closes-Bug: #1327019 ** Changed in: python-keystoneclient Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: Fix Committed Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Thu Jul 24 21:46:41 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 24 Jul 2014 21:46:41 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie1a0c286ff7e513cd964d4a93855230c78b98c6c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/109120 Log: commit 391f794fdd5470c066e2d29a9b4a5e0c69f4e907 Author: Nathan Kinder Date: Wed Jul 23 12:06:22 2014 -0700 Trust unit tests should target additional threat scenarios This adds unit tests for two threat scenarios around the trust functionality that are not currently tested. The first scenario is related to deletion of a grant that has been previously delegated via a trust. We need to ensure that executing a trust for a role that the trustor no longer has is rejected. The second scenario is related to an attempt to use a trust token with impersonation to execute another trust as the impersonated user. We need to ensure that a trust token can't be used to execute another trust. SecurityImpact Closes-Bug: #1347909 Change-Id: Ie1a0c286ff7e513cd964d4a93855230c78b98c6c From nkinder at redhat.com Thu Jul 24 21:56:12 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 24 Jul 2014 21:56:12 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140724215613.9414.87354.malone@gac.canonical.com> We should write an OSSN for this so people are aware of the fact that passwords for users will be logged in Horizon if debug logging is enabled. Now that a keystoneclient patch has been merged, we will soon have a release that doesn't log passwords anymore. We should recommend using the newer keystoneclient as soon as it's available. ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossn Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: Fix Committed Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Thu Jul 24 22:08:28 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 24 Jul 2014 22:08:28 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit ed0a632dad4abcdccd0815a7f675708fb010a554 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From nkinder at redhat.com Fri Jul 25 01:54:35 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 24 Jul 2014 18:54:35 -0700 Subject: [Openstack-security] IMPORTANT: OpenStack Security Notes - Repository Migration Message-ID: <53D1B8DB.9010608@redhat.com> Hi, I am in the process of migrating the openstack-security-notes repository[1] that we use for OSSNs to the security-doc repository[2] where the Security Guide is kept. This has been discussed numerous times in our weekly meetings, so hopefully the effort is not a surprise to anyone. The main reasons for the move are: - Automatically publishing OSSNs into an appendix of the Security Guide should be much easier. - We can hook into the existing documentation gate tests more easily since they are already used by the new repository. - IRC channel notifications are already set up for the new repository. During this cut-over period, I would like to halt the creation of any new OSSN patches. This should be a short window. I would like to wrap up the existing notes that are in-progress: OSSN-0020 - https://review.openstack.org/106837 OSSN-0021 - https://review.openstack.org/107426 OSSN-0022 - https://review.openstack.org/108349 After these are merged, I will sync them into the patch I've prepared to switch repositories[3]. I will then clear out the old repository and get it removed to prevent confusion. We will start using the new repository for OSSN-0023. So, if you're working on one of the OSSNs that's in-progress, let's hurry and get it wrapped up! :) If you're not an author of one of these in-progress notes, please review them to help get them finished. Please let me know if you have any questions or concerns! Thanks, -NGK [1] https://git.openstack.org/cgit/openstack/openstack-security-notes/ [2] https://git.openstack.org/cgit/openstack/security-doc/ [3] https://review.openstack.org/109464 From 1004114 at bugs.launchpad.net Fri Jul 25 02:44:45 2014 From: 1004114 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 25 Jul 2014 02:44:45 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140725024448.32391.71408.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Milestone: None => 0.10.1 ** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: Fix Released Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From 1004114 at bugs.launchpad.net Fri Jul 25 03:22:13 2014 From: 1004114 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 25 Jul 2014 03:22:13 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140725032213.9582.13663.malone@gac.canonical.com> keystoneclient 0.10.1 was released with the password logging fix: https://launchpad.net/python-keystoneclient/+milestone/0.10.1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: Fix Released Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From fungi at yuggoth.org Sat Jul 26 00:28:24 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 26 Jul 2014 00:28:24 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140726002824.14013.37734.malone@chaenomeles.canonical.com> I think the counterargument is that you shouldn't be able to "reboot" an instance which is in a down state, and safety checks were added in Icehouse to prevent exactly that. The issue arises if you're running Havana or earlier and don't realize you shouldn't reboot a down instance, in which case it gets brought up with no filtering (because reboot assumes it was already running and doesn't reapply them). So essentially if you do something you're not supposed to do, you can leave instances vulnerable--this requires a mistake on the part of an inexperienced operator, or a fairly significant amount of social engineering on the part of an attacker to convince the operator to make such an error, and has since been hardened in subsequent Nova releases anyway. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From fungi at yuggoth.org Sat Jul 26 00:31:42 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 26 Jul 2014 00:31:42 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140726003142.4524.73613.malone@gac.canonical.com> Also, to issue an OSSA, we'd need a stable backport of the enforcement which was added in Icehouse (a behavioral change so far deemed unsafe for introduction into a stable branch) or some other hotfix which is less impacting on existing behaviors in Havana. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): New Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From fungi at yuggoth.org Sat Jul 26 00:41:31 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 26 Jul 2014 00:41:31 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140726004131.4325.7792.malone@gac.canonical.com> The only current known weakness in MD5 is a hash collision--the ability for an attacker to pick (with some effort) two inputs which hash to the same value. In what way do you see this posing a risk to Trove's use of MD5 for stream validation? Also, I agree with your bug description calling this out specifically as a hardening measure, something for which we should not issue a security advisory. ** Tags added: security ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): New Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From gerrit2 at review.openstack.org Sat Jul 26 03:50:45 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 26 Jul 2014 03:50:45 +0000 Subject: [Openstack-security] [openstack/swift] SecurityImpact review request change I0a13d6d44cd1abc4b66fa33f39eea407617a01d5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/109793 Log: commit b69c3f765b48bc3c0d5d5d4606358ab9da1e4a2c Author: Nathan Kinder Date: Fri Jul 25 20:47:11 2014 -0700 Avoid usage of insecure mktemp() function This eliminates usae of the depreceated insecure tempfile.mktemp() function. It has been replaced with the secure alternatives where temporary files are actually required. Change-Id: I0a13d6d44cd1abc4b66fa33f39eea407617a01d5 SecurityImpact Closes-bug: #1348869 From gerrit2 at review.openstack.org Sat Jul 26 05:07:51 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 26 Jul 2014 05:07:51 +0000 Subject: [Openstack-security] [openstack/swift] SecurityImpact review request change I0a13d6d44cd1abc4b66fa33f39eea407617a01d5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/109793 Log: commit 6978275cdb04bb08aaf142d401b52a46527dac4c Author: Nathan Kinder Date: Fri Jul 25 20:47:11 2014 -0700 Avoid usage of insecure mktemp() function This patch eliminates the use of the deprecated and insecure tempfile.mktemp() function. It has been replaced with secure alternatives where temporary files are actually required. Change-Id: I0a13d6d44cd1abc4b66fa33f39eea407617a01d5 SecurityImpact Closes-bug: #1348869 From gerrit2 at review.openstack.org Sun Jul 27 15:55:22 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 27 Jul 2014 15:55:22 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 8e0eadef29938927f5977885984a8fb9f8170e38 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1348339 at bugs.launchpad.net Mon Jul 28 11:57:18 2014 From: 1348339 at bugs.launchpad.net (Robert Clark) Date: Mon, 28 Jul 2014 11:57:18 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728115718.14248.68285.malone@chaenomeles.canonical.com> @Jeremy there are more issues than just collisions in MD5, for a start the search space for an MD5 hash is completely tractable due to rainbow tables, pre-image attacks are also theoretically possible in addition to the collisions you describe. In summary, it's appropriate to use MD5 for corruption checks where there's no possibility of malicious attempts to breach file integrity but this is rarely the case and SHA hashes should probably just replace md5 across the board. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): New Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From bdpayne at acm.org Mon Jul 28 17:44:16 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 28 Jul 2014 17:44:16 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728174416.19755.6779.malone@wampee.canonical.com> +1 to Rob's comment. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): New Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From gerrit2 at review.openstack.org Mon Jul 28 18:20:49 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 18:20:49 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 72e2dc31efd1835fdd1f2f87515fb9ff4d77e365 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL allow a deploy driver to download an image from Glance without requiring an auth_token, which gives access more than just Glance. This requires a set of config options: the Glance endpoint URL, a shared secret temporary key, and the account configured in Glance to talk to Swift with, which owns the container images are stored in. A later patch will explore using the direct_url in Glance to simplify the config options. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Partial Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Mon Jul 28 18:37:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 18:37:02 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit b0b03717ef8bd83d071e9199ec997fd9ff601246 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL allow a deploy driver to download an image from Glance without requiring an auth_token, which gives access more than just Glance. This requires a set of config options: the Glance endpoint URL, a shared secret temporary key, and the account configured in Glance to talk to Swift with, which owns the container images are stored in. A later patch will explore using the direct_url in Glance to simplify the config options. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Partial Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From SlickNik at gmail.com Mon Jul 28 17:52:09 2014 From: SlickNik at gmail.com (Nikhil Manchanda) Date: Mon, 28 Jul 2014 17:52:09 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728175209.14044.90081.malone@chaenomeles.canonical.com> Okay, I took a quick look at the code in Trove, and this _is_ one of the cases where we're using an MD5 hash check to ensure no data corruption has occurred with backup data stored in swift. Since it's not actually being used for any crypto (i.e. encryption / decryption) I don't think this is a high priority security issue, but it would be good for hardening. Triaging the bug, appropriately based on this information. Thanks! ** Changed in: trove Status: New => Triaged ** Changed in: trove Importance: Undecided => Low ** Changed in: trove Milestone: None => ongoing -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From fungi at yuggoth.org Mon Jul 28 18:39:59 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 28 Jul 2014 18:39:59 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728183959.4877.97837.malone@gac.canonical.com> Right, so risky in places where collision and chosen-prefix attacks can be mounted... just trying to ascertain whether the static analysis which highlighted this bug identified an exploitable security vulnerability or just another hardening opportunity. Sounds like the latter. It's worth noting however that similar issues were just pointed out yesterday in rsync (it uses MD5 for identifying alterations to blocks rather than stream integrity, but perhaps a tangentially similar problem space?). http://openwall.com/lists/oss- security/2014/07/28/1http://openwall.com/lists/oss-security/2014/07/28/1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From fungi at yuggoth.org Mon Jul 28 18:40:49 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 28 Jul 2014 18:40:49 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728184049.14345.43718.malone@chaenomeles.canonical.com> Gah, my paste button is bouncing lately... http://openwall.com/lists /oss-security/2014/07/28/1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From eric.hibbard at hds.com Mon Jul 28 19:06:35 2014 From: eric.hibbard at hds.com (Eric Hibbard) Date: Mon, 28 Jul 2014 19:06:35 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728190635.19421.51439.malone@wampee.canonical.com> Something to consider...when a crypto algorithm/function is used for what is perceived to be a non-crypto use, it introduces a bunch of baggage and should be part of the overall decision process. Some organizations are taking a VERY hard line when it comes to the use of things like MD5, SHA-1, RC4, etc. A generic question gets asked as to whether the code/application uses certain banned algorithms. If the answer is "yes" then its use is not permitted within the organization unless a waiver is approved (may not be an option). In such a scenario, the person wanting to use the code is put in the position of justifying the waiver and "accepting" the risks...often considered a career limiting move. I've also see crypto issues used as a way of down- selecting choices (vendor, code bases etc.). It seems prudent to just make this problem go away by replacing MD5 with SHA-2, especially when we've found it. Coming back later to find these because of a data breach or other problem can be a massive waste of time. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From bknudson at us.ibm.com Mon Jul 28 19:09:45 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Mon, 28 Jul 2014 19:09:45 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140728190945.19285.40099.malone@wampee.canonical.com> I tried this with the keystone command and passwords and tokens are still being printed. $ keystone --debug user-list DEBUG:keystoneclient.session:REQ: curl -i -X POST http://localhost:5000/v2.0/tokens -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -d '{"auth": {"tenantName": "demo", "passwordCredentials": {"username": "admin", "password": "mypassword"}}}' ... RESP BODY: {"access": {"token": {"issued_at": "2014-07-28T19:08:05.637184", "expires": "2014-07-28T20:08:05Z", "id": "PKIZ_", ... ... DEBUG:keystoneclient.session:REQ: curl -i -X GET http://192.168.122.176:35357/v2.0/users -H "User-Agent: python-keystoneclient" -H "X-Auth-Token: PKIZ_" ** Changed in: python-keystoneclient Status: Fix Released => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: Confirmed Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From bknudson at us.ibm.com Mon Jul 28 19:18:27 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Mon, 28 Jul 2014 19:18:27 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140728191828.19098.21175.malone@wampee.canonical.com> I wasn't running with the fix so was getting the passwords. With the fix the token is still printed. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: Confirmed Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From bdpayne at acm.org Mon Jul 28 19:32:16 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 28 Jul 2014 19:32:16 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728193216.19421.7922.malone@wampee.canonical.com> I pretty much agree with all that has been said. We should fix it. SHA-2 makes the most sense today. And fixing it as a general hardening measure, rather than an OSSA makes sense. To the point of wanting to just get all bad crypto algorithms out of these code bases... the OSSG is working on some gate tools that would catch such things. Once those are put in place, it should be much easier to prevent this kind of thing from happening in the future :-) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From gerrit2 at review.openstack.org Mon Jul 28 19:57:20 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 19:57:20 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change I1edc3821ed028471102cc9b95eb9f3b54c9e2778 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/110117 Log: commit bc0962167248a7c5a50ae19a530f54b558f611bf Author: Brant Knudson Date: Mon Jul 28 14:34:53 2014 -0500 Redact tokens in request headers Tokens shouldn't be logged since a token could be gathered from a log file and used. The client was logging the X-Auth-Token and X-Subject-Token request headers. With this change, the X-Auth-Token and X-Subject-Token are shown as "TOKEN_REDACTED". This is for security hardening. SecurityImpact Closes-Bug: #1004114 Closes-Bug: #1327019 Change-Id: I1edc3821ed028471102cc9b95eb9f3b54c9e2778 From 1004114 at bugs.launchpad.net Mon Jul 28 19:57:17 2014 From: 1004114 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 28 Jul 2014 19:57:17 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140728195718.27011.55848.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/110117 ** Changed in: python-keystoneclient Status: Confirmed => In Progress ** Changed in: python-keystoneclient Assignee: Nathan Kinder (nkinder) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Mon Jul 28 21:16:35 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 21:16:35 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 77f067d38deed043956c30cbf40122832748857b Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL allow a deploy driver to download an image from Glance without requiring an auth_token, which gives access more than just Glance. This requires a set of config options: the Glance endpoint URL, a shared secret temporary key, and the account configured in Glance to talk to Swift with, which owns the container images are stored in. A later patch will explore using the direct_url in Glance to simplify the config options. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Partial Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Mon Jul 28 23:12:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 23:12:48 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 96573df180a4de1208da42daedc9717f72b8000b Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL allow a deploy driver to download an image from Glance without requiring an auth_token, which gives access more than just Glance. This requires a set of config options: the Glance endpoint URL, a shared secret temporary key, and the account configured in Glance to talk to Swift with, which owns the container images are stored in. A later patch will explore using the direct_url in Glance to simplify the config options. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Partial Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Mon Jul 28 23:17:57 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 23:17:57 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 2e3608b098ffe6af6cee03cf6f2789b72ba86b44 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL allow a deploy driver to download an image from Glance without requiring an auth_token, which gives access more than just Glance. This requires a set of config options: the Glance endpoint URL, a shared secret temporary key, and the account configured in Glance to talk to Swift with, which owns the container images are stored in. A later patch will explore using the direct_url in Glance to simplify the config options. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Partial Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Mon Jul 28 23:20:05 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 28 Jul 2014 23:20:05 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit e2eaaaf1b50a2088b9f9205cb31a0499a6a7d1f5 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL allow a deploy driver to download an image from Glance without requiring an auth_token, which gives access more than just Glance. This requires a set of config options: the Glance endpoint URL, a shared secret temporary key, and the account configured in Glance to talk to Swift with, which owns the container images are stored in. A later patch will explore using the direct_url in Glance to simplify the config options. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift performance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Partial Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1348339 at bugs.launchpad.net Tue Jul 29 07:04:03 2014 From: 1348339 at bugs.launchpad.net (Robert Clark) Date: Tue, 29 Jul 2014 07:04:03 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140729070403.14479.97927.malone@chaenomeles.canonical.com> +1 to Bryan and Eric Many enterprise customers are requesting to see our crypto audits - there's only so many times you can explain "Yes, but, MD5 is pretty much o.k in this context" before you start looking silly. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From schang at tesora.com Mon Jul 28 19:40:59 2014 From: schang at tesora.com (Simon Chang) Date: Mon, 28 Jul 2014 19:40:59 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140728194101.4493.45031.launchpad@gac.canonical.com> ** Changed in: trove Assignee: (unassigned) => Simon Chang (changsimon) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From 1004114 at bugs.launchpad.net Tue Jul 29 15:46:58 2014 From: 1004114 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 29 Jul 2014 15:46:58 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140729154658.19786.73371.malone@wampee.canonical.com> Can we just remove the curl examples? I don't understand their utility if they're not valid. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From fungi at yuggoth.org Tue Jul 29 20:44:55 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 29 Jul 2014 20:44:55 -0000 Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work with vip and ovs plugin References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20140729204456.5055.90889.launchpad@gac.canonical.com> ** Tags added: security ** No longer affects: ossa ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1163569 Title: security groups don't work with vip and ovs plugin Status in OpenStack Neutron (virtual network service): In Progress Bug description: http://codepad.org/xU8G4s00 I pinged nachi and he suggested to try using: interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver But after setting this it seems like the vip does not work at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1163569/+subscriptions From fungi at yuggoth.org Tue Jul 29 21:03:15 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 29 Jul 2014 21:03:15 -0000 Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work with vip and ovs plugin References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20140729210315.4271.90728.malone@gac.canonical.com> It sounds like there's no need for the VMT to issue a security advisory, but it does seem like something the OSSG might be interested in documenting more visibly so I've tagged it to the ML in case they do. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1163569 Title: security groups don't work with vip and ovs plugin Status in OpenStack Neutron (virtual network service): In Progress Bug description: http://codepad.org/xU8G4s00 I pinged nachi and he suggested to try using: interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver But after setting this it seems like the vip does not work at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1163569/+subscriptions From ishakhat at mirantis.com Tue Jul 29 15:42:31 2014 From: ishakhat at mirantis.com (Ilya Shakhat) Date: Tue, 29 Jul 2014 15:42:31 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140729154231.19555.34412.malone@wampee.canonical.com> Roman, can you try to do repro once again? The issue should be fixed by https://review.openstack.org/#/c/101447/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Incomplete Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1163569 at bugs.launchpad.net Wed Jul 30 09:23:55 2014 From: 1163569 at bugs.launchpad.net (Robert Clark) Date: Wed, 30 Jul 2014 09:23:55 -0000 Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work with vip and ovs plugin References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20140730092355.4617.56625.malone@gac.canonical.com> Could be OSSN worthy, I'll throw it on our queue for discussion. ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1163569 Title: security groups don't work with vip and ovs plugin Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: New Bug description: http://codepad.org/xU8G4s00 I pinged nachi and he suggested to try using: interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver But after setting this it seems like the vip does not work at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1163569/+subscriptions From geekinutah at gmail.com Wed Jul 30 18:00:34 2014 From: geekinutah at gmail.com (Michael H Wilson) Date: Wed, 30 Jul 2014 18:00:34 -0000 Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session token in URL and insecurely sets the session cookie References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <20140730180034.19190.53527.malone@wampee.canonical.com> @parthipan and Paul Murray Do you guys have a newer version of this patch? I keep starting to try and apply this to trunk and then getting lost. If you have it around it would be awesome to see it submitted or if you want attach it here and I will put it in. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From schang at tesora.com Wed Jul 30 18:19:21 2014 From: schang at tesora.com (Simon Chang) Date: Wed, 30 Jul 2014 18:19:21 -0000 Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com> Message-ID: <20140730181921.4462.76888.malone@gac.canonical.com> I don't think we can upgrade the code in question from MD5 to SHA256 at the moment. The Swift put_object() call's response has an etag field. This etag field is populated with the MD5 hash for the data segment received by Swift, and it is calculated by Swift. I took a quick look at the Swift code, and don't see evidence of etag hash algorithm being configurable on Swift. This posting is also saying etag is MD5 only: https://answers.launchpad.net/swift/+question/217171 Since MD5 is a constraint imposed by Swift, unless Swift starts to support SHA etags, I don't believe we have other choice at the moment but to stick with MD5 here. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348339 Title: Use of weak MD5 algorithm Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: The file: trove/trove/guestagent/strategies/storage/swift.py line 54 uses a weak hashing algorithm, MD5. It would be pretty simple hardening upgrade to use at least hashlib.SHA256. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1348339/+subscriptions From gerrit2 at review.openstack.org Wed Jul 30 20:12:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 30 Jul 2014 20:12:39 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change I1edc3821ed028471102cc9b95eb9f3b54c9e2778 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/110117 Log: commit 605577192d7158ecf40bd9a94b7cf3acc2ce1c95 Author: Brant Knudson Date: Mon Jul 28 14:34:53 2014 -0500 Redact tokens in request headers Tokens shouldn't be logged since a token could be gathered from a log file and used. The client was logging the X-Auth-Token and X-Subject-Token request headers. With this change, the X-Auth-Token and X-Subject-Token are shown as "TOKEN_REDACTED". Also, the "Authentication" header is also redacted. This is for security hardening. SecurityImpact Closes-Bug: #1004114 Closes-Bug: #1327019 Change-Id: I1edc3821ed028471102cc9b95eb9f3b54c9e2778 From 1004114 at bugs.launchpad.net Thu Jul 31 12:19:10 2014 From: 1004114 at bugs.launchpad.net (Abu Shohel Ahmed) Date: Thu, 31 Jul 2014 12:19:10 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140731121913.13884.33073.launchpad@chaenomeles.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Abu Shohel Ahmed (shohel-csdu) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From robert.clark at hp.com Thu Jul 31 16:37:05 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 31 Jul 2014 16:37:05 +0000 Subject: [Openstack-security] OSSG Meet up and Progress Message-ID: Hi All! As most of you know, we had a meet up of the OSSG a few weeks back, there were various topics covered which you can read more about in the etherpad here: https://etherpad.openstack.org/p/ossg-juno-meetup I just wanted to highlight a few of the great successes that we had and hope to encourage you all to come to our next meet up! * Much of the week was taken up focussing on gate tests as these allow us to demonstrate immediate value to the wider community. At first we started by writing Pep8 checks, much of the prelim work for this was done by Travis (Thanks!) - later we switched focus to a new tool written by Jamie (Chair6) which shows some real promise as a new element in the CI Chain. Application of these checks resulted in us noting and processing some 37 new vulnerabilities in OpenStack - mainly low hanging fruit but a great result! * Lots of attention was paid to developing the threat modelling process, during the walkthrough we found several issues of concern in Keystone (which is where most of the excellent work by Shohel has been done so far) - we learned that we need a way to streamline the process and that we may have to come to terms with not being able to put every project through the process for every release - very valuable time spent here. * The Security Guide has gone through some mammoth changes thanks mainly to Bryan and his team - over 60 new bugs logged against the guide and many new additions - including OpenStack newbies being guided through the gerrit workflow for the first time - excellent work! * Several new OpenStack Security Notes were produced during the week and the process went through some refinement in real time, feedback from new authors was essential to this and we look forward to increasing the number of issued notes and the number of OSSN authors! I wanted to keep the roundup brief, I know how busy you all are. I invite others in the OSSG to reply to this, with their feedback, highs/lows etc. to share with the community. Cheers -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: