4 ms·

> The packages had preinstall scripts that automatically launched a script to exfiltrate identifying information from the machine as soon as the build process p

by koolba 6y ago

> The packages had preinstall scripts that automatically launched a script to exfiltrate identifying information from the machine as soon as the build process pulled the packages in. Pre and post install scripts in NPM packages are such a terrible idea. Even when it’s not malware, it usually just a nagging donation request with a deliberate “sleep 5” to slow down your build and keep the text displayed.

joepie91_ 6y ago
I don't understand why people keep endlessly complaining about postinstall scripts. Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. This is really a complete nothingburger.
- minitech 6y ago
  “install” and “execute later” don’t always involve the same permissions. If you apply restrictive sandboxes your code, package managers that aren’t designed to be able to download untrusted code are annoying. Of course, this problem isn’t unique to npm. (It’s actually the opposite – all you need to do with npm is --ignore-scripts, whereas pretty much every other popular package manager I use just makes it impossible.) And yes, you want to sandbox the install too anyway, but it at least needs permissions enough to do its job, i.e. interact with the network somehow. (Although I’m working on a tool to make that fully deterministic so it can never exfiltrate anything.) There’s also the possibility that there’s no “execute” step at all, like installing a dependency tree just to inspect source, or in theory being able to skip auditing unused code paths.
  - seg_lol 6y ago
    Keep editing, we will wait. Eventually you containerize the container and realize that only a single if is enough for everyone.
    - minitech 6y ago
      > Eventually you containerize the container and realize that only a single if is enough for everyone. You either have a typo somewhere or are not being very clear. Either way, keep editing.
      - seg_lol 6y ago
        That was a sweet self own. I really enjoyed this.
- koolba 6y ago
  > Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, What does "banned by npm" mean? Here's an example from the source of the latest version of nodemailer (with 1.4M weekly downloads) sleeping for 4,100 ms on every install so that it can show a "Sponsor us to remove this lag" message: https://github.com/nodemailer/nodemailer/blob/a455716a22d22f80e1ffdfd7171e92123ab38cc8/postinstall.js#L96-L101 https://github.com/nodemailer/nodemailer/blob/a455716a22d22f... > and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. It's fine to have a standard mechanism for postinstall steps. It should be opt-in by the end user rather than opt-out. That way people know that they're running additional code and ideally selectively pick which packages are allowed to do so. The vast majority of packages do not need it anyway as they do not have C++ bindings or need to generate data. The defaults for NPM are such that you have to know quite a bit of how NPM works to download a package and inspect the contents without executing random code. > This is really a complete nothingburger. It's defensive in depth. With the default being to execute remote code, a single typo could be installing a package that immediately runs malware.
bennofs 6y ago
Are there many package manager that do not have either pre-, post- or build scripts or plugins allowing arbitrary code execution during build? pkg managers that do have that: cargo (build.rs), pip (setup.py), npm (install scripts), apt/rpm/pacman (postinstall hooks) Maybe the only exceptions are Go and Java package managers?
- dathinab 6y ago
  I'm pretty sure all package managers which produce packages which might bind to C do have "some form" of pre-, post- or build scripts. The reason is simple because without it you can't properly bind to system libraries. And even without, the supply chain attack still works against at least developers as packages are not just build but also run, often without any additional sandbox. (E.g. you run tests in the library you build which pulled in a corrupted package). The main problem here are not build scripts (they still are a problem, just not the main) but that some of the build tools like npm haven't been build with security but convenience as priority and security was just an afterthought. For example npm did (still does?, idk) not validate if the packag freezing file and the project dependencies match so you could try to sneak in bad dependency sources. Also for things which are classical system package managers (i.e. not build tools) like apt/rpm/pacman it build scripts really does not matter at all. The reason is that what you produce will be placed and run in your system without sand-boxing anyway, so it's a bit different then a build tool which is often used to build binaries (installers, etc.) at one place and then distribute them to many other places. Edit: Another attack vector is to bring in a corrupted package which then "accesses" the code and data of another package, this could use speculative pointer accesses or similar but in languages like Java,Python, JavaScript you often can use reflections or overriding standard functions to archive this much more reliable.
- kyrra 6y ago
  Go considers this to be a security bug, as was seen recently with: https://blog.golang.org/path-security https://blog.golang.org/path-security (talked about briefly here: https://news.ycombinator.com/item?id=25881212 https://news.ycombinator.com/item?id=25881212)

by koolba 6y ago

joepie91_ 6y ago

I don't understand why people keep endlessly complaining about postinstall scripts. Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. This is really a complete nothingburger.

minitech 6y ago
“install” and “execute later” don’t always involve the same permissions. If you apply restrictive sandboxes your code, package managers that aren’t designed to be able to download untrusted code are annoying. Of course, this problem isn’t unique to npm. (It’s actually the opposite – all you need to do with npm is --ignore-scripts, whereas pretty much every other popular package manager I use just makes it impossible.) And yes, you want to sandbox the install too anyway, but it at least needs permissions enough to do its job, i.e. interact with the network somehow. (Although I’m working on a tool to make that fully deterministic so it can never exfiltrate anything.) There’s also the possibility that there’s no “execute” step at all, like installing a dependency tree just to inspect source, or in theory being able to skip auditing unused code paths.
- seg_lol 6y ago
  Keep editing, we will wait. Eventually you containerize the container and realize that only a single if is enough for everyone.
  - minitech 6y ago
    > Eventually you containerize the container and realize that only a single if is enough for everyone. You either have a typo somewhere or are not being very clear. Either way, keep editing.
    - seg_lol 6y ago
      That was a sweet self own. I really enjoyed this.
koolba 6y ago
> Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, What does "banned by npm" mean? Here's an example from the source of the latest version of nodemailer (with 1.4M weekly downloads) sleeping for 4,100 ms on every install so that it can show a "Sponsor us to remove this lag" message: https://github.com/nodemailer/nodemailer/blob/a455716a22d22f80e1ffdfd7171e92123ab38cc8/postinstall.js#L96-L101 https://github.com/nodemailer/nodemailer/blob/a455716a22d22f... > and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. It's fine to have a standard mechanism for postinstall steps. It should be opt-in by the end user rather than opt-out. That way people know that they're running additional code and ideally selectively pick which packages are allowed to do so. The vast majority of packages do not need it anyway as they do not have C++ bindings or need to generate data. The defaults for NPM are such that you have to know quite a bit of how NPM works to download a package and inspect the contents without executing random code. > This is really a complete nothingburger. It's defensive in depth. With the default being to execute remote code, a single typo could be installing a package that immediately runs malware.

bennofs 6y ago

Are there many package manager that do not have either pre-, post- or build scripts or plugins allowing arbitrary code execution during build? pkg managers that do have that: cargo (build.rs), pip (setup.py), npm (install scripts), apt/rpm/pacman (postinstall hooks) Maybe the only exceptions are Go and Java package managers?

dathinab 6y ago
I'm pretty sure all package managers which produce packages which might bind to C do have "some form" of pre-, post- or build scripts. The reason is simple because without it you can't properly bind to system libraries. And even without, the supply chain attack still works against at least developers as packages are not just build but also run, often without any additional sandbox. (E.g. you run tests in the library you build which pulled in a corrupted package). The main problem here are not build scripts (they still are a problem, just not the main) but that some of the build tools like npm haven't been build with security but convenience as priority and security was just an afterthought. For example npm did (still does?, idk) not validate if the packag freezing file and the project dependencies match so you could try to sneak in bad dependency sources. Also for things which are classical system package managers (i.e. not build tools) like apt/rpm/pacman it build scripts really does not matter at all. The reason is that what you produce will be placed and run in your system without sand-boxing anyway, so it's a bit different then a build tool which is often used to build binaries (installers, etc.) at one place and then distribute them to many other places. Edit: Another attack vector is to bring in a corrupted package which then "accesses" the code and data of another package, this could use speculative pointer accesses or similar but in languages like Java,Python, JavaScript you often can use reflections or overriding standard functions to archive this much more reliable.
kyrra 6y ago
Go considers this to be a security bug, as was seen recently with: https://blog.golang.org/path-security https://blog.golang.org/path-security (talked about briefly here: https://news.ycombinator.com/item?id=25881212 https://news.ycombinator.com/item?id=25881212)