Congrats av, you win today’s Burned by the medium hackernoon repost award.
Another way malware is getting in to things is by naming themselves as misspellings of popular repos https://www.theregister.co.uk/2017/09/15/pretend_python_packages_prey_on_poor_typing/
Once again, I’m barley totally suprised that a medium invented to distribute and connect so-called “hypertext” documents, which has over time revived multiple additionsand extensions from “browser developers” and some other committees thinking they have more power than they actually do, by adding a turing complete language, multiple ways to change the same style of a document and many more things to this simple and innocent transfer protocol, could be abused. It’s not like people will create complexity that one can’t comprehend anymore - create build systems, packages managers, special editors and frameworks just this little project initiated by some guy in Switzerland.
I don’t find this a very useful reply.
This post is only marginally about browsers and HTML/CSS/JS. Almost no application system in place nowadays has any isolation of application data from the application itself. At least a browser logs, sandboxes and traces all of those interactions. Replacing npm through CocoaPods in this scenario would not change much.
The browser seems remarkably weak for auditing. What script did I run ten minutes ago? I have no idea. It’s practically impossible to examine what a site is going to do in advance. You click and hope nothing bad happens. You have no idea if clicking a second link will do something else entirely.
Could you answer the same question about any other app you ran 10 minutes ago?
I’m not saying the browser is perfect, but with the parent post, I’d like a realistic assessment of a system at the deployment and usage scale as web browsers that fares better. Sure, we could all go back to BBS, but who’d want that?
The ultra fine granularity and relative low quality of the NPM packages make ideal circumstances for abuse, as the article eloquently shows. It’s a good case for the “batteries included” environments, which would be less prone to that type of attack. At the end of the day, the root cause is more social and organizational than technical – and that’s a fascinating aspect of computer security.
Counter-point: the fine granularity allows for not pulling much dead code in. With all the jokes about left-pad, it is easier to audit then activesupport.
I don’t think a good case for any of these environments can be made. I’d say the question of how to audit artifacts that literally include code from all over the world properly is unsolved.
I don’t have to audit activesupport, I have to trust the people with commit access. That’s a much smaller group than the set of package authors in my npm dependancies
This is not npm problem. More like third-party code can be malicious problem.
Yes, but 3rd-party code which can effectively be published by everyone without oversight by any more trusted parties and where it’s accepted to ship minified code and/or compiler output in packages; such ecosystems are especially vulnerable to the scenario described in the post. And then there’s this cultural norm to put every few lines in its own packages so that you end up with implicit trust to literally hundreds of people in many projects.
I mean Debian for example has got it’s own fair share of criticism and lacks in people to audit changes, but: You need to earn community trust before you can push anything in to the main repositories and minified code is not accepted.
Also, package signing is mandatory in Debian and unsupported in npm; it’s ordinary for npm users to import code from hundreds or thousands of authors, any of whom can be hacked.