Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security issue: React is vulnerable to supply chain attacks #27748

Closed
paulmillr opened this issue Nov 26, 2023 · 12 comments
Closed

Security issue: React is vulnerable to supply chain attacks #27748

paulmillr opened this issue Nov 26, 2023 · 12 comments

Comments

@paulmillr
Copy link

react depends on "loose-envify": "^1.1.0", a package which owned by one person. Last update of it was 5 years ago.

If the persons NPM credentials or token are leaked, and a new malwared version of loose-envify is published, all react users will instantly receive malware.

Moreover, same can happen to envify's dependency: js-tokens.

Ways to mitigate:

  • Lock version to 1.1.0
  • Better: ask person (fb employee) to release new loose-envify with locked-down version of js-tokens, then lock envify version in react
  • Is it even needed in dependencies (not devDeps)? Maybe remove altogether
@markerikson
Copy link
Contributor

markerikson commented Nov 27, 2023

I have mixed feelings about this:

  • It seems like a pretty big stretch to claim that React is "vulnerable to supply chain attacks" because of the existence of one particular dependency. Why wouldn't that be the case for every dependency on NPM ever? That's an awfully hypothetical situation.
  • Agreed that the fact that the package hasn't been updated for a number of years is in one sense something to think about, but it's also a tooling-related package that has no reason to change at all anyway
  • That said, we dropped loose-envify from Redux a while back, per Investigate dropping all external dependencies reduxjs/redux#3567 (although we are just now getting ready to release that in a new major version). It was designed for Browserify users to help that tool do search-and-replace on process.env.NODE_ENV when used to build an app that used a given library like React. Browserify is rarely used today, and that should really be an app-level configuration concern. (Related, see External packages not transforming process.env.NODE_ENV #9641 where this was added to some of the addon packages)

So, I disagree with the security reasoning, but I agree that React shouldn't list loose-envify as a dependency because it's not useful any more.

@paulmillr
Copy link
Author

paulmillr commented Nov 27, 2023

Why wouldn't that be the case for every dependency on NPM ever

It is the case. That’s why there supply chain attacks are so effective in js: of popularity of version ranges and the fact ppl blindly update their dependencies to every new version.

Consider a simple scenario: the persons npm token is leaked by virus and 1.1.1 is published; with the ability to steal other peoples npm tokens. Would a simple locking to 1.1.0 mitigate this? Sure.

There are other ways to make packages resilient. For example, with ethereum-cryptography package, the dependency state is locked down, there have been an audit. Every time a dependency bump is done, it is reviewed by at least one other person, we check version diff, etc. It is not possible for packages such as typescript, but there are few of these. Moreover, the recent rewrite, reduced the amount of authors who can publish a sub-dependency update from 33 to just 1.

@markerikson
Copy link
Contributor

markerikson commented Nov 27, 2023

@paulmillr : yeah, I follow that. My question is more about why it's worth singling out one dep here in this repo specifically. What makes this situation special?

again, to be clear, I do support removing loose-envify as a dep entirely, but for non-security related reasons. I just don't understand the urgency for filing a security-claim issue about one random dep.

@phryneas
Copy link

Also, since npm has started to require two-factor auth for publishing popular packages, a token stolen by a virus does not pose a significant threat of a supply-chain attack.

@rickhanlonii
Copy link
Member

Has anyone looked into how it's actually used? I believe we only have it to support browserify, so if you don't run browserify, the code in the package isn't executed, right? Should it be moved to a dev dependency anyway?

@markerikson
Copy link
Contributor

markerikson commented Nov 27, 2023

@rickhanlonii : yeah, it's purely a Browserify thing.

If you intend it to be used, it has to be listed as a dependency as far as I know. I think the intended usage sequence is:

  • User installs react, which drags along loose-envify as a dep so it's available
  • Browserify tries to build the app
  • Browserify looks at react's package.json, sees the transforms section, pulls in loose-envify, and automatically uses that as part of its transformation process

So, moving it to a dev dep breaks that, because installing react wouldn't automatically install loose-envify too.

My take is that this is not React's job at this point. It's up to the user to configure their own build tool properly. (And doubly so given that Browserify is a relatively legacy build tool today.)

@paulmillr
Copy link
Author

@markerikson a person in other repo randomly told me “even react does this”, then i’ve did the researched and while it seemed like the dep is not really up-to-date, or “not devdep”, i’ve opened the issue.

@paulmillr
Copy link
Author

paulmillr commented Nov 28, 2023

@phryneas

Also, since npm has started to require two-factor auth for publishing popular packages, a token stolen by a virus does not pose a significant threat of a supply-chain attack.

I don’t believe this mitigates the risk. They just enforced 2fa for auth. Not for publish — otherwise CI publish tokens would have stopped working. I have published popular packages through CI recently, all is fine. Tokens can still be stolen.

@oliviertassinari
Copy link
Contributor

oliviertassinari commented Feb 25, 2024

Removing loose-envify makes a lot sense to me:

SCR-20240225-pcjk

It's at about 5% of the downloads of React today. When this dependency was introduced in 2016 ecf824c, it was a much different landscape: https://npm-stat.com/charts.html?package=browserify&package=react&from=2015-02-24&to=2017-02-24, Browserify had more downloads than React.

SCR-20240225-pdkv

@markerikson
Copy link
Contributor

@oliviertassinari not sure what you mean with the "react-is would need this" comment. That's the exact same dev-vs-prod import idiom that react and react-dom already use:

and bundlers already handle NODE_ENV as an idiom indicating dev vs prod.

@oliviertassinari
Copy link
Contributor

@markerikson I would expect react-is to reproduce the loose-envify setup than react has:

  "browserify": {
    "transform": [
      "loose-envify"
    ]
  }

Otherwise, the benefit is limited to have it in react in the first place.

@eps1lon
Copy link
Collaborator

eps1lon commented Mar 1, 2024

Closed in #28480

@eps1lon eps1lon closed this as completed Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants