[Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

Wed Nov 1 16:48:07 UTC 2023

On Wed, Nov 01, 2023 at 02:39:27PM -0000, Adrien Nader wrote:
> This one is indeed not in the SRU at the moment. The description edit
> itself did not make much sense.

(Okay, that's what I thought.  For what it's worth, I noticed afterwards
that the description for LP: #2033422 still has the "four bugs" version
of that sentence.)

> As far as I understand, tinc could fairly easily work around this issue
> by explicitely setting the key size before doing operations. This is the
> safest approach. It might even be faster than waiting for the SRU and
> corresponding phased updates.

Actually this isn't really easy on the Tinc side (at least for
Ubuntu end users).

In particular, the Tinc package actually hasn't changed at all in
several Ubuntu releases, so the big surprise here was that Tinc
1.0.36 on Jammy fails to connect in a network where Tinc 1.0.36
on Focal worked fine (even after making the configuration
adjustments that were expected due to the openssl 1.1 -> 3
transition).

Tinc does not provide any user-level control on these parameters,
and I don't think it even sets the parameters explicitly
internally in the code; rather, it relies on the default settings
for the algorithm, which is what was broken in that brief range
of OpenSSL v3 upstream releases.  (Presumably if it already set
the parameters explicitly then it wouldn't have been affected by
this bug.)

In any case, solving this from the Tinc side would involve
(someone) making a Ubuntu-specific customization to the Tinc
source code -- which seems a lot more fraught than simply using a
fixed libssl3 library...

One thought that occurred to me is the idea of a semi-official
PPA build with this Blowfish patch included in it.
"Semi-official" in that you (or someone involved in the OpenSSL
Ubuntu packaging work) would publish it, building on top of the
official Ubuntu package, and thus it would track any other fixes
that were published to the main OpenSSL Jammy package -- but
since it's in a PPA it would be opt-in for those who need it.

This would be certainly be preferable to me over my current
situation using an "orphan" version of the legacy.so library
file,  but I don't know how much effort it would be to provide
that on your end...

                                                Nathan

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1990216

Title:
  backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL
  1.1 with blowfish in OFB or CFB modes" to Jammy

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug was the fourth in a series of bugs for a single SRU.
  The "central" bug with the global information and debdiff is http://pad.lv/2033422

  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead to decryption issues.

  [Test plan]
  On Focal, run the following and copy the output to your clipboard

      for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" | openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
      tar c pouet.bf-* | xz | base64 -w 60

  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.

  On Jammy, run the following and paste your clipboard

      base64 -d | xz -d | tar x
      for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; done

  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.

  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):

      /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
      8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
      hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
      m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
      D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
      ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
      GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
      AoBQAACjzq5WscRn+wIAAAAABFla

  Here is the same but from Jammy if you want to test encryption on
  Jammy and decryption on Lunar/Mantic:

      /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
      8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
      HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
      jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
      2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
      k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
      /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAAAAAABRzyqPdCqX
      1AABrQKAUAAABh3ynbHEZ/sCAAAAAARZWg==

  The contents are expected to be different due to the use of
  randomness. Don't try to compare the base64 outputs: I'm only using
  them to ease testing across containers.

  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" and search for "Blowfish" for instance) and fixes decryption from an up-to-date Jammy to pretty much everything else, but it also create an issue for data encrypted on Jammy without this patch and Jammy with this patch.

  There are two possible cases: encrypted data being streamed across
  this boundary or data at rest being transferred or read later.

  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's
  only Jammy and not any other OS or distribution).

  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there
  is already an incompatibility at the moment between Jammy and
  everything else and the more time passes by, the more such problematic
  files can be created. Luckily very few people are using blowfish
  nowadays and it's not even enabled by default anymore in openssl.
  Moreover the software update to work around the issue should be a
  single API call which is documented in the upstream bug report (
  https://github.com/openssl/openssl/issues/18359 ). Finally, I have
  warned the two projects that I am aware are impacted; this is made
  easier by the fact that they encountered the initial incompatibility.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/issues/18359

  * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Fix-regression-in-default-key-length-for-Blowfish-CF.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0
  * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Test-the-default-key-length-of-the-Blowfish-ciphers.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  OpenSSL upstream implemented a fix for their issue #18359  "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes"
    https://github.com/openssl/openssl/issues/18359
  as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic).

  Could this fix be backported to libssl3 in Jammy?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216/+subscriptions