[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

Tue Dec 5 00:24:06 UTC 2023

On Mon, Dec 04, 2023 at 04:42:48PM -0000, Adrien Nader wrote:
> The affected code is in libcrypto which I think sees fewer important security
> fixes. Therefore it's possible to build it and put it in your library search
> path. This should fix the issue without being too terrible wrt security
> updates.
[...]
> I'll prepare a PPA on tomorrow with only this change on tomorrow; I will
> probably add a few things to prevent using the package directly however
> since I expect the proper approach would be to 'dpkg -x' the package or
> equivalent and use its libcrypto.so and LD_LIBRARY_PATH or similar
> specifically when needed.

Note that as far as I understand from my own testing, the library file
that is affected by this particular upstream bugfix (OpenSSL
issue #18359/PR #18362) is ossl-modules/legacy.so ... 

... and as such it is possible to work around the bug in the
systemwide libssl3 package copy of that library by 
setting the OPENSSL_MODULES environment variable (rather than
touching LD_LIBRARY_PATH).

(See LP: #1972939 comment 11 for a brief bit of additional detail.)

If you are considering building a PPA to resolve this in Jammy,
here are a few possible approaches I can envision:

A) a "full" libssl3 package that contains the upstream patch applied
   directly to ossl-modules/legacy.so , and would be installed 
   in place of the standard libssl3 package.

B) a "full" libssl3 package (installed in place of the standard
   one) that contains the standard legacy.so file and then also a
   ossl-modules/legacy-fixedBF.so file with a copy of the
   legacy.so library patched by the fix.

C) a "special" libssl3 package (e.g. named libssl3-fixedbf) which
   would contain only the ossl-modules/legacy-fixedBF.so file, and
   would be installed alongside the standard libssl3 package.

The idea behind options B and C is that both the
broken/original-Jammy behavior and the fixed behavior would be
available simultaneously on the system, with the user selecting
which behavior they are looking for based on which module they
load at run time.  In both cases the ossl-modules/ directory
would contain both legacy.so and legacy-fixedBF.so files (once
the PPA package in question was installed).

With option A only the corrected library would be available
(at run time with the PPA package installed), and it would be
found under the standard "legacy" module name.  This would
certainly be the easiest-to-use approach in the Tinc-interop
case, but limits flexibility for sites which need compatibility
with both the default-Jammy and corrected behavior at the same
time.

(The names "legacy-fixBF.so" and "libssl3-fixedbf" just names I
made up to provide these examples; some other scheme like
"legacy-issue18359.so" or whatever would work similarly from the
user's standpoint.)

                                        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 once the fourth in a series of bugs grouped for a single SRU, with
  the "central" bug with the global information and debdiff being http://pad.lv/2033422 .  However, this particular bug is no longer included in that SRU effort.)

  [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