3 ms·

Hi forty, this mitigation is for the install time vulnerability. To answer your question, at install time: no, at runtime: yes, but not always. For instance, if

Hi forty, this mitigation is for the install time vulnerability. To answer your question, at install time: no, at runtime: yes, but not always. For instance, if it's a frontend package it will run in a browser. Therefore, it can't create the symlink.

forty 6y ago
I understand, but this malicious package issue is also a problem when installing on the local dev environment. And the dev is probably going to run some kind of unit tests at some point, which will import the package and run whatever malicious code is there
- laurent92 6y ago
  The only way to know is to forge a malicious script that encrypts the filesystem, slip it into a popular library, and see who complains. Otherwise people will always take half-decisions, only masking the types of attacks they know about. This, or black hats are already using this backdoor silently. Which makes me wonder: Should dev machines be considered high-risk? They run all sorts of software, with permissions loosened, then pass programs to CI tools, which build them and deploy to prod with AWS authentication tokens enabled... I’m shaking just seeing how many Chrome extensions my devs have (with all permissions enabled of course) when they access prod instances... Should startup management (Safe environnements with Excel, no Chrome extensions, accessing the company’s bank accounts, etc) be done on separate machines than development activities?
  - efortis 6y ago
    About the dev machines, yes, many places do consider them (and they are) high risk. I'd add to your list, the source code, future plans, etc. I do some basic steps to harden my dev machines: - A Chrome profile without extensions for developing for the most part. - The localhost is not 127.0.0.1 but a random IP under 127/8, with a random port. See https://news.ycombinator.com/item?id=20028108 https://news.ycombinator.com/item?id=20028108 - When creating SSH keys, add extra rounds (e.g. `ssh-keygen -a 64`) to make it harder to brute-force the passphrase.
- efortis 6y ago
  That shouldn't be difficult to PoC. Although, following the tangent, other vectors targeting the js engine could be. At any rate, do you agree those issues would be unrelated to NPM scripts? I ask because my point is more like: one mitigation at a time. Otherwise, many people would do nothing because it wouldn't solve everything.
  - forty 6y ago
    Maybe. I'll note that we do npm install in a separate gitlab-ci step as other steps that are running the code (we then share the modules via artifacts). Actually the publishing / deployment are also done in separate steps, so we could make sure that only the deployment step have the credentials (though I'm not sure it's possible with gitlab-ci atm) which would be a much better improvement than preventing npm scripts (which I'm still not convinced do bring more security without further improvements)
    - efortis 6y ago
      When running `npm install` without the mitigation, the attacker can steal your source code right away, among other things. Also, developers adding new packages could compromise their environment because that's done running e.g. `npm install react`.

forty 6y ago

I understand, but this malicious package issue is also a problem when installing on the local dev environment. And the dev is probably going to run some kind of unit tests at some point, which will import the package and run whatever malicious code is there

laurent92 6y ago
The only way to know is to forge a malicious script that encrypts the filesystem, slip it into a popular library, and see who complains. Otherwise people will always take half-decisions, only masking the types of attacks they know about. This, or black hats are already using this backdoor silently. Which makes me wonder: Should dev machines be considered high-risk? They run all sorts of software, with permissions loosened, then pass programs to CI tools, which build them and deploy to prod with AWS authentication tokens enabled... I’m shaking just seeing how many Chrome extensions my devs have (with all permissions enabled of course) when they access prod instances... Should startup management (Safe environnements with Excel, no Chrome extensions, accessing the company’s bank accounts, etc) be done on separate machines than development activities?
- efortis 6y ago
  About the dev machines, yes, many places do consider them (and they are) high risk. I'd add to your list, the source code, future plans, etc. I do some basic steps to harden my dev machines: - A Chrome profile without extensions for developing for the most part. - The localhost is not 127.0.0.1 but a random IP under 127/8, with a random port. See https://news.ycombinator.com/item?id=20028108 https://news.ycombinator.com/item?id=20028108 - When creating SSH keys, add extra rounds (e.g. `ssh-keygen -a 64`) to make it harder to brute-force the passphrase.
efortis 6y ago
That shouldn't be difficult to PoC. Although, following the tangent, other vectors targeting the js engine could be. At any rate, do you agree those issues would be unrelated to NPM scripts? I ask because my point is more like: one mitigation at a time. Otherwise, many people would do nothing because it wouldn't solve everything.
- forty 6y ago
  Maybe. I'll note that we do npm install in a separate gitlab-ci step as other steps that are running the code (we then share the modules via artifacts). Actually the publishing / deployment are also done in separate steps, so we could make sure that only the deployment step have the credentials (though I'm not sure it's possible with gitlab-ci atm) which would be a much better improvement than preventing npm scripts (which I'm still not convinced do bring more security without further improvements)
  - efortis 6y ago
    When running `npm install` without the mitigation, the attacker can steal your source code right away, among other things. Also, developers adding new packages could compromise their environment because that's done running e.g. `npm install react`.