yahoo-eng-team team mailing list archive

[Lee Yarwood <lyarwood@xxxxxxxxxx>]

This also impacts os-brick that has recently copied the encryptor
codebase with change :

Copy encryptors from Nova to os-brick
https://review.openstack.org/#/c/247372/

We should really try to remove the Nova encryptors this cycle I
guess....

** Also affects: os-brick
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1633518

Title:
  The passphrase used to encrypt or decrypt volumes was mangled prior to
  Newton

Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New

Bug description:
  Description
  ===========

  tl;dr hex(x) previously stripped leading 0's from individual hex
  numbers while encoding the passphrase back to a hex string before use
  to encrypt/decrypt a luks volume.

  Prior to Newton the following method was used to encode passphrases
  when attempting to use or create a luks volume :

      def _get_passphrase(self, key):
          """Convert raw key to string."""
          return ''.join(hex(x).replace('0x', '') for x in key)

  https://github.com/openstack/nova/blob/82190bdd283dda37f7517fd9a268b5e55183f06c/nova/volume/encryptors/cryptsetup.py#L92-L94

  This was replaced in Newton with the move to Castellan in the
  following change that altered both the decoding and encoding steps :

  Replace key manager with Castellan
  https://review.openstack.org/#/c/309614/

  The original method used the built-in hex() call to convert individual
  unsigned ints back to hex. This would strip the leading 0 from each
  hex digit pair, altering the eventual passphrase used to encrypt or
  decrypt the volume.

  For example, the following one liner represents both the initial
  decode step preformed by ConfKeyManager and the step above to encode
  the passphrase in the LuksEncryptor class :

  >>> ''.join(hex(x).replace('0x', '') for x in array.array('B', '752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'.decode('hex')).tolist())
  '752523eb50c3bf2ba3ff639c2545805fd4e779894ef536e15e081696a'

  Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a
  New string     : 752523eb50c3bf2ba3ff639c25 4 5805fd4e779894ef536 e15e081696a

  The returned string is missing various 0's that have been stripped by
  the hex() call :

  >>> hex(14)
  '0xe'

  >>> int(0x0e)
  14

  >>> int(0xe)
  14

  >>> hex(4)
  '0x4'

  >>> int(0x04)
  4

  >>> int(0x4)
  4

  The following one liner represents the current decode and encode
  steps, producing the same string as is entered :

  >>> import binascii
  >>> binascii.hexlify(bytes(binascii.unhexlify('752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'))).decode('utf-8')
  u'752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'

  Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a
  New string     : 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a

  IMHO the way to handle this is to add a simple retry in master and
  stable/newton when we fail due to a bad passphrase using the mangled
  passphrase.

  We should also improve the testing in this area as it appears all
  previous testing used zero based passphrases, missing this issue when
  it landed in Newton.

  More notes available downstream in the following bug :

  Nova encryption alters the key used
  https://bugzilla.redhat.com/show_bug.cgi?id=1382415

  Steps to reproduce
  ==================
  - Encrypt a volume in Mitaka or earlier.
  - Upgrade to Newton or later.
  - Attempt to use the volume.

  Expected result
  ===============
  Volume is decrypted and usable.

  Actual result
  =============
  Unable to decrypt the volume due to the use of an modified passphrase during initial formatting and use prior to Newton.

  Environment
  ===========
  1. Exact version of OpenStack you are running. See the following
    list for all releases: http://docs.openstack.org/releases/
     Newton and later.
     
  2. Which hypervisor did you use?
     Libvirt

  2. Which storage type did you use?
     N/A

  3. Which networking type did you use?
     (For example: nova-network, Neutron with OpenVSwitch, ...)
     N/A

  Logs & Configs
  ==============
  N/A

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