5 ms·

Am I the only one who is scared by the entire ecosystem of "drag random crap and dependencies off the Internet from who the hell knows"? I've had a couple of m

by cjk2 3y ago

Am I the only one who is scared by the entire ecosystem of "drag random crap and dependencies off the Internet from who the hell knows"? I've had a couple of minor incidents with NodeJS dependencies over the last few years on this front which sort of opened my eyes to running untrusted code. I tend to err on the side of distribution packages since, with the restrictions that imposes on what I do.

nerdwaller 3y ago
Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code. Depending on how and where you deploy, you can mitigate some of that by isolating the installs and not keeping sensitive information there (e.g. in a docker image). [1] - I don't follow node/npm closely anymore, so this may have changed.
- louislang 3y ago
  this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.
  - PuercoPop 3y ago
    For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust. And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines. For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory. I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)
    - mensfeld 3y ago
      Hey, you have to patch nothing. Nix support was merged to karafka two months ago.
- Denvercoder9 3y ago
  I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?
  - taeric 3y ago
    Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace. More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)
    - dns_snek 3y ago
      How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it. In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.
      - taeric 3y ago
        Honestly, I'm going off memory on python. In the olden days, it was not at all uncommon for devs to want the ability to "sudo pip install foo".
    - Denvercoder9 3y ago
      Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.
seabrookmx 3y ago
You're not the only one! This is why I strongly prefer languages with a comprehensive standard library. I trust my Python/golang/dotnet/whatever install, so the number of third party packages I need to pull in is much smaller and more easily audited.
- mooreds 3y ago
  What is your audit schedule/process?
  - seabrookmx 3y ago
    Well it starts with a culture of taking responsibility when adding a dependency. We want people to look at child dependencies and just think more critically about them before checking in code. This is mostly to prevent bloat but sometimes we catch unmaintained packages or accidentally pulling in a random form rather than the community supported variant, for example. We also run SAST in our gitlab pipelines and include reviewing the output as part of the code review and release process so that we can catch CVE's that may not have been known if when we first installed a package.
- TZubiri 3y ago
  I build python servers. I've replaced most of the dependencies with just standard library code. Removed Flask for http.server Removed requests for urllib Removed requirements.txt Removed pip Life is good
  - maxerickson 3y ago
    I use urllib.request to avoid having a dependency in little scripts, but I can't say I think that requests is a big supply chain risk.
    - benglish11 3y ago
      It may not be the request package itself but a sub dependency. It only has a few from looking at the repo but something like flask can have a lot (especially with the plugins) and that’s a mainstream and well supported library
JohnFen 3y ago
You're not the only one. I have become hesitant to use applications developed in certain languages and ecosystems (like Python) because they encourage the prolific use of unvetted code not under the control of the developer, although there is no real safe space anymore. It's a cultural shift that has affected almost everything.
- cqqxo4zV46cp 3y ago
  From your perspective, the application itself is untrusted un-vetted third-party code until you yourself have vetted it, no? The fact that you also have to vet dependencies is meaningless implementation detail. You’ve got a bucket of code, you want to run it on your machine, and you decide that you want to vet it first. How does a package boundary change that? You’re describing security theatre.
  - JohnFen 3y ago
    > The fact that you also have to vet dependencies is meaningless implementation detail. I disagree. minimizing dependencies means reducing the risk exposure. That's not meaningless. What I'm really talking about is a cultural change where package managers have made it so easy to just throw a package at a problem that devs tend to do this too much. People using packages to do simple things, people using packages without understanding what the packages do, etc. Every time an application uses a library or package of any sort, that decreases the security of the application. So it's a tradeoff, and I think that too many devs ignore or forget that there's a tradeoff here and just go for "install a package/library to do it" as if it were cost-free. Minimizing the use of external code is not security theater at all. It's good practice. I think avoiding applications that use languages and platforms where lots of external code is common and expected is a reasonable thing. It's absolutely not a complete security solution, but it does reduce the risk.
mopsi 3y ago
Looks absolutely insane to me too. Recently I had to deal with a NPM-based theme for a minor website. It downloaded 140 dependencies. Most of them were trivial like "string-width", which finds the visual width of a character (some Unicode characters may appear as double-width). The package consists of a rather simple 25-line function that tests a character against several if-s in a loop. A function that trivial does not justify adding +1 to the potential sources of supply-chain attacks.
- dboreham 3y ago
  Unfortunately JS people believe this is a feature not a bug.
- qwertox 3y ago
  https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd It's stuff like this which makes me hate npm and the modern Javascript ecosystem in general. You start a new project and pull in a bigger thing like Quasar and npm fetches hundreds of packages and the summary tells you that 5 of them have vulnerabilities in them before you even get started. What am I supposed to do with them? But regarding the string-width problem, im not sure if you've come across "What every developer should know about Unicode" [0], because it appears to be a problem which requires an external package. [0] https://news.ycombinator.com/item?id=37735801 https://news.ycombinator.com/item?id=37735801
  - text0404 3y ago
    this is hardly restricted to the javascript ecosystem. it's a problem with any language where third-party libraries are readily available.
tredre3 3y ago
The current system is crazy to me as well, I've come to refuse to use online dependencies in my projects. It's brittle and it's a security nightmare. If I need a library, I look for a self contained one and I vendor it into the project. In other words I bypass the package manager but I still appreciate the ability to browse the online catalogue. :)
- cjk2 3y ago
  This is how I used to do stuff when I was working on .Net classic years ago. Check the damn dlls into SVN which was all in-house.
devwastaken 3y ago
We need a neutral code signing vendor that does international identity verification. We can fix this tomorrow, but the big three tech corps all make money from charging $$$ for what can be done with an openssl command.
qwertox 3y ago
Im horrified by the extensions I've got installed in VS Code. They are so good but one day one will go rouge and install malware on my machine.
- cjk2 3y ago
  Please don't get me started on VScode. That is basically a remote execution environment. Just adding an extension and opening a file has the cheek to ask if what is on your filesystem is trusted immediately after downloading several tens of megabytes of who knows what for language server and parser. I was using it for LaTeX stuff and programming but I shelved it. I'm on a Mac so it's system provided vim for me and the Apple command line dev tools, mostly for git, llvm and make. It works and I don't need or use any extensions for it or pull anything else onto my computer.
cqqxo4zV46cp 3y ago
How could you think that you’re the only one? This has (thankfully) been a widely discussed attack vector for many years now, and even longer within the more switched-on circles.
- cjk2 3y ago
  I work in a bubble with people who are ignorant.

by cjk2 3y ago

nerdwaller 3y ago

Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code. Depending on how and where you deploy, you can mitigate some of that by isolating the installs and not keeping sensitive information there (e.g. in a docker image). [1] - I don't follow node/npm closely anymore, so this may have changed.

louislang 3y ago
this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.
- PuercoPop 3y ago
  For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust. And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines. For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory. I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)
  - mensfeld 3y ago
    Hey, you have to patch nothing. Nix support was merged to karafka two months ago.
Denvercoder9 3y ago
I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?
- taeric 3y ago
  Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace. More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)
  - dns_snek 3y ago
    How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it. In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.
    - taeric 3y ago
      Honestly, I'm going off memory on python. In the olden days, it was not at all uncommon for devs to want the ability to "sudo pip install foo".
  - Denvercoder9 3y ago
    Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.

seabrookmx 3y ago

You're not the only one! This is why I strongly prefer languages with a comprehensive standard library. I trust my Python/golang/dotnet/whatever install, so the number of third party packages I need to pull in is much smaller and more easily audited.

mooreds 3y ago
What is your audit schedule/process?
- seabrookmx 3y ago
  Well it starts with a culture of taking responsibility when adding a dependency. We want people to look at child dependencies and just think more critically about them before checking in code. This is mostly to prevent bloat but sometimes we catch unmaintained packages or accidentally pulling in a random form rather than the community supported variant, for example. We also run SAST in our gitlab pipelines and include reviewing the output as part of the code review and release process so that we can catch CVE's that may not have been known if when we first installed a package.
TZubiri 3y ago
I build python servers. I've replaced most of the dependencies with just standard library code. Removed Flask for http.server Removed requests for urllib Removed requirements.txt Removed pip Life is good
- maxerickson 3y ago
  I use urllib.request to avoid having a dependency in little scripts, but I can't say I think that requests is a big supply chain risk.
  - benglish11 3y ago
    It may not be the request package itself but a sub dependency. It only has a few from looking at the repo but something like flask can have a lot (especially with the plugins) and that’s a mainstream and well supported library

JohnFen 3y ago

You're not the only one. I have become hesitant to use applications developed in certain languages and ecosystems (like Python) because they encourage the prolific use of unvetted code not under the control of the developer, although there is no real safe space anymore. It's a cultural shift that has affected almost everything.

cqqxo4zV46cp 3y ago
From your perspective, the application itself is untrusted un-vetted third-party code until you yourself have vetted it, no? The fact that you also have to vet dependencies is meaningless implementation detail. You’ve got a bucket of code, you want to run it on your machine, and you decide that you want to vet it first. How does a package boundary change that? You’re describing security theatre.
- JohnFen 3y ago
  > The fact that you also have to vet dependencies is meaningless implementation detail. I disagree. minimizing dependencies means reducing the risk exposure. That's not meaningless. What I'm really talking about is a cultural change where package managers have made it so easy to just throw a package at a problem that devs tend to do this too much. People using packages to do simple things, people using packages without understanding what the packages do, etc. Every time an application uses a library or package of any sort, that decreases the security of the application. So it's a tradeoff, and I think that too many devs ignore or forget that there's a tradeoff here and just go for "install a package/library to do it" as if it were cost-free. Minimizing the use of external code is not security theater at all. It's good practice. I think avoiding applications that use languages and platforms where lots of external code is common and expected is a reasonable thing. It's absolutely not a complete security solution, but it does reduce the risk.

mopsi 3y ago

Looks absolutely insane to me too. Recently I had to deal with a NPM-based theme for a minor website. It downloaded 140 dependencies. Most of them were trivial like "string-width", which finds the visual width of a character (some Unicode characters may appear as double-width). The package consists of a rather simple 25-line function that tests a character against several if-s in a loop. A function that trivial does not justify adding +1 to the potential sources of supply-chain attacks.

dboreham 3y ago
Unfortunately JS people believe this is a feature not a bug.
qwertox 3y ago
https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd It's stuff like this which makes me hate npm and the modern Javascript ecosystem in general. You start a new project and pull in a bigger thing like Quasar and npm fetches hundreds of packages and the summary tells you that 5 of them have vulnerabilities in them before you even get started. What am I supposed to do with them? But regarding the string-width problem, im not sure if you've come across "What every developer should know about Unicode" [0], because it appears to be a problem which requires an external package. [0] https://news.ycombinator.com/item?id=37735801 https://news.ycombinator.com/item?id=37735801
- text0404 3y ago
  this is hardly restricted to the javascript ecosystem. it's a problem with any language where third-party libraries are readily available.

tredre3 3y ago

The current system is crazy to me as well, I've come to refuse to use online dependencies in my projects. It's brittle and it's a security nightmare. If I need a library, I look for a self contained one and I vendor it into the project. In other words I bypass the package manager but I still appreciate the ability to browse the online catalogue. :)

cjk2 3y ago
This is how I used to do stuff when I was working on .Net classic years ago. Check the damn dlls into SVN which was all in-house.

devwastaken 3y ago

We need a neutral code signing vendor that does international identity verification. We can fix this tomorrow, but the big three tech corps all make money from charging $$$ for what can be done with an openssl command.

qwertox 3y ago

Im horrified by the extensions I've got installed in VS Code. They are so good but one day one will go rouge and install malware on my machine.

cjk2 3y ago
Please don't get me started on VScode. That is basically a remote execution environment. Just adding an extension and opening a file has the cheek to ask if what is on your filesystem is trusted immediately after downloading several tens of megabytes of who knows what for language server and parser. I was using it for LaTeX stuff and programming but I shelved it. I'm on a Mac so it's system provided vim for me and the Apple command line dev tools, mostly for git, llvm and make. It works and I don't need or use any extensions for it or pull anything else onto my computer.

cqqxo4zV46cp 3y ago

How could you think that you’re the only one? This has (thankfully) been a widely discussed attack vector for many years now, and even longer within the more switched-on circles.

cjk2 3y ago
I work in a bubble with people who are ignorant.