[Bug 1979639] Re: Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Thu Jul 14 16:19:24 UTC 2022

On Thu, Jul 14, 2022 at 03:56:04PM -0000, David Zuelke wrote:
> So I think a big class of programs to consider that are affected by this
> potentially are those that use a statically linked OpenSSL v1, not just
> Node.js or any leftover programs that dynamically link against
> libssl1.1.
> 
> And that's... a lot of software off the internet ;)

This is true. Maybe we need to be pragmatic about this type of case. I'd
like to see some data on what's actually affected though.

Regardless, such programs are buggy. They're not properly built if they
have a dependency on the system /etc by assuming libssl1.1 is available
on the system like this. This is a perfect demonstration of how merely
asking the linker to link statically does not result in a properly
independent binary.

In our ecosystem it's pretty unusual for there to be an expectation that
binaries will continue working following distribution release upgrades
like this, and if they don't, usually the third party distributor is
expected to produce a fixed binary. And if we do choose to maintain
compatibility, then this stifles improvements. What's the time limit for
backwards incompatibility like this? Usually a major distribution
release upgrade is the appropriate time to make these kinds of breaking
changes.

I have no issue with pragmatically arranging the configuration to be
backwards compatible for a while. But the time to do this is before
release. Doing it after is much riskier, and so we should be more
cautious. The people affected who want the change are not the people who
would be affected and be forced to deal with any fallout.

So how big is this impact really? That's why I'd like to see the
evidence.

-- 
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/1979639

Title:
  Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Incomplete
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact] 
  While the default configuration works fine for every package that uses the system libssl3, any software that uses libssl1.1, either separately packaged (e.g. as an upgrade leftover) or vendored in (as in nodejs in our own archive) will fail to load the configuration as they don't have any notion of providers.

  If the provider section isn't present in the configuration, libssl3
  will load the default provider, which means that commenting out the
  section won't impact the behavior of standard libssl3 users.

  [Test Plan]

  On a system with a pristine openssl configuration:

  $ sudo apt install nodejs
  $ nodejs - <<EOF
  var crypto = require('crypto')
  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 2048 });
  var sign = crypto.createSign('RSA-SHA256');
  sign.update(Buffer.from("hello"));
  sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}));
  EOF

  Without the fix, the nodejs execution will have a non-zero return code and an uncaught exception with the following line:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the shared library

  With the fix, there shouldn't be any output, and an exit code of 0.

  [Where problems could occur]

  There could easily be user errors when trying to merge the new
  configuration, for instance if they enabled the legacy provider, as
  they might comment out the default provider loading section (which is
  necessary if any other provider is explicitly loaded).

  [Other Info]

  Dear SRU team, please do not move this from -proposed to -updates before 
  the apt phasing fix has reached it first:
  https://bugs.launchpad.net/charm-mysql-innodb-cluster/+bug/1979244

  [Original report]
  ~ $ lsb-release -a
  No LSB modules are available.
  Distributor ID:	Ubuntu
  Description:	Ubuntu 22.04 LTS
  Release:	22.04
  Codename:	jammy

  https://launchpad.net/debian/+source/openssl/3.0.3-7 includes a single
  change,
  https://sources.debian.org/src/openssl/3.0.3-8/debian/patches/Remove-
  the-provider-section.patch/

  That patch solves a problem with programs that use OpenSSL v1
  (statically or dynamically linked); these still read
  /etc/ssl/openssl.cnf, but the v3-specific sections in the sid/jammy
  default config may cause a failure.

  One example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011051

  Another example: a (non-Ubuntu) Node.js v16 (OpenSSL compiled
  statically) hits an error in its crypto lib:

  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the shared library
      at Sign.sign (node:internal/crypto/sig:131:29) {
    opensslErrorStack: [
      'error:0E076071:configuration file routines:module_run:unknown module name',
      'error:0E07506E:configuration file routines:module_load_dso:error loading dso',
      'error:25070067:DSO support routines:DSO_load:could not load the shared library'
    ],
    library: 'DSO support routines',
    function: 'dlfcn_load',
    reason: 'could not load the shared library',
    code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }

  Removing the relevant provider section lines (the Debian patch doesn't
  apply cleanly, hence the use of sed) fixes it:

  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  <Buffer c5 e7 ba 01 5a 33 3f 26 43 bb 4e 47 99 49 e4 c7 60 41 be c6 91 63 c6 5d 0a af 78 5c 15 4a 9f 1a e7 24 99 ce 6a f0 05 b5 48 96 4e 59 b8 d5 69 df 3c bc ... 206 more bytes>

  I realize there is no libssl1.1 on jammy, but a statically linked
  OpenSSL is not uncommon (Node.js being a very prominent example).

  Would it be possible to get this Debian sid change ported to jammy?

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