swap volume operation may leak credentials into debug logs

Bug #1685678 reported by Matt Riedemann on 2017-04-24
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
High
Dane Fichter
OpenStack Security Advisory
Undecided
Unassigned

Bug Description

The swap volume code in the compute service logs old and new volume connection_info dicts to debug here:

https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4930

The new connection_info comes from Cinder:

https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4901

That's a plain dict from the response which may contain credentials.

The old connection_info comes from the nova.objects.block_device.BlockDeviceMapping object, which uses SensitiveStringField to sanitize the field's value when logged:

https://github.com/openstack/nova/blob/1ad41c0b0c844b65424251dbc3399039789b064f/nova/compute/manager.py#L4904

https://github.com/openstack/oslo.versionedobjects/blob/1.23.0/oslo_versionedobjects/fields.py#L280

The new connection_info could contain credentials though, so we should mask those when logging it, even at debug level.

Matt Riedemann (mriedem) on 2017-04-24
description: updated

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

Changed in ossa:
status: New → Incomplete
description: updated

If this is only happening at DEBUG level, then it's probably a class B3 according to VMT's taxonomy: https://security.openstack.org/vmt-process.html#incident-report-taxonomy

Matt Riedemann (mriedem) wrote :

Can I post a patch for this in Gerrit or do I need to hold off for now? I can attach a .patch file in here if needed.

Jeremy Stanley (fungi) wrote :

I agree with Tristan's assessment that the VMT won't pursue an advisory in this case, per our long-standing policy about information leaks in DEBUG-level logging, thus there's no need to maintain the embargo and fixes can definitely be reviewed in public. I'm lifting the embargo now and switching this to a potential hardening opportunity.

Matt Riedemann (mriedem) wrote :

Here is an example from the logs in a CI run:

http://logs.openstack.org/94/465794/2/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/688500a/logs/screen-n-cpu.txt.gz#_May_19_22_46_34_664553

{
   u'driver_volume_type':u'iscsi',
   'connector':{
      'platform':'x86_64',
      'host':'ubuntu-xenial-internap-mtl01-8904270',
      'do_local_attach':False,
      'ip':'198.72.124.18',
      'os_type':'linux2',
      'multipath':False,
      'initiator': u'iqn.1993-08.org.debian:01:f5ecd8cdb33f'
   },
   'serial':u'8ab09912-5e7b-4ca4-988b-e5993bfe24f6',
   u'data':{
      u'access_mode':u'rw',
      u'target_discovered':False,
      u'encrypted':False,
      u'qos_specs':None,
      u'target_iqn': u'iqn.2010-10.org.openstack:volume-8ab09912-5e7b-4ca4-988b-e5993bfe24f6',
      u'target_portal': u'198.72.124.18:3260 ', u' volume_id':u'8ab09912-5e7b-4ca4-988b-e5993bfe24f6',
      u'target_lun':1,
      u'auth_password':u'y2UWZPbTLf27A3xV',
      u'auth_username':u'qAAHKzWja6X2yXRBwCym',
      u'auth_method':u'CHAP'
   }
}

Jeremy Stanley (fungi) on 2017-05-21
description: updated
information type: Private Security → Public
Changed in nova:
status: Triaged → Won't Fix
status: Won't Fix → Triaged
Changed in ossa:
status: Incomplete → Won't Fix

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

Changed in nova:
assignee: nobody → Matt Riedemann (mriedem)
status: Triaged → In Progress
Changed in nova:
assignee: Matt Riedemann (mriedem) → Dane Fichter (dane-fichter)
Changed in nova:
assignee: Dane Fichter (dane-fichter) → Matt Riedemann (mriedem)
Changed in nova:
assignee: Matt Riedemann (mriedem) → Dane Fichter (dane-fichter)
Matt Riedemann (mriedem) wrote :
Changed in python-cinderclient:
status: New → Triaged
importance: Undecided → High
Matt Riedemann (mriedem) wrote :

Actually cinderclient should be fixed:

https://review.openstack.org/#/c/395119/

no longer affects: python-cinderclient

Change abandoned by Matt Riedemann (<email address hidden>) on branch: master
Review: https://review.openstack.org/466533
Reason: Looks like it was fixed under a different bug https://review.openstack.org/#/c/558694/

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers