Enable --security-revert to be used in NODE_OPTIONS environment variable

[singyantam]

What is the problem this feature will solve?

When Nodejs is used for AWS lambda, the only mechanism available to supply Nodejs options is via NODE_OPTIONS environment variable. The recent Feb 24 security release started blocking use of RSA_PKCS1_PADDING in crypto module's privateDecrypt method. For any major company that always keep up to date with security patches, this new release immediate block Nodejs lambda's ability to process legacy data that was encrypted with RSA_PKCS1_PADDING.

If the --security-revert option can be specified via NODE_OPTIONS, we have the mechanism to allow Nodejs Lambda's to continue processing legacy data while remediation is developed and implemented.

What is the feature you are proposing to solve the problem?

Just allow --security-revert to be specified and acknowledge using NODE_OPTIONS - and not restrict it to be on the command line.

What alternatives have you considered?

No other possibility when dealing with AWS Lambda Nodejs runtime.

[WilliamABradley]

I'm running into the same issue with AWS Lambda, and hit this with an API that is outside of my control.

As a workaround, we can use node-rsa:

const crypto = require("crypto");
const NodeRSA = require("node-rsa");

const keypair = crypto.generateKeyPairSync("rsa", {
  modulusLength: 2048,
});

const data = Buffer.from("Hello, World!");

const encrypted = crypto.publicEncrypt(
  {
    key: keypair.publicKey,
    padding: crypto.constants.RSA_PKCS1_PADDING,
  },
  data
);
console.log("encrypted: ", encrypted.toString("base64"));

const keyRSA = new NodeRSA(
  keypair.privateKey.export({ format: "pem", type: "pkcs1" }),
  "private",
  {
    encryptionScheme: "pkcs1",
  }
);

// By default it will use the node crypto library with the CVE
keyRSA.setOptions({ environment: "browser" });

const decrypted = keyRSA.decrypt(encrypted);
console.log("decrypted: ", decrypted.toString());

[singyantam]

Thanks for the suggestion, we wrapped the original privateDecrypt in try catch and use node-rsa as a back up. But we prefer to have the NODE_OPTIONS support since node-rsa is JavaScript based implementation (when you specify browser - otherwise it actually relegate the work back to crypto module) while crypto leverage native code.

…

On Sun, Mar 10, 2024 at 5:34 PM Will Bradley ***@***.***> wrote: I'm running into the same issue with AWS Lambda, and hit this with an API that is outside of my control. As a workaround, we can use node-rsa: const crypto = require("crypto");const NodeRSA = require("node-rsa"); const keypair = crypto.generateKeyPairSync("rsa", { modulusLength: 2048,}); const data = Buffer.from("Hello, World!"); const encrypted = crypto.publicEncrypt( { key: keypair.publicKey, padding: crypto.constants.RSA_PKCS1_PADDING, }, data);console.log("encrypted: ", encrypted.toString("base64")); const keyRSA = new NodeRSA( keypair.privateKey.export({ format: "pem", type: "pkcs1" }), "private", { encryptionScheme: "pkcs1", }); // By default it will use the node crypto library with the CVEkeyRSA.setOptions({ environment: "browser" }); const decrypted = keyRSA.decrypt(encrypted);console.log("decrypted: ", decrypted.toString()); — Reply to this email directly, view it on GitHub <#52017 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANJLIH4NWQ6WGFQ27SAGIPLYXTGWFAVCNFSM6AAAAABENKVUGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGM3DSNRRGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[WilliamABradley]

Yeah, I'm not a fan of the workaround (and adding another dependency), and would much rather be able to disable the CVE block with an environment variable or other method.

[fliodhais]

The workaround isn't ideal but at least it works in the case of AWS lambda environment where we can't just simply pass in the NODE_OPTIONS unfortunately this is a good patch solution.

[mhdawson]

I'm surprised that NODE_OPTIONS does not support the security revert command line options. We'll have to see if that was on purpose on an omission due to the way options are allowed in NODE_OPTIONS.

[mhdawson]

It seems like it was a specific decision at the time - #12028 (comment)

[mhdawson]

I've reached out to one of the other maintainers that was part of the original PR/discussion to see if we still believe the exclusion from NODE_OPTIONS is the right way to go.

[melihbirim]

Having node-rsa and environment attribute to 'browser' solved the problem on my end. But the problem is having a fix on node that does break all the code we have without clarifying the exact real solution.
Any system, without a change should work as it is. It just drops the trust on the node versions in which we are not responsible to update to the latest version like in AWS lambda.

[mhdawson]

Talked with one of the other maintainers re the earlier concerns about including --cve-revert in NODE_OPTIONS and those concerns still apply.

One idea we came up with was the option of adding and api along the lines of

process.cveRevert('cve...")

that could be used to turn on a revert programatically. That would require an update to the Node.js application and would not flow through to spawned processes (similar to command line options I think), but would give another option versus the command line.

@singyantam would that approach work in your situation?

[WilliamABradley]

I think that would work for us, I was wondering if I could set process.CVE_... to true manually (As that is true when the security revert is applied), but seeing as this logic is in native code and not userland, that would not do anything.