24 ms·

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your ap

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't do packages. I don't want that level of control over other people's projects, it's scary as fuck. I have enough responsibilities as is. I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. IMO, re-inventing the wheel sometimes is not the worst thing. Including code written by strangers that you haven't inspected and that they can remotely modify is. Stop using packages that are essentially wrappers around three-line Stack Overflow answers. In this case, the old-fashioned way is the better way, and you'll have a hard time convincing me otherwise. [0]: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ https://qz.com/646467/how-one-programmer-broke-the-internet-...

blackoil 5y ago
Extending your logic to extreme you'll not be able to use any OS, compiler, processor unless you build it. We can't build practically anything of use without any 3rd party library in any language/platform. The problem here is not packages but lack of stdlib and tendency of package writers to have shit ton of further dependencies.
MaxBarraclough 5y ago
> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.
- rajin444 5y ago
  There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.
  - MaxBarraclough 5y ago
    Stale libraries are more likely to contain known security vulnerabilities.
    - temp12192021 5y ago
      I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.
      - cerved 5y ago
        I don't recommend this approach
        temp12192021 5y ago
        I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?
        cerved 5y ago
        You're committing something that is not a part of your source code into your version control system, assuming your source code is git, this is irrevocable without rewriting history. It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it. As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler. Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver
        charcircuit 5y ago
        The benefit of having your dependencies vendored is that you have everything needed to build your application without having to download stuff from the internet. You get to ensure what exactly makes it into your application. Yes, it will increase the repository size, but I don't see why merge conflicts would be a problem since you are just replacing a file with a new version.
- notRobot 5y ago
  Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.
  - rich_sasha 5y ago
    In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.
    - cerved 5y ago
      look at diffs?
      - apetresc 5y ago
        Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
        dane-pgp 5y ago
        Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
        naasking 5y ago
        Nice link, thanks! Good to see Mark Miller is still working in this space.
- bee_rider 5y ago
  Packing is most of the point of a distro. They are specifically taking on that responsibility. They also have a better perspective to handle overall compatibility. In a sense you've pointed out the alternative to having the programmer handling the packaging -- having some third party package and distribute. And this separation of responsibility turns out be almost always be a better solution. Distribution and coding are, after all, two full jobs (without 100% skill overlap). Plus, hopefully it indicates that at least two sets of eyeballs have at least glanced at the code (not the full desired many-eyeball outcome, but as good as we can expect sometimes).
  - mschuster91 5y ago
    Given that Debian (and its descendants...) packages a shitload of npm packages, it's a wide stretch to say there is more QA for these packages from the Debian side than there is from the npm side. The one thing that Debian provides is that in the case there is a security issue, admins worldwide only need to do "apt update && apt upgrade" and they are safe, without having to check all of the software that runs on their servers (as long as said software comes from Debian, that is!).
    - bee_rider 5y ago
      I do think people would be served, generally, by being more aware of the fact that distros are not some doing some hardcore security vetting. But the alternative is just to use whatever was pushed up to NPM, right? In that case, Debian packager+NPM push > NPM push by definition, unless the Debian packager somehow provides negative QA, which seems unlikely. (Also, on the incredibly unlikely offchance that some Debian packager reads this comment -- your work is incredibly useful and I very much appreciate it, just trying to be realistic about what exactly is provided by your group!)
      - _-david-_ 5y ago
        > unless the Debian packager somehow provides negative QA, which seems unlikely It has happened before. Last time there was anything major was over a decade ago though. https://lists.debian.org/debian-security-announce/2008/msg00152.html https://lists.debian.org/debian-security-announce/2008/msg00...
heluser 5y ago
To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them
- julianlam 5y ago
  npm does as well, they made this change after left-pad. You also can't unpublish once a single person has downloaded the package, I believe.
- mjlawson 5y ago
  This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.
  - throw_m239339 5y ago
    > This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
    - dathinab 5y ago
      Except if they have reason to believe the code was uploaded with the permission of the copyright holder. The they have gotten the right for npm to distribute the source code in context of npm.
      - throw_m239339 5y ago
        > The they have gotten the right for npm to distribute the source code in context of npm. There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None. The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.
drawkbox 5y ago
Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to worse than DLL hell, telemetry tracking/data, and attack vectors that can take down or target many, many systems.
- xg15 5y ago
  How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.
  - hombre_fatal 5y ago
    You also have to rely on all of your dependencies doing that for their dependencies and so on. It’s really a mindset/vigilance you need for the whole ecosystem.
    - xg15 5y ago
      Transitive dependencies are also your dependencies, even if you didn't consciously include them. So in an ideal world, you should vet all changes to dependencies of your codebase, including transitive dependencies. Whether or not this would be compatible with the way dependencies are used today is another question.
      - hnick 5y ago
        I'm not even sure it's not a fool's errand with the current software ecosystem. I think at some point it will have to be a language level feature. The ability to sandbox or provide permissions to packages/functions. Just like our OS had to, just like browsers had to, just like phones had to. Our code is the platform, the packages the apps. It's a similar use case. If I could download a module, and tell the compiler this module, and everything it uses (including packages that I also use, but through a different call tree) will never access the network or write to disk, it'd help grant some small peace of mind in terms of security at least.
pc86 5y ago
Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context. Pegging to a specific version limits exposure. Syncing these packages to your own on-prem/isolated environment limits it further. Deploying all changes to a test/staging environment where they're reviewed first limits it even more. I mean yeah if your build process takes @latest of all your packages and then pushes it right into production, that opens you up to a lot of risk. It's also incredibly stupid for anything beyond a personal project (and probably even those). This doesn't strike me as a weakness in package management, it strikes me as a weakness in doing package management wrong.
- ratorx 5y ago
  The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether this default behaviour should change is not is also a security tradeoff. Pinning versions means that you will keep using an insecure version of a dependency until you update, whereas using a semver compatible version allows you to “automatically” pick up a fixed and compatible version. In practice however with lock files and local caches, the developer always needs to update for security patches anyway. However, given the current NPM landscape (with packages having numerous small dependencies from a large variety of authors), going towards the former instead of the latter is definitely makes a lot more sense.
  - jka 5y ago
    To boost this: it's worth reading about the difference between "npm install" and "npm clean-install". The "ignore-scripts" flag/configuration setting can also be valuable.
  - 5y ago
oneoff786 5y ago
I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?
- tehbeard 5y ago
  stdlib of JS vs python or php is absolutely tiny. It's improving over time, but it's still playing catchup.
  - Sebb767 5y ago
    And if you're optimizing for the browser, you can't count on the improvements being there. So you still want to use third-party libraries for their polyfills.
- fault1 5y ago
  npm (or yarn) for the most part works much better than python package managers
- aaaaaaaaaaab 5y ago
  They don’t know better.
- gremlinsinc 5y ago
  I prefer to look at the code, decide if A. it's worth it, B. it wouldn't be funner/better to just clone it as a 'plugin' in my own code, and C. it looks like it has a good team/support around it.
- tjpnz 5y ago
  They took the Unix philosophy of doing one thing well and drove it off a cliff.
  - broknbottle 5y ago
    I literally lol’d. Thank you for the laugh
fxtentacle 5y ago
In my opinion, golang does this correctly. You can just git submodule the source code of your dependencies. That way, you're always in control over what gets updated and when.
- dagmx 5y ago
  That's true of most package managers too though. It's very trivial to vendor the code yourself in both NPM and Cargo for example.
daveevad 5y ago
the whole point of the internet > are literally remote code exec vulns
- IYasha 5y ago
  I applaud you ) HTML-based WEB1.0 was so much safer and faster...
gremlinsinc 5y ago
I often find myself... ripping out a lot of what I 'need' into something that maybe isn't always well-maintainable, but it's my fuckfest of code, and if something breaks it's because I choose to eff it up myself. Esp, when it's something API related, most php api sdk's are poorly maintained anyways and need updating as I go, plus I usually learn the api pretty well as I rebuild and test the new classes. Ironically, I'm working on a laravel package myself that i'm hoping to maintain (and turn into a viable side project) that's basically jetstream with SaaS components, and UI elements... (think ui component libraries + laravel jetstream + extra SaaS/ERP things like tenancy beyond just teams but..like Org which can have teams, projects, employees, and each user can belong to multiple orgs, teams, projects, and have attached profiles to each. For a lot of the UI stuff, I've basically repacked MIT stuff for tailwindcss components, and laravel/livewire added some extra configurations and options, and made it so you don't need Jetstream, just this thing... so a lot of it is actually other's packaged code pulled into one package so, ideally there's one dependency that could even be easily forked and repurposed for a team's needs but cover a lot of boilerplate possibilities.
ec109685 5y ago
I’m surprised the AWS SDK doesn’t pin its dependencies and put new versions through its paces before letting end users possibly use a compromised utility with catastrophic results.
jayflux 5y ago
> At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] That hasn’t been true for 7 years now, it was changed after the left-pad incident and that article everyone keeps quoting is from 2016. Deleting a GitHub repo or a package does not remove it from npm as part of their policy.
- hsbauauvhabzb 5y ago
  Does updating it with junk take any longer?
  - brundolf 5y ago
    Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production.
    - pinum 5y ago
      >You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }
      - brundolf 5y ago
        I mean... that's true if you ever use any code that you haven't read through line-by-line. That's not specific to package managers in general, much less NPM, so I think it's out of scope for this discussion.
hsbauauvhabzb 5y ago
I wholeheartedly agree with this commentary. Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I feel like the implicit trust makes even using popular packages such as react seem a bit sketchy. I’m betting react devs audit upstream packages, but I don’t know if any formal statements that they do. Multiply that by all the other common projects and you have a huge auditability issue.
- sylens 5y ago
  >> Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I would think that the sheer popularity of the JavaScript (and therefore Node) ecosystems contributes partially to it - there's a massive industry out there about skilling new developers up in JavaScript, Node, and some front-end frameworks. But it definitely doesn't explain all of it.
  - hsbauauvhabzb 5y ago
    I actually attribute it more to the micro package architecture, but maybe I don’t know it well enough. I don’t know any other ecosystem with a left-padding package for instance.
- jamesfinlayson 5y ago
  I noticed a few years ago that my bank didn't use much in the way of dependencies for their website (possibly just jQuery) - clearly they agree that depending on React opens you up to depending on... who knows what.
  - hsbauauvhabzb 5y ago
    I’ve considered that, there are a few scenarios: - some sites favor security over UI/UX - some organisations have the funding to review packages such as react In the future I think security bureaucracy will prevent security conscious organisations from having nice new things. This happens in places like the military (who were known to use WinXP long after public EOL).
synergy20 5y ago
a peer-viewed standard library is key, just like what glibc or libstdcpp for c/c++ that covers 80% of the normal use cases, the rest you're in charge for its quality check. with javascript/node, you can write 100 lines of code then pulling 100 modules, it's quite different and hard to assure its quality and safety over long period of time. I heard rust also has a very small stdlib, that gave me concerns, but I don't code rust, I do hope though all languages can have a stdlib that is 20% the size covers 80% of normal needs.
Ros2 5y ago
True enough overall, but I'm surprised no one has let you know that NPM actually doesn't allow you to delete packages anymore (after the left-pad controversy). You have to email them and then you are judged by how many downloads you have. If you have users relying on your package, they do not let you delete it.
xwolfi 5y ago
Yes ! Re-inventing the wheel is literally perfectly fine. You take a round piece of wood, make it roll, and BAM you re-invented the wheel. No need to go to Toyota, buy their wheel making machinery for millions and run that to make a little thing roll. It's the same with packages, it's FINE to have to redo a bit thousand separator logic, do you truly need a transitive dependency hell with ^1.1.1 in the package list that auto upgrade at random !!? I've had several cases where the whole company is all hands on deck because some dep somewhere moved up and all subsequent builds fail - what are people doing in node, we never had these issues in Java.
JimDabell 5y ago
> Packages are literally remote code exec vulns in the hands of package authors Something mentioned in this article caught my eye: > While searching for Marak’s libraries, I found this npm-test-access library. This library seems to be used for what the name describes: to test access to NPM. Marak seems like a very capable software engineer, and it’s unclear to me why he’d need a package like this. So, this make me personally doubt a little bit if Marak is really behind all of this, or if maybe his account got compromised, or if something else it at play. — [0] https://jworks.io/the-faker-js-saga-continues/ https://jworks.io/the-faker-js-saga-continues/ If you wanted to take over other people’s NPM packages by pushing a compromised update to one of your own widely used packages, the first thing it would do is check to see if the victim had access to publish to NPM. Marek, who has just started publishing malicious updates to his own widely used packages, has just created a package to check for access to NPM.
- zaroth 5y ago
  This seems like irresponsible speculation and insinuating that Marek is about to commit a felony? I’d rather skip the character assassination based on hypothetical future actions please, and focus on what’s actually happened.
  - JimDabell 5y ago
    > Packages are literally remote code exec vulns in the hands of package authors There are 20m+ weekly downloads of the colors package alone. He has what amounts to remote execution privileges to people using that package. When the subject of compromised packages comes up and he’s demonstrated that he’s willing to publish malicious updates, it’s completely fair to wonder what else he’s willing to do with that level of access to that many systems. It’s irresponsible not to consider what his packages can do to your systems.
  - CRConrad 5y ago
    > This seems like irresponsible speculation and insinuating that Marek is about to commit a felony? No, it's speculation that Marek didn't do any of this, but that instead his account was hacked. You either responded to the wrong comment by mistake, or totally misunderstood the one you replied to.
cookiengineer 5y ago
I wish there was a package manager for node.js that is made for "static" or offline usage, and is able to compare headers of libraries before upgrading them. But here we are, 10 years in, with nobody giving a damn about semantic versioning. Life could be so much easier with an actual package manager that isn't just some git clone replacement.
deleted 5y ago
[deleted]
- deleted 5y ago
  [deleted]
lrvick 5y ago
Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mirrors JS many companies import ;)
- 0x0nyandesu 5y ago
  You can say the same thing about the entire Linux stack
  - mPReDiToR 5y ago
    Unless you're using LFS, of course. The problem you describe isn't Linux, it's Linux Distributions. Where would you draw the line? Source packages are available, and if the binaries don't match the code a distro would soon be outed a la "many eyes" thinking. We have to trust some or none. Get the top off that chip, see if the factory put an extra core in for the NSA (IME).
  - asddubs 5y ago
    any operating system, really, if you want to play that game
  - mid-kid 5y ago
    Not really, individual package developers don't have as much inmediate control over the repository's state as they do with NPM. Packages go through a review by one of the trusted developers and sometimes automated QA and testing (including as of late reproducibility testing, i.e. does the source match the binary?), before being uploaded to the repository. If you can't trust the team behind the distro, then sure, your supply chain is compromised, but it's significantly less likely for a single package developer to cause any damage, as all the big distros have rather extensive policy and procedures to prevent such things.
    - 5y ago
raxxorrax 5y ago
You don't have to always pull the latest release on utility packages if you want to evade such problems. Sure, you would need to audit a lot of packages in certain languages... But yes, I prefer to "vendor" my dependencies too, especially on large projects.
- lrvick 5y ago
  Security vulns are fixed daily in most webapp dependency trees. If you do not update you are vulnerable to piles of issues anyone can look up. If you update blindly you may import new obvious supply chain attacks. The solution is actually doing code review. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. The extra effort to use a minimal framework and some cherry picked functions may be worth it for most orgs.
heurisko 5y ago
> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. This offers no benefit in terms of security, over a package dependency locked at a specific version. The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead of curl. It doesn't contribute to security at all, it just makes it awkward for other people to use your code. I would also assume that people are connecting your library to a package management system anyway, to overcome this unnecessary hurdle e.g. https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository https://getcomposer.org/doc/05-repositories.md#loading-a-pac...
- Bolkan 5y ago
  By using automatic upgrades you trade theoretical security fixes for undefined behaviour and bugs. One is clearly much worse than the other.
  - heurisko 5y ago
    Composer (PHP dependency manager) does not force you into doing automatic upgrades. You can keep a dependency fixed at a particular version indefinitely. You can also point composer at a private vendored repository of the dependency if you don't trust the upstream server.
- notRobot 5y ago
  I do this solely because I don't like packages, I don't use them, and I don't want to maintain them for other people. To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. The code I write is primarily for me. Other people can use it if they want to, and I hope it helps them, but I don't care much about how many chose to use it or not. If they do, they have to work with my preferred way of distributing code. There have been times where third parties have included my code in their packages, but I'm explicitly not the package author in those cases, so it (the package) is not my responsibility.
maze-le 5y ago
> At the very least, it takes them under a minute to break your app, simply by deleting their package. Not really, if you pin your versions exactly and don't do auto-updates. This also means that you have to update your packages manually and inspect what the latest versions are doing -- which is good practive anyway. NPM packages can not be depublished any longer as far as I know.
indigochill 5y ago
IMO this is what forking is for. You don't have to rewrite it, you simply copy it somewhere that it isn't going to change unless you make the change happen, because some third party screwing around with your production code is just Bad News even if they have the best of intentions. You should still look over it and make sure it's not obviously malicious, but simply using forks or local repos of open source packages would probably save 98% of these kinds of headaches (with a 2% allowance for insecure/malicious open source code).
asah 5y ago
Omg y re making list for packages. It's not a technical cure, but it connects developers and library consumers and creates far more accountability. GitHub issues can work in theory but in practice, developers are often slow to respond i.e. GI is where problems go to die.
harperlee 5y ago
How complicated it is to just clone the repo and point your apps to your forked version? That way this would not have happened.
goodpoint 5y ago
> Packages are literally remote code exec vulns in the hands of package authors Reminder: this is why traditional Linux distributions exist.
jamaicahest 5y ago
I have worked with several banks as a devops consultant and have helped implement self-hosted proxy repositories for NPM, NuGet, etc. These proxies save a copy of every package downloaded and store it locally for as long as the bank wants. Developers are then blocked from downloading from any other repository than these proxies. This solves the problem of packages being taken offline, but it does very little against malicious code on new versions of the package. However it also provides the ability to reproduce code X years into the past, as can be required of banks by financial regulators in various countries. As always it is a cost/benefit trade-off: what is the benefit to auditing every package vs. the cost of auditing every package?
daudmalik06 5y ago
Totally agree with you, i think it's time to think carefully and immediately start using services like Vulert(https://bit.ly/336DZub https://bit.ly/336DZub) that tracks your open-source softwares for free and notifies you in real-time if any seccurity issue is found within your applciation. it's free. atleast in this way we can secure ourselves from supply chain attacks

blackoil 5y ago

Extending your logic to extreme you'll not be able to use any OS, compiler, processor unless you build it. We can't build practically anything of use without any 3rd party library in any language/platform. The problem here is not packages but lack of stdlib and tendency of package writers to have shit ton of further dependencies.

MaxBarraclough 5y ago

> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.

rajin444 5y ago
There’s no reason people can’t keep local caches of these libs if it is a major concern. This seems like a non issue.
- MaxBarraclough 5y ago
  Stale libraries are more likely to contain known security vulnerabilities.
  - temp12192021 5y ago
    I know it's bad practice, but I just checkin vendor files/libs to source control. Makes auditing new releases of libraries a bit easier. Assuming they aren't binaries of course.
    - cerved 5y ago
      I don't recommend this approach
      - temp12192021 5y ago
        I haven't had issues yet, but it's considered bad practice for a reason. What headaches am I in store for?
        cerved 5y ago
        You're committing something that is not a part of your source code into your version control system, assuming your source code is git, this is irrevocable without rewriting history. It's mainly a nuisance. It takes up unnecessary space. Introduces possible annoying merge conflicts etc etc and it's not trivial to remove it. As reference, I migrated repositories from TFVC to git. One team relies on checking in packages into source control, another one does so far less. One repo is significantly nimbler. Checking packages into source control is making your VCS a package manager. Presumably you have one. Don't hammer nails with your screwdriver
        charcircuit 5y ago
        The benefit of having your dependencies vendored is that you have everything needed to build your application without having to download stuff from the internet. You get to ensure what exactly makes it into your application. Yes, it will increase the repository size, but I don't see why merge conflicts would be a problem since you are just replacing a file with a new version.
notRobot 5y ago
Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time.
- rich_sasha 5y ago
  In practical terms, can they really be audited? This is at least obvious DoS, I’m sure it’s easy to slip in an innocuous line that, dunno, ships your ssh keys to some rando server.
  - cerved 5y ago
    look at diffs?
    - apetresc 5y ago
      Can you really say, with a straight face, that you inspect the diffs of your entire dependency closure every time you deploy an update? With the level of scrutiny required to detect a maliciously-obfuscated security exploit? If you can, you're an infinitely more diligent developer than I am, that's for sure.
      - dane-pgp 5y ago
        Fortunately the problem could become more tractable if something like SES / Endo takes off: "Endo protects program integrity both in-process and in distributed systems. SES protects local integrity, defending an application against supply chain attacks: hacks that enter through upgrades to third-party dependencies. Endo does this by encouraging the Principle of Least Authority. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies." https://github.com/endojs/endo https://github.com/endojs/endo
        naasking 5y ago
        Nice link, thanks! Good to see Mark Miller is still working in this space.
bee_rider 5y ago
Packing is most of the point of a distro. They are specifically taking on that responsibility. They also have a better perspective to handle overall compatibility. In a sense you've pointed out the alternative to having the programmer handling the packaging -- having some third party package and distribute. And this separation of responsibility turns out be almost always be a better solution. Distribution and coding are, after all, two full jobs (without 100% skill overlap). Plus, hopefully it indicates that at least two sets of eyeballs have at least glanced at the code (not the full desired many-eyeball outcome, but as good as we can expect sometimes).
- mschuster91 5y ago
  Given that Debian (and its descendants...) packages a shitload of npm packages, it's a wide stretch to say there is more QA for these packages from the Debian side than there is from the npm side. The one thing that Debian provides is that in the case there is a security issue, admins worldwide only need to do "apt update && apt upgrade" and they are safe, without having to check all of the software that runs on their servers (as long as said software comes from Debian, that is!).
  - bee_rider 5y ago
    I do think people would be served, generally, by being more aware of the fact that distros are not some doing some hardcore security vetting. But the alternative is just to use whatever was pushed up to NPM, right? In that case, Debian packager+NPM push > NPM push by definition, unless the Debian packager somehow provides negative QA, which seems unlikely. (Also, on the incredibly unlikely offchance that some Debian packager reads this comment -- your work is incredibly useful and I very much appreciate it, just trying to be realistic about what exactly is provided by your group!)
    - _-david-_ 5y ago
      > unless the Debian packager somehow provides negative QA, which seems unlikely It has happened before. Last time there was anything major was over a decade ago though. https://lists.debian.org/debian-security-announce/2008/msg00152.html https://lists.debian.org/debian-security-announce/2008/msg00...

heluser 5y ago

To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them

julianlam 5y ago
npm does as well, they made this change after left-pad. You also can't unpublish once a single person has downloaded the package, I believe.
mjlawson 5y ago
This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.
- throw_m239339 5y ago
  > This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
  - dathinab 5y ago
    Except if they have reason to believe the code was uploaded with the permission of the copyright holder. The they have gotten the right for npm to distribute the source code in context of npm.
    - throw_m239339 5y ago
      > The they have gotten the right for npm to distribute the source code in context of npm. There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None. The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.

drawkbox 5y ago

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to worse than DLL hell, telemetry tracking/data, and attack vectors that can take down or target many, many systems.

xg15 5y ago
How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.
- hombre_fatal 5y ago
  You also have to rely on all of your dependencies doing that for their dependencies and so on. It’s really a mindset/vigilance you need for the whole ecosystem.
  - xg15 5y ago
    Transitive dependencies are also your dependencies, even if you didn't consciously include them. So in an ideal world, you should vet all changes to dependencies of your codebase, including transitive dependencies. Whether or not this would be compatible with the way dependencies are used today is another question.
    - hnick 5y ago
      I'm not even sure it's not a fool's errand with the current software ecosystem. I think at some point it will have to be a language level feature. The ability to sandbox or provide permissions to packages/functions. Just like our OS had to, just like browsers had to, just like phones had to. Our code is the platform, the packages the apps. It's a similar use case. If I could download a module, and tell the compiler this module, and everything it uses (including packages that I also use, but through a different call tree) will never access the network or write to disk, it'd help grant some small peace of mind in terms of security at least.

pc86 5y ago

Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context. Pegging to a specific version limits exposure. Syncing these packages to your own on-prem/isolated environment limits it further. Deploying all changes to a test/staging environment where they're reviewed first limits it even more. I mean yeah if your build process takes @latest of all your packages and then pushes it right into production, that opens you up to a lot of risk. It's also incredibly stupid for anything beyond a personal project (and probably even those). This doesn't strike me as a weakness in package management, it strikes me as a weakness in doing package management wrong.

ratorx 5y ago
The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether this default behaviour should change is not is also a security tradeoff. Pinning versions means that you will keep using an insecure version of a dependency until you update, whereas using a semver compatible version allows you to “automatically” pick up a fixed and compatible version. In practice however with lock files and local caches, the developer always needs to update for security patches anyway. However, given the current NPM landscape (with packages having numerous small dependencies from a large variety of authors), going towards the former instead of the latter is definitely makes a lot more sense.
- jka 5y ago
  To boost this: it's worth reading about the difference between "npm install" and "npm clean-install". The "ignore-scripts" flag/configuration setting can also be valuable.
- 5y ago

oneoff786 5y ago

I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?

tehbeard 5y ago
stdlib of JS vs python or php is absolutely tiny. It's improving over time, but it's still playing catchup.
- Sebb767 5y ago
  And if you're optimizing for the browser, you can't count on the improvements being there. So you still want to use third-party libraries for their polyfills.
fault1 5y ago
npm (or yarn) for the most part works much better than python package managers
aaaaaaaaaaab 5y ago
They don’t know better.
gremlinsinc 5y ago
I prefer to look at the code, decide if A. it's worth it, B. it wouldn't be funner/better to just clone it as a 'plugin' in my own code, and C. it looks like it has a good team/support around it.
tjpnz 5y ago
They took the Unix philosophy of doing one thing well and drove it off a cliff.
- broknbottle 5y ago
  I literally lol’d. Thank you for the laugh

fxtentacle 5y ago

In my opinion, golang does this correctly. You can just git submodule the source code of your dependencies. That way, you're always in control over what gets updated and when.

dagmx 5y ago
That's true of most package managers too though. It's very trivial to vendor the code yourself in both NPM and Cargo for example.

daveevad 5y ago

the whole point of the internet > are literally remote code exec vulns

IYasha 5y ago
I applaud you ) HTML-based WEB1.0 was so much safer and faster...

gremlinsinc 5y ago

I often find myself... ripping out a lot of what I 'need' into something that maybe isn't always well-maintainable, but it's my fuckfest of code, and if something breaks it's because I choose to eff it up myself. Esp, when it's something API related, most php api sdk's are poorly maintained anyways and need updating as I go, plus I usually learn the api pretty well as I rebuild and test the new classes. Ironically, I'm working on a laravel package myself that i'm hoping to maintain (and turn into a viable side project) that's basically jetstream with SaaS components, and UI elements... (think ui component libraries + laravel jetstream + extra SaaS/ERP things like tenancy beyond just teams but..like Org which can have teams, projects, employees, and each user can belong to multiple orgs, teams, projects, and have attached profiles to each. For a lot of the UI stuff, I've basically repacked MIT stuff for tailwindcss components, and laravel/livewire added some extra configurations and options, and made it so you don't need Jetstream, just this thing... so a lot of it is actually other's packaged code pulled into one package so, ideally there's one dependency that could even be easily forked and repurposed for a team's needs but cover a lot of boilerplate possibilities.

ec109685 5y ago

I’m surprised the AWS SDK doesn’t pin its dependencies and put new versions through its paces before letting end users possibly use a compromised utility with catastrophic results.

jayflux 5y ago

> At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] That hasn’t been true for 7 years now, it was changed after the left-pad incident and that article everyone keeps quoting is from 2016. Deleting a GitHub repo or a package does not remove it from npm as part of their policy.

hsbauauvhabzb 5y ago
Does updating it with junk take any longer?
- brundolf 5y ago
  Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production.
  - pinum 5y ago
    >You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }
    - brundolf 5y ago
      I mean... that's true if you ever use any code that you haven't read through line-by-line. That's not specific to package managers in general, much less NPM, so I think it's out of scope for this discussion.

hsbauauvhabzb 5y ago

I wholeheartedly agree with this commentary. Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I feel like the implicit trust makes even using popular packages such as react seem a bit sketchy. I’m betting react devs audit upstream packages, but I don’t know if any formal statements that they do. Multiply that by all the other common projects and you have a huge auditability issue.

sylens 5y ago
>> Any insight into why this is so much the case with npm but not seemingly as bad in other ecosystems (dependency trees in npm are huge). I would think that the sheer popularity of the JavaScript (and therefore Node) ecosystems contributes partially to it - there's a massive industry out there about skilling new developers up in JavaScript, Node, and some front-end frameworks. But it definitely doesn't explain all of it.
- hsbauauvhabzb 5y ago
  I actually attribute it more to the micro package architecture, but maybe I don’t know it well enough. I don’t know any other ecosystem with a left-padding package for instance.
jamesfinlayson 5y ago
I noticed a few years ago that my bank didn't use much in the way of dependencies for their website (possibly just jQuery) - clearly they agree that depending on React opens you up to depending on... who knows what.
- hsbauauvhabzb 5y ago
  I’ve considered that, there are a few scenarios: - some sites favor security over UI/UX - some organisations have the funding to review packages such as react In the future I think security bureaucracy will prevent security conscious organisations from having nice new things. This happens in places like the military (who were known to use WinXP long after public EOL).

synergy20 5y ago

a peer-viewed standard library is key, just like what glibc or libstdcpp for c/c++ that covers 80% of the normal use cases, the rest you're in charge for its quality check. with javascript/node, you can write 100 lines of code then pulling 100 modules, it's quite different and hard to assure its quality and safety over long period of time. I heard rust also has a very small stdlib, that gave me concerns, but I don't code rust, I do hope though all languages can have a stdlib that is 20% the size covers 80% of normal needs.

Ros2 5y ago

True enough overall, but I'm surprised no one has let you know that NPM actually doesn't allow you to delete packages anymore (after the left-pad controversy). You have to email them and then you are judged by how many downloads you have. If you have users relying on your package, they do not let you delete it.

xwolfi 5y ago

Yes ! Re-inventing the wheel is literally perfectly fine. You take a round piece of wood, make it roll, and BAM you re-invented the wheel. No need to go to Toyota, buy their wheel making machinery for millions and run that to make a little thing roll. It's the same with packages, it's FINE to have to redo a bit thousand separator logic, do you truly need a transitive dependency hell with ^1.1.1 in the package list that auto upgrade at random !!? I've had several cases where the whole company is all hands on deck because some dep somewhere moved up and all subsequent builds fail - what are people doing in node, we never had these issues in Java.

JimDabell 5y ago

> Packages are literally remote code exec vulns in the hands of package authors Something mentioned in this article caught my eye: > While searching for Marak’s libraries, I found this npm-test-access library. This library seems to be used for what the name describes: to test access to NPM. Marak seems like a very capable software engineer, and it’s unclear to me why he’d need a package like this. So, this make me personally doubt a little bit if Marak is really behind all of this, or if maybe his account got compromised, or if something else it at play. — [0] https://jworks.io/the-faker-js-saga-continues/ https://jworks.io/the-faker-js-saga-continues/ If you wanted to take over other people’s NPM packages by pushing a compromised update to one of your own widely used packages, the first thing it would do is check to see if the victim had access to publish to NPM. Marek, who has just started publishing malicious updates to his own widely used packages, has just created a package to check for access to NPM.

zaroth 5y ago
This seems like irresponsible speculation and insinuating that Marek is about to commit a felony? I’d rather skip the character assassination based on hypothetical future actions please, and focus on what’s actually happened.
- JimDabell 5y ago
  > Packages are literally remote code exec vulns in the hands of package authors There are 20m+ weekly downloads of the colors package alone. He has what amounts to remote execution privileges to people using that package. When the subject of compromised packages comes up and he’s demonstrated that he’s willing to publish malicious updates, it’s completely fair to wonder what else he’s willing to do with that level of access to that many systems. It’s irresponsible not to consider what his packages can do to your systems.
- CRConrad 5y ago
  > This seems like irresponsible speculation and insinuating that Marek is about to commit a felony? No, it's speculation that Marek didn't do any of this, but that instead his account was hacked. You either responded to the wrong comment by mistake, or totally misunderstood the one you replied to.

cookiengineer 5y ago

I wish there was a package manager for node.js that is made for "static" or offline usage, and is able to compare headers of libraries before upgrading them. But here we are, 10 years in, with nobody giving a damn about semantic versioning. Life could be so much easier with an actual package manager that isn't just some git clone replacement.

deleted 5y ago

[deleted]

deleted 5y ago
[deleted]

lrvick 5y ago

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mirrors JS many companies import ;)

0x0nyandesu 5y ago
You can say the same thing about the entire Linux stack
- mPReDiToR 5y ago
  Unless you're using LFS, of course. The problem you describe isn't Linux, it's Linux Distributions. Where would you draw the line? Source packages are available, and if the binaries don't match the code a distro would soon be outed a la "many eyes" thinking. We have to trust some or none. Get the top off that chip, see if the factory put an extra core in for the NSA (IME).
- asddubs 5y ago
  any operating system, really, if you want to play that game
- mid-kid 5y ago
  Not really, individual package developers don't have as much inmediate control over the repository's state as they do with NPM. Packages go through a review by one of the trusted developers and sometimes automated QA and testing (including as of late reproducibility testing, i.e. does the source match the binary?), before being uploaded to the repository. If you can't trust the team behind the distro, then sure, your supply chain is compromised, but it's significantly less likely for a single package developer to cause any damage, as all the big distros have rather extensive policy and procedures to prevent such things.
  - 5y ago

raxxorrax 5y ago

You don't have to always pull the latest release on utility packages if you want to evade such problems. Sure, you would need to audit a lot of packages in certain languages... But yes, I prefer to "vendor" my dependencies too, especially on large projects.

lrvick 5y ago
Security vulns are fixed daily in most webapp dependency trees. If you do not update you are vulnerable to piles of issues anyone can look up. If you update blindly you may import new obvious supply chain attacks. The solution is actually doing code review. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. The extra effort to use a minimal framework and some cherry picked functions may be worth it for most orgs.

heurisko 5y ago

> I have a mailing list for people who use my code, when an update is out they can download the .php files, 'require' them and test them before deployment, but never will I do packages. This offers no benefit in terms of security, over a package dependency locked at a specific version. The end result is the same: the user ends up downloading the .php files, and testing them in deployment, but through composer instead of curl. It doesn't contribute to security at all, it just makes it awkward for other people to use your code. I would also assume that people are connecting your library to a package management system anyway, to overcome this unnecessary hurdle e.g. https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository https://getcomposer.org/doc/05-repositories.md#loading-a-pac...

Bolkan 5y ago
By using automatic upgrades you trade theoretical security fixes for undefined behaviour and bugs. One is clearly much worse than the other.
- heurisko 5y ago
  Composer (PHP dependency manager) does not force you into doing automatic upgrades. You can keep a dependency fixed at a particular version indefinitely. You can also point composer at a private vendored repository of the dependency if you don't trust the upstream server.
notRobot 5y ago
I do this solely because I don't like packages, I don't use them, and I don't want to maintain them for other people. To the people who want to use my code, it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. The code I write is primarily for me. Other people can use it if they want to, and I hope it helps them, but I don't care much about how many chose to use it or not. If they do, they have to work with my preferred way of distributing code. There have been times where third parties have included my code in their packages, but I'm explicitly not the package author in those cases, so it (the package) is not my responsibility.

maze-le 5y ago

> At the very least, it takes them under a minute to break your app, simply by deleting their package. Not really, if you pin your versions exactly and don't do auto-updates. This also means that you have to update your packages manually and inspect what the latest versions are doing -- which is good practive anyway. NPM packages can not be depublished any longer as far as I know.

indigochill 5y ago

IMO this is what forking is for. You don't have to rewrite it, you simply copy it somewhere that it isn't going to change unless you make the change happen, because some third party screwing around with your production code is just Bad News even if they have the best of intentions. You should still look over it and make sure it's not obviously malicious, but simply using forks or local repos of open source packages would probably save 98% of these kinds of headaches (with a 2% allowance for insecure/malicious open source code).

asah 5y ago

Omg y re making list for packages. It's not a technical cure, but it connects developers and library consumers and creates far more accountability. GitHub issues can work in theory but in practice, developers are often slow to respond i.e. GI is where problems go to die.

harperlee 5y ago

How complicated it is to just clone the repo and point your apps to your forked version? That way this would not have happened.

goodpoint 5y ago

> Packages are literally remote code exec vulns in the hands of package authors Reminder: this is why traditional Linux distributions exist.

jamaicahest 5y ago

I have worked with several banks as a devops consultant and have helped implement self-hosted proxy repositories for NPM, NuGet, etc. These proxies save a copy of every package downloaded and store it locally for as long as the bank wants. Developers are then blocked from downloading from any other repository than these proxies. This solves the problem of packages being taken offline, but it does very little against malicious code on new versions of the package. However it also provides the ability to reproduce code X years into the past, as can be required of banks by financial regulators in various countries. As always it is a cost/benefit trade-off: what is the benefit to auditing every package vs. the cost of auditing every package?

daudmalik06 5y ago

Totally agree with you, i think it's time to think carefully and immediately start using services like Vulert(https://bit.ly/336DZub https://bit.ly/336DZub) that tracks your open-source softwares for free and notifies you in real-time if any seccurity issue is found within your applciation. it's free. atleast in this way we can secure ourselves from supply chain attacks