node.js v14.17.5

[ken@…]

Notable Changes

    CVE-2021-3672/CVE-2021-22931: Improper handling of untypical characters in domain names (High)
        Node.js was vulnerable to Remote Code Execution, XSS, application crashes due to missing input validation of hostnames returned by Domain Name Servers in the Node.js DNS library which can lead to the output of wrong hostnames (leading to Domain Hijacking) and injection vulnerabilities in applications using the library. You can read more about it at https://nvd.nist.gov/vuln/detail/CVE-2021-22931.
    CVE-2021-22930: Use after free on close http2 on stream canceling (High)
        Node.js was vulnerable to a use after free attack where an attacker might be able to exploit memory corruption to change process behavior. This release includes a follow-up fix for CVE-2021-22930 as the issue was not completely resolved by the previous fix. You can read more about it at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22930.
    CVE-2021-22939: Incomplete validation of rejectUnauthorized parameter (Low)
        If the Node.js HTTPS API was used incorrectly and "undefined" was in passed for the "rejectUnauthorized" parameter, no error was returned and connections to servers with an expired certificate would have been accepted. You can read more about it at https://nvd.nist.gov/vuln/detail/CVE-2021-22939.

Commits

    [4923b59e0b] - deps: update c-ares to 1.17.2 (Beth Griggs) #39724
    [847a4c6a8a] - deps: reflect c-ares source tree (Beth Griggs) #39653
    [33208e2f89] - deps: apply missed updates from c-ares 1.17.1 (Beth Griggs) #39653
    [af5c1af9a4] - http2: add tests for cancel event while client is paused reading (Akshay K) #39622
    [434872e838] - http2: update handling of rst_stream with error code NGHTTP2_CANCEL (Akshay K) #39622
    [35b86110e4] - tls: validate "rejectUnauthorized: undefined" (Matteo Collina) nodejs-private/node-private#276

[ken@…]

Anybody manage to build this ? I'm getting

In file included from ../src/cares_wrap.cc:25:
../src/cares_wrap.h:25:11: fatal error: ares_nameser.h: No such file or directory
   25 | # include <ares_nameser.h>
      |           ^~~~~~~~~~~~~~~~
compilation terminated.

while trying to compile

  g++ -o /scratch/working/node-v14.17.5/out/Release/obj.target/libnode/src/cares_wrap.o ../src/cares_wrap.cc '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D__STDC_FORMAT_MACROS' '-DNODE_ARCH="x64"' '-DNODE_PLATFORM="linux"' '-DNODE_WANT_INTERNALS=1' '-DV8_DEPRECATION_WARNINGS=1' '-DNODE_OPENSSL_SYSTEM_CERT_PATH=""' '-DHAVE_INSPECTOR=1' '-DNODE_ENABLE_LARGE_CODE_PAGES=1' '-D__POSIX__' '-DNODE_USE_V8_PLATFORM=1' '-DNODE_HAVE_I18N_SUPPORT=1' '-DHAVE_OPENSSL=1' '-DNGHTTP2_STATICLIB' -I../src -I/scratch/working/node-v14.17.5/out/Release/obj/gen -I/scratch/working/node-v14.17.5/out/Release/obj/gen/include -I/scratch/working/node-v14.17.5/out/Release/obj/gen/src -I../deps/histogram/src -I../deps/uvwasi/include -I../deps/v8/include -I../deps/llhttp/include -I../deps/nghttp2/lib/includes -I../deps/brotli/c/include  -Wall -Wextra -Wno-unused-parameter -pthread -Wall -Wextra -Wno-unused-parameter -m64 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++1y -MMD -MF /scratch/working/node-v14.17.5/out/Release/.deps//scratch/working/node-v14.17.5/out/Release/obj.target/libnode/src/cares_wrap.o.d.raw   -c

[Douglas R. Reno]

I'm not sure, I haven't tried yet. Do you have the new c-ares installed? I was wondering if that could be related. Not sure though

[ken@…]

I have c-ares-1.17.2 on this system. AUR has gone with patching their existing 16.6, using a system c-ares patch, ​https://github.com/archlinux/svntogit-community/tree/packages/nodejs/trunk which looks similar to what 14.17.5 is doing.

Looking at c-ares-1.17.2 it _is_ in c-ares-1.17.2/src/lib/ares_nameser.h but it doesn't get installed.

The package contents for Arch's c-ares (link at ​https://archlinux.org/packages/extra/x86_64/c-ares/ doesn't seem to include it either.

[ken@…]

​https://github.com/nodejs/node/pull/39739 - b0rken it is.

That request was force-pushed, but the coverage-linux checks failed.

I suggest we wait until somebody has a working fix.

[Bruce Dubbs]

Try using:

sed -i s:ares_:arpa/: src/cares_wrap.h

Not tested.

[ken@…]

Replying to Bruce Dubbs:

Try using:

sed -i s:ares_:arpa/: src/cares_wrap.h

Not tested.

I'll give that a try. I was hoping to wait for a fix since it is broken in all linux and mac builds and that is an internal c-ares header. There is a pull request ​https://github.com/nodejs/node/issues/39747 but the original still shows that merging is blocked, so better to try to pick up whatever they have managed to fix.

Too generic. It changes the desired line, but two lines later changes a namespace specification from cares_wrap to carpa/wrap at which point things go rapidly downhill.

Using

sed -i 's%ares_\(nameser.h\)%arpa/\1%' src/cares_wrap.h

[Bruce Dubbs]

I guess I'm just pickey, but I don't like using % in REs. I prefer /, :, or | in that order. I also do not like \( constructs, but the backslashes can be avoued with 'sed -re ...'. To make things clearer, how about:

sed -i 's:ares_nameser.h:arpa/nameser.h:' src/cares_wrap.h

[Douglas R. Reno]

Are we going to still need that binutils patch for this?

[Bruce Dubbs]

My understanding is yes.

[ken@…]

Replying to Bruce Dubbs:

I guess I'm just pickey, but I don't like using % in REs. I prefer /, :, or | in that order. I also do not like \( constructs, but the backslashes can be avoued with 'sed -re ...'. To make things clearer, how about:

sed -i 's:ares_nameser.h:arpa/nameser.h:' src/cares_wrap.h

Too late, I've built and installed it like that, and am currently running the tests for a measured build.

[ken@…]

Replying to Douglas R. Reno:

Are we going to still need that binutils patch for this?

My understanding is that some people building node-v16 with different configs need the patch, and they might need it for this version. On this system (my slow one) with stock binutils-2.37 and glibc-2.34 I have not yet patched binutils (waiting until I think qtwebengine might be good enough to use, it takes 3 or 4 hours to build using all 8 cores).

[ken@…]

Fixed in @62c6ab795d30aed2a0963f9d26c9f88eb1ba3aec 10.1-763

[ken@…]

Security Advisory 10.1 091