4 ms·

This reminds me of the supply chain attack experts who's only solution seems to be blocking postinstall scripts.

insanitybit 3y ago
That sounds completely different. Blocking the word 'keygen' accomplishes absolutely nothing and is clearly stupid. Blocking build scripts absolutely stops a major attack vector.
- smashah 3y ago
  Malicious unchecked code in postinstall can just be moved to runtime so blanket blocking postinstall is as effective a solution to supply chain attacks as the solution of blocking npm packages with the word "keygen" in them is to the problem of .... js based keygens??? There are many legitimate purposes for postinstall scripts yet the anti-postinstall crowd acts like they solved security issues with this one easy step.
  - marcosdumay 3y ago
    Postinstall scripts run without any interaction before the developer has any chance of reviewing the code. They are a very bad thing.
    - smashah 3y ago
      "any chance"??? I can't square this circle of someone being paranoid about postinstall script but at the same time thinks the first chance to review dependency code is after doing a `npm i`. Check the git repo of the library you are installing beforehand if you're so paranoid about postinstall. And above that, never install any library for which the source is not readily available. This is the most basic first line of defense. username checks out.
      - dns_snek 3y ago
        > Check the git repo of the library you are installing beforehand if you're so paranoid about postinstall. > And above that, never install any library for which the source is not readily available. Whether source is available or not is mostly irrelevant when you're potentially dealing with malicious code, you need to review artifacts that are being fetched from NPM since those can differ from source code on Github. Attackers aren't going to announce their malicious code through meaningful git commit messages in a prominently displayed GitHub repository. They will make innocent-looking commits on Github, then publish a new version containing a single additional line of malicious code on NPM.
        smashah 3y ago
        > ...NPM since those can differ from source code on Github. True. How about people act their threat model? Instead of removing a feature for many users, just do whatever you need to do to be sure you're safe yourself? In what other major situation is the solution to nuke a feature due to security concerns? Afaik the main conversation about postinstall is around leeches complaining about political messages in their console and one or two other incidents
      - deleted 3y ago
        [deleted]
  - throwaway290 3y ago
    Runtime can be anything from browser to quickjs to Node in a docker. In many such cases the only time code runs on your dev machine completely unsandboxed is install scripts. Yes it is good to never install malicious NPM packages anyway but if you develop for any of those runtimes and you do not bother to check dep tree the anti install script crowd saved your ass.
  - insanitybit 3y ago
    > moved to runtime So a completely different scenario? Let's assume for a moment that developers only ever 'build' or 'check' their code, but all actual runtime behavior is in production. In production we have toooooons of security tooling for monitoring and constraining program behavior. On dev computers? Basically nothing. Of course, developers run `test` as well, and sometimes they run the whole program but these use cases, especially at companies, are increasingly moving to CI.
    - salawat 3y ago
      Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group. Please, make sure it runs locally first. CI often costs $$$, and when you nab a QA for debugging support, nothing irritates more than the answer "Well, no..." to the question "Did you even compile/run this?"
      - insanitybit 3y ago
        > Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group. Uh... branches? Obviously?
- duskwuff 3y ago
  > Blocking the word 'keygen' accomplishes absolutely nothing and is clearly stupid. The intent is almost certainly to stop a spam campaign which was using NPM package pages to host links to outside sites. Similar pages have been discussed on HN previously [1]. The fact that there was actual installable software involved was irrelevant to the attacker. All they were after was a way to put their content on a high-reputation domain -- and NPM was perfect for that. [1]: https://news.ycombinator.com/item?id=35370728 https://news.ycombinator.com/item?id=35370728

That sounds completely different. Blocking the word 'keygen' accomplishes absolutely nothing and is clearly stupid. Blocking build scripts absolutely stops a major attack vector.

smashah 3y ago
Malicious unchecked code in postinstall can just be moved to runtime so blanket blocking postinstall is as effective a solution to supply chain attacks as the solution of blocking npm packages with the word "keygen" in them is to the problem of .... js based keygens??? There are many legitimate purposes for postinstall scripts yet the anti-postinstall crowd acts like they solved security issues with this one easy step.
- marcosdumay 3y ago
  Postinstall scripts run without any interaction before the developer has any chance of reviewing the code. They are a very bad thing.
  - smashah 3y ago
    "any chance"??? I can't square this circle of someone being paranoid about postinstall script but at the same time thinks the first chance to review dependency code is after doing a `npm i`. Check the git repo of the library you are installing beforehand if you're so paranoid about postinstall. And above that, never install any library for which the source is not readily available. This is the most basic first line of defense. username checks out.
    - dns_snek 3y ago
      > Check the git repo of the library you are installing beforehand if you're so paranoid about postinstall. > And above that, never install any library for which the source is not readily available. Whether source is available or not is mostly irrelevant when you're potentially dealing with malicious code, you need to review artifacts that are being fetched from NPM since those can differ from source code on Github. Attackers aren't going to announce their malicious code through meaningful git commit messages in a prominently displayed GitHub repository. They will make innocent-looking commits on Github, then publish a new version containing a single additional line of malicious code on NPM.
      - smashah 3y ago
        > ...NPM since those can differ from source code on Github. True. How about people act their threat model? Instead of removing a feature for many users, just do whatever you need to do to be sure you're safe yourself? In what other major situation is the solution to nuke a feature due to security concerns? Afaik the main conversation about postinstall is around leeches complaining about political messages in their console and one or two other incidents
    - deleted 3y ago
      [deleted]
- throwaway290 3y ago
  Runtime can be anything from browser to quickjs to Node in a docker. In many such cases the only time code runs on your dev machine completely unsandboxed is install scripts. Yes it is good to never install malicious NPM packages anyway but if you develop for any of those runtimes and you do not bother to check dep tree the anti install script crowd saved your ass.
- insanitybit 3y ago
  > moved to runtime So a completely different scenario? Let's assume for a moment that developers only ever 'build' or 'check' their code, but all actual runtime behavior is in production. In production we have toooooons of security tooling for monitoring and constraining program behavior. On dev computers? Basically nothing. Of course, developers run `test` as well, and sometimes they run the whole program but these use cases, especially at companies, are increasingly moving to CI.
  - salawat 3y ago
    Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group. Please, make sure it runs locally first. CI often costs $$$, and when you nab a QA for debugging support, nothing irritates more than the answer "Well, no..." to the question "Did you even compile/run this?"
    - insanitybit 3y ago
      > Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group. Uh... branches? Obviously?
duskwuff 3y ago
> Blocking the word 'keygen' accomplishes absolutely nothing and is clearly stupid. The intent is almost certainly to stop a spam campaign which was using NPM package pages to host links to outside sites. Similar pages have been discussed on HN previously [1]. The fact that there was actual installable software involved was irrelevant to the attacker. All they were after was a way to put their content on a high-reputation domain -- and NPM was perfect for that. [1]: https://news.ycombinator.com/item?id=35370728 https://news.ycombinator.com/item?id=35370728