Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-30829

crypto.fips reports "0" even when FIPS is enabled

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • rhel-9.5
    • rhel-9.3.0
    • nodejs
    • None
    • None
    • Moderate
    • ZStream
    • sst_cs_apps
    • ssg_core_services
    • 32
    • 2
    • False
    • Hide

      None

      Show
      None
    • None
    • Red Hat Enterprise Linux
    • None
    • Approved Blocker
    • None
    • None
    • None

      What were you trying to do that didn't work?

      A customer tries to verify whether FIPS is enabled using node js script available in 1.2.2.2. Verifying that Node.js is running in FIPS mode.
      It happens the script always reports 0, and this is internally reproducible with latest nodejs and module:

      [root@vm-fips9 ~]# cat fips.js 
      const crypto = require('crypto');
      console.log("FIPS = " + crypto.fips);
      
      [root@vm-fips9 ~]# fips-mode-setup --check
      FIPS mode is enabled.
      [root@vm-fips9 ~]# node fips.js 
      FIPS = 0
      

      NodeJs relies on calling EVP_default_properties_is_fips_enabled() to perform the check, but for me systemtap shows it's always reporting 0.

      Source code:

      207 void GetFipsCrypto(const FunctionCallbackInfo<Value>& args) {
      208   Mutex::ScopedLock lock(per_process::cli_options_mutex);
      209   Mutex::ScopedLock fips_lock(fips_mutex);
      210 
      211 #if OPENSSL_VERSION_MAJOR >= 3
      212   args.GetReturnValue().Set(EVP_default_properties_is_fips_enabled(nullptr) ?
      213       1 : 0);
      214 #else
      215   args.GetReturnValue().Set(FIPS_mode() ? 1 : 0);
      216 #endif
      217 }
      

      Systemtap script showing issue:

      # export STAP_FIPS_OVERRIDE=1
      # stap -d /usr/lib64/libnode.so.93 -d /lib64/libcrypto.so.3 --ldd -e 'probe process("/lib64/libcrypto.so.3").function("EVP_default_properties_is_fips_enabled").return { printf("%ld (%s)\n", pid(), execname()); print_ubacktrace_fileline(); printf("$return = %d, $libctx = %p\n", $return, @entry($libctx)); }'
      [...]
      
      5094 (node)
       0x7f45e72965fc : _ZN4node6crypto13GetFipsCryptoERKN2v820FunctionCallbackInfoINS1_5ValueEEE+0x3c/0x80 [/usr/lib64/libnode.so.93]
       0x7f45e777a798 : _ZN2v88internal25FunctionCallbackArguments4CallENS0_15CallHandlerInfoE+0xe8/0x1a0 [/usr/lib64/libnode.so.93]
       0x7f45e777aea1 : _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE+0xb1/0x450 [/usr/lib64/libnode.so.93]
       0x7f45e777b30d : _ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE+0xcd/0x1b0 [/usr/lib64/libnode.so.93]
       0x7f45e7379499 : Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit+0x39/0xe0 [/usr/lib64/libnode.so.93]
      $return = 0, $libctx = 0x0
      

      Here above we have return code 0 and calling context NULL.

      Weirdly, sshd does same call and it works for it. e.g. when connecting to the system:

      5969 (sshd)
       0x7f14c307b955 : ossl_pool_acquire_entropy+0x95/0x380 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c2fe7e31 : ossl_rand_get_entropy+0x31/0xb0 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c260d047 [/usr/lib64/ossl-modules/fips.so+0x9d047/0x143000]
      $return = 0, $libctx = 0x0
      5969 (sshd)
       0x7f14c307b955 : ossl_pool_acquire_entropy+0x95/0x380 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c2fe7e31 : ossl_rand_get_entropy+0x31/0xb0 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c260d047 [/usr/lib64/ossl-modules/fips.so+0x9d047/0x143000]
      $return = 0, $libctx = 0x0
      5969 (sshd)
       0x7f14c307b955 : ossl_pool_acquire_entropy+0x95/0x380 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c2fe7e31 : ossl_rand_get_entropy+0x31/0xb0 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c260d047 [/usr/lib64/ossl-modules/fips.so+0x9d047/0x143000]
      $return = 0, $libctx = 0x0
      5969 (sshd)
       0x7f14c307b955 : ossl_pool_acquire_entropy+0x95/0x380 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c2fe7e31 : ossl_rand_get_entropy+0x31/0xb0 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c260d047 [/usr/lib64/ossl-modules/fips.so+0x9d047/0x143000]
      $return = 1, $libctx = 0x0
      5969 (sshd)
       0x7f14c307b955 : ossl_pool_acquire_entropy+0x95/0x380 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c2fe7e31 : ossl_rand_get_entropy+0x31/0xb0 [/usr/lib64/libcrypto.so.3.0.7]
       0x7f14c260d047 [/usr/lib64/ossl-modules/fips.so+0x9d047/0x143000]
      $return = 1, $libctx = 0x0
      
      ...
      

      *However* even for sshd, the initial calls return 0, so potentially there is some issue with early initialization somehow (seems like related to Entropy???).

      Please provide the package NVR for which bug is seen:

      nodejs-16.20.2-4.el9_3.x86_64
      nodejs-20.11.0-1.module+el9.3.0+21188+8b938bcb

      How reproducible:

      Always

      Steps to reproduce

      1. See above

      Expected results

      FIPS = 1

      Actual results

      FIPS = 0

            jstanek@redhat.com Jan Stanek
            rhn-support-rmetrich Renaud Métrich
            nodejs-maint nodejs-maint
            Jakub Heger Jakub Heger
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: