6 ms·

>Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run a

>Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently. No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. You only have "secutity" to the extent that you can trust the people who control those packages to act both competently and in good faith ad infinitum. Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there.

deepsun 10mo ago
Same thing with IDE plugins. At least some are full-featured by the manufacturer, but I couldn't get on with VS Code as for every small feature I had to install some random plugin (even if popular, but still developed by who-knows-who).
- willvarfar 10mo ago
  The amount of browser extension authors who have talked openly about being approached to sell their extension or insert malicious code is many, and presumably many others have taken the money and not told us about it. It seems likely there are IDE extensions doing or going to do the same thing...
- packtreefly 10mo ago
  It's painful, but I've grown distrustful enough of the ecosystem that I disable updates on every IDE plugin not maintained by a company with known-adequate security controls and review the source code of plugin changes before installing updates, typically opting out unless something is broken. It's unclear to me if the code linked on the plugin's description page is in amy way guaranteed to be the code that the IDE downloads. The status quo in software distribution is simultaneously convenient, extraordinarily useful, and inescapably fucked.
elif 10mo ago
It wasn't in their product. It was just on a devs machine
- hnlmorg 10mo ago
  I think the OP is aware of that and I agree with them that it’s bad practice despite how common it is. For example with AWS, you can use the AWS CLI to sign you in and that goes through the HTTPS auth flow to provide you with temporary access keys. Which means: 1. You don’t have any access keys in plain text 2. Even if your env vars are also stolen, those AWS keys expire within a few hours anyway. If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file. I will agree that It does take effort to get your cloud credentials set up in a convenient way (easy to access, but without those access keys in plain text). But if you’re doing cloud stuff professionally, like the devs in the article, then you really should learn how to use these tools.
  - robomc 10mo ago
    > If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file. This doesn't really help though, for a supply chain attack, because you're still going to need to decrypt those keys for your code to read at some point, and the attacker has visibility on that, right? Like the shell isn't the only thing the attacker has access to, they also have access to variables set in your code.
    - hnlmorg 10mo ago
      I agree it doesn’t keep you completely safe. However scanning the file system for plain text secrets is significantly easier than the alternatives. For example, for vars to be read, you’d need the compromised code to be part of your the same project. But if you scan the file system, you can pick up secrets for any project written in any language, even those which differ from the code base that pulled the compromised module. This example applies directly to the article; it wasn’t their core code base that ran the compromised code but instead an experimental repository. Furthermore, we can see from these supply chain attacks that they do scan the file system. So we do know that encrypting secrets adds a layer of protection against the attacks happening in the wild. In an ideal world, we’d use OIDC everywhere and not need hardcoded access keys. But in instances where we can’t, encrypting them is better than not.
LtWorf 10mo ago
> Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there. Doesn't really matter, if the agent is unlocked they can be accessed.
- johncolanduoni 10mo ago
  This is not strictly true - most OS keychain stores have methods of authenticating the requesting application before remitting keys (signatures, non-user-writable paths, etc.), even if its running as the correct user. That said, it requires careful design on the part of the application (and its install process) to not allow a non-elevated application to overwrite some part of the trusted application and get the keys anyway. macOS has the best system here in principle with its bundle signing, but most developer tools are not in bundles so its of limited utility in this circumstance.
  - michaelt 10mo ago
    > This is not strictly true - most OS keychain stores have methods of authenticating the requesting application before remitting keys (signatures, non-user-writable paths, etc.), even if its running as the correct user. Isn't that a smartphone-and-app-store-only thing? As I understand it, no mainstream desktop OS provides the capabilities to, for example, protect a user's browser cookies from a malicious tool launched by that user. That's why e.g. PC games ship with anti-cheat mechanisms - because PCs don't have a comprehensive attested-signed-code-only mechanism to prevent nefarious modifications by the device owner.
    - acdha 10mo ago
      > As I understand it, no mainstream desktop OS provides the capabilities to, for example, protect a user's browser cookies from a malicious tool launched by that user. macOS sandboxing has been used for this kind of thing for years. Open a terminal window on a new Mac and trying to open the user’s photo library, Desktop, iCloud documents, etc. will trigger a permissions prompt.
majormajor 10mo ago
> Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently. This is wildly circular logic! "One person using these tools isn't bad security practice, the problem is that EVERYONE ELSE ["the ecosystem"] uses these tools and doesn't have higher standards!" It should be no shock to anyone at this point that huge chunks of common developer tools have very poor security profiles. We've seen stories like this many times. If you care, you need to actually care!
- perching_aix 10mo ago
  So do you actually agree or disagree that there's something wrong with npm? It reads as if you were playing both sides, just to land on blaming the individual each time. Even if this was actually some weirdly written plea to shared responsibility, surely it makes sense that in a hierarchy, one would proritize trying to fix things upstream closer to the root, rather than downstream closer to the leaves, doesn't it? > This is wildly circular logic! They're very clearly implying a semantic disagreement there, not making a logical mistake.
  - jrflowers 10mo ago
    I can’t speak for majormajor but I thought the language was kind of funny. “The problem is an ecosystem that allows packages to run arbitrary code silently” is an odd statement because for many people that’s kind of what a package manager does.
    - ballpug 10mo ago
      [dead]
  - chatmasta 10mo ago
    > one would proritize trying to fix things upstream closer to the root One should prioritize fixing things one is responsible for. If you make a commitment to protect your user’s data, then you take responsibility for the tools you use, and how you use them. Whether or not you – or someone else – should fix those tools upstream, is a separate issue to be solved later. First solve the problems that are your responsibility. Then worry about everyone else. The npm ecosystem has many security issues but they are all mitigatable.
c0balt 10mo ago
> Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there. To be fair, some tools only support a netrc file for http(s) based auth. Regardless, if you want to use git via http this vector exists almost always.
- woodruffw 10mo ago
  Serious question: what tools only support netrc for authentication? I'm aware of lots of tools that (unfortunately IMO) support netrc as a source of credentials, but I can't think of a single one that requires it.
  - c0balt 10mo ago
    Afaik, nix for https-based git(hub/lab/...) repositories and http-auth protected resources (via fetchurl and friends).
atherton94027 10mo ago
> No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. Could you explain how you'd design a package manager that does not allow that? As far as I understand the moment you use third party code you have to trust to some extent the code that you will run.
- vasco 10mo ago
  They can't explain, it's just victim blaming. The market currently doesn’t have a proper solution to this. Everyone works with these package managers, I bet the commenter also has installed pip or npm packages without reading its full code, it just feels cool to tell other people they are dumb and it's their own fault for not reading all the code beforehand or for using a package manager, when every single person does the same. Some just are unlucky. The whole ecosystem is broken, the expectations of trust are not compatible with the current amount of attacks.
  - voidnap 10mo ago
    It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model. I run npm under bubblewrap because npm has a culture of high risk; of using too many dependencies from untrusted authors. But being scrupulous and responsible is a cost I pay with my time and attention. But it is important because if I run some untrusted code and am compromised it can affect others. But that is challenging when every time some exploit rolls around people, like you, brush it off as "unlucky". As if to say it's inavoidable. That nobody can be expected to be responsible for the libraries they use because that is too hard or whatever. You simply lack the appetite for good hygene and it makes it harder for the minority of us who care about how our actions affect others.
    - VPenkov 10mo ago
      > you have no appetite for a better security model For what it's worth, there are some advancements. PNPM - the packager used in this case - doesn't automatically run postinstall scripts. In this case, either the engineer allowed it explicitly, or a transitive dependency was previously considered safe, and allowed by default, but stopped being safe. PNPM also lets you specify a minimum package age, so you cannot install packages younger than X. The combination of these would stop most attacks, but becomes less effective if everyone specifies a minimum package age, so no one would fall victim. It's a bit grotesque because the system relies on either the package author noticing on time, or someone falling victim and reporting it. NPM now supports publishing signed packages, and PNPM has a trustPolicy flag. This is a step in a good direction, but is still not enough, because it relies on publishers to know and care about signing packages, and it relies on consumers to require it. There _is_ appetite for a better security model, but a lot of old, ubiquitous packages, are unmaintained and won't adopt it. The ecosystem is evolving, but very slowly, and breaking changes seem needed.
amluto 10mo ago
>> The security failure is in an ecosystem that allows packages to run arbitrary code silently. > No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. How about both? It’s conceptually straightforward to build a language in which code cannot do anything other than read its inputs, consume resources, and produce correctly typed output. This would not fully solve the supply chain problem — malicious code could produce maliciously incorrect output or exploit side channels, but the exposure would be much, much less than it is now.

deepsun 10mo ago

Same thing with IDE plugins. At least some are full-featured by the manufacturer, but I couldn't get on with VS Code as for every small feature I had to install some random plugin (even if popular, but still developed by who-knows-who).

willvarfar 10mo ago
The amount of browser extension authors who have talked openly about being approached to sell their extension or insert malicious code is many, and presumably many others have taken the money and not told us about it. It seems likely there are IDE extensions doing or going to do the same thing...
packtreefly 10mo ago
It's painful, but I've grown distrustful enough of the ecosystem that I disable updates on every IDE plugin not maintained by a company with known-adequate security controls and review the source code of plugin changes before installing updates, typically opting out unless something is broken. It's unclear to me if the code linked on the plugin's description page is in amy way guaranteed to be the code that the IDE downloads. The status quo in software distribution is simultaneously convenient, extraordinarily useful, and inescapably fucked.

elif 10mo ago

It wasn't in their product. It was just on a devs machine

hnlmorg 10mo ago
I think the OP is aware of that and I agree with them that it’s bad practice despite how common it is. For example with AWS, you can use the AWS CLI to sign you in and that goes through the HTTPS auth flow to provide you with temporary access keys. Which means: 1. You don’t have any access keys in plain text 2. Even if your env vars are also stolen, those AWS keys expire within a few hours anyway. If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file. I will agree that It does take effort to get your cloud credentials set up in a convenient way (easy to access, but without those access keys in plain text). But if you’re doing cloud stuff professionally, like the devs in the article, then you really should learn how to use these tools.
- robomc 10mo ago
  > If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file. This doesn't really help though, for a supply chain attack, because you're still going to need to decrypt those keys for your code to read at some point, and the attacker has visibility on that, right? Like the shell isn't the only thing the attacker has access to, they also have access to variables set in your code.
  - hnlmorg 10mo ago
    I agree it doesn’t keep you completely safe. However scanning the file system for plain text secrets is significantly easier than the alternatives. For example, for vars to be read, you’d need the compromised code to be part of your the same project. But if you scan the file system, you can pick up secrets for any project written in any language, even those which differ from the code base that pulled the compromised module. This example applies directly to the article; it wasn’t their core code base that ran the compromised code but instead an experimental repository. Furthermore, we can see from these supply chain attacks that they do scan the file system. So we do know that encrypting secrets adds a layer of protection against the attacks happening in the wild. In an ideal world, we’d use OIDC everywhere and not need hardcoded access keys. But in instances where we can’t, encrypting them is better than not.

LtWorf 10mo ago

> Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there. Doesn't really matter, if the agent is unlocked they can be accessed.

johncolanduoni 10mo ago
This is not strictly true - most OS keychain stores have methods of authenticating the requesting application before remitting keys (signatures, non-user-writable paths, etc.), even if its running as the correct user. That said, it requires careful design on the part of the application (and its install process) to not allow a non-elevated application to overwrite some part of the trusted application and get the keys anyway. macOS has the best system here in principle with its bundle signing, but most developer tools are not in bundles so its of limited utility in this circumstance.
- michaelt 10mo ago
  > This is not strictly true - most OS keychain stores have methods of authenticating the requesting application before remitting keys (signatures, non-user-writable paths, etc.), even if its running as the correct user. Isn't that a smartphone-and-app-store-only thing? As I understand it, no mainstream desktop OS provides the capabilities to, for example, protect a user's browser cookies from a malicious tool launched by that user. That's why e.g. PC games ship with anti-cheat mechanisms - because PCs don't have a comprehensive attested-signed-code-only mechanism to prevent nefarious modifications by the device owner.
  - acdha 10mo ago
    > As I understand it, no mainstream desktop OS provides the capabilities to, for example, protect a user's browser cookies from a malicious tool launched by that user. macOS sandboxing has been used for this kind of thing for years. Open a terminal window on a new Mac and trying to open the user’s photo library, Desktop, iCloud documents, etc. will trigger a permissions prompt.

majormajor 10mo ago

> Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently. This is wildly circular logic! "One person using these tools isn't bad security practice, the problem is that EVERYONE ELSE ["the ecosystem"] uses these tools and doesn't have higher standards!" It should be no shock to anyone at this point that huge chunks of common developer tools have very poor security profiles. We've seen stories like this many times. If you care, you need to actually care!

perching_aix 10mo ago
So do you actually agree or disagree that there's something wrong with npm? It reads as if you were playing both sides, just to land on blaming the individual each time. Even if this was actually some weirdly written plea to shared responsibility, surely it makes sense that in a hierarchy, one would proritize trying to fix things upstream closer to the root, rather than downstream closer to the leaves, doesn't it? > This is wildly circular logic! They're very clearly implying a semantic disagreement there, not making a logical mistake.
- jrflowers 10mo ago
  I can’t speak for majormajor but I thought the language was kind of funny. “The problem is an ecosystem that allows packages to run arbitrary code silently” is an odd statement because for many people that’s kind of what a package manager does.
  - ballpug 10mo ago
    [dead]
- chatmasta 10mo ago
  > one would proritize trying to fix things upstream closer to the root One should prioritize fixing things one is responsible for. If you make a commitment to protect your user’s data, then you take responsibility for the tools you use, and how you use them. Whether or not you – or someone else – should fix those tools upstream, is a separate issue to be solved later. First solve the problems that are your responsibility. Then worry about everyone else. The npm ecosystem has many security issues but they are all mitigatable.

c0balt 10mo ago

> Also the OP seemingly implies credentials are stored on-filesystem in plaintext but I might be extrapolating too much there. To be fair, some tools only support a netrc file for http(s) based auth. Regardless, if you want to use git via http this vector exists almost always.

woodruffw 10mo ago
Serious question: what tools only support netrc for authentication? I'm aware of lots of tools that (unfortunately IMO) support netrc as a source of credentials, but I can't think of a single one that requires it.
- c0balt 10mo ago
  Afaik, nix for https-based git(hub/lab/...) repositories and http-auth protected resources (via fetchurl and friends).

atherton94027 10mo ago

> No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. Could you explain how you'd design a package manager that does not allow that? As far as I understand the moment you use third party code you have to trust to some extent the code that you will run.

vasco 10mo ago
They can't explain, it's just victim blaming. The market currently doesn’t have a proper solution to this. Everyone works with these package managers, I bet the commenter also has installed pip or npm packages without reading its full code, it just feels cool to tell other people they are dumb and it's their own fault for not reading all the code beforehand or for using a package manager, when every single person does the same. Some just are unlucky. The whole ecosystem is broken, the expectations of trust are not compatible with the current amount of attacks.
- voidnap 10mo ago
  It isn't victim blaming. People like you make it impossible to avoid attacks like these because you have no appetite for a better security model. I run npm under bubblewrap because npm has a culture of high risk; of using too many dependencies from untrusted authors. But being scrupulous and responsible is a cost I pay with my time and attention. But it is important because if I run some untrusted code and am compromised it can affect others. But that is challenging when every time some exploit rolls around people, like you, brush it off as "unlucky". As if to say it's inavoidable. That nobody can be expected to be responsible for the libraries they use because that is too hard or whatever. You simply lack the appetite for good hygene and it makes it harder for the minority of us who care about how our actions affect others.
  - VPenkov 10mo ago
    > you have no appetite for a better security model For what it's worth, there are some advancements. PNPM - the packager used in this case - doesn't automatically run postinstall scripts. In this case, either the engineer allowed it explicitly, or a transitive dependency was previously considered safe, and allowed by default, but stopped being safe. PNPM also lets you specify a minimum package age, so you cannot install packages younger than X. The combination of these would stop most attacks, but becomes less effective if everyone specifies a minimum package age, so no one would fall victim. It's a bit grotesque because the system relies on either the package author noticing on time, or someone falling victim and reporting it. NPM now supports publishing signed packages, and PNPM has a trustPolicy flag. This is a step in a good direction, but is still not enough, because it relies on publishers to know and care about signing packages, and it relies on consumers to require it. There _is_ appetite for a better security model, but a lot of old, ubiquitous packages, are unmaintained and won't adopt it. The ecosystem is evolving, but very slowly, and breaking changes seem needed.

amluto 10mo ago

>> The security failure is in an ecosystem that allows packages to run arbitrary code silently. > No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. How about both? It’s conceptually straightforward to build a language in which code cannot do anything other than read its inputs, consume resources, and produce correctly typed output. This would not fully solve the supply chain problem — malicious code could produce maliciously incorrect output or exploit side channels, but the exposure would be much, much less than it is now.