Skip to content

The kDisableNodeOptionsEnv option can be work around by using NODE_REPL_EXTERNAL_MODULE env #51227

Description

@zcbenz

Node has an kDisableNodeOptionsEnv embedder flag that disables NODE_OPTIONS env to avoid injecting external code into apps, however it can be bypassed by using the NODE_REPL_EXTERNAL_MODULE env as reported by electron/electron#40770.

I understand kDisableNodeOptionsEnv only means to disable NODE_OPTIONS env, but if we don't also disable NODE_REPL_EXTERNAL_MODULE the protection would become meaningless.

I think we have 2 options to fix this:

  1. Disable NODE_REPL_EXTERNAL_MODULE env when kDisableNodeOptionsEnv is used.
  2. Deprecate kDisableNodeOptionsEnv and add a new flag that disables all possible ways to inject code.

I wonder which one would be preferred by Node team. /cc @addaleax @joyeecheung @bnoordhuis

Activity

  1. avivkeller commented on Apr 26, 2024

    @avivkeller
    Member

    @nodejs/security-wg

  2. added
    dotenvIssues and PRs related to .env file parsing.
    on Apr 26, 2024
  3. avivkeller commented on Apr 26, 2024

    @avivkeller
    Member

    Dotenv isn't the correct label (no dotenv file), buts AFAIK the closest to env variables

  4. removed
    dotenvIssues and PRs related to .env file parsing.
    on Apr 29, 2024
  5. RafaelGSS commented on Apr 29, 2024

    @RafaelGSS
    Member

    @zcbenz While the first option is trivial I assume it will be a breaking change for all users that rely on the current behavior. I believe a new flag should be a safer approach. Honestly, I'm fine with both options.

    cc: @nodejs/tsc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    securityIssues and PRs related to security.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions