4 ms·

It seems language package manager compromise is becoming an increasingly prevalent attack vector. IMHO, at some point, the software development industry is goi

• krapp 8y ago
  >It seems language package manager compromise is becoming an increasingly prevalent attack vector. This problem seems to be increasingly prevalent for only one package manager and the ecosystem around one language, though.
• _bxg1 8y ago
  Unfortunately in this case, since the source repository itself wasn't compromised, there was nothing to audit (assuming the final bundle was packed/minified). One interesting mitigation would be for NPM to allow you to bind your package directly to a particular repo. So rather than a user (or job system) having to manually go in and publish releases, NPM could assure that what's live always matches what's in the repo. I've always wondered, how does apt-get solve this? Do they audit every package?
  • rattray 8y ago
    Yeah, `npm publish` should just – on npm's servers – fetch a github repo and run a build command. This would be more secure, convenient, and less prone to silly errors (like forgetting to build before releasing).
  • namibj 8y ago
    They build them themselves, and vet holders of signing keys. They have _much_ better opsec than the NPM ecosystem.
• maksymddd 8y ago
  Yes, and then we will have to audit each update and each bugfix, right?
  • codingdave 8y ago
    Someone will need to, yes. Hopefully it would be a more centralized, trusted auditor. But flip it around -- without such audits (the status quo), you don't know what code runs in your own codebase. Is that acceptable?
• fulafel 8y ago
  We don't really know how to audit for backdoors/vulns that don't want to be found. See eg the underhanded c contest.
  • _bxg1 8y ago
    Due to sandboxing, the concerns for malicious JS are different from those of C. From what I've seen, bad JS usually tries to record/read and then exfiltrate data, which can only be done through a narrow set of native APIs, which would be comparatively easy to check for.
    • fulafel 8y ago
      This was a node app, running without sandbox. For sandboxed browser apps, I think the exfiltration problem is not much easier - there are a zillion ways a piece of data can get incorporated into an outgoing xhr or image url. And everything can be monkey-patched. And the code will get transpiled, minified and webpacked etc a zillion times over, all steps which are attractive spots to mess with your code.
      • _bxg1 8y ago
        Maybe sandbox is the wrong technical term, but JS as a language runs with constraints. It can't manipulate pointers, mainly. As far as I know there's no such thing as a buffer-overflow attack in the context of Node.js.
        • fulafel 8y ago
          If the malicious JS code is already running in node, there is no need to exploit a RCE bug. edit: to expand, an underhanded js bug might be a path traversal bug, xss bug, leak of session cookies - any of the familiar js security bugs that occur as honest mistakes too. (But while on the subject, Node API's are historically quite unsafe and do have lots of memory safety vulns, search results are in 3 digits in the issue tracker for queries like segfault. Node API's are not really written with hostile code in mind.)
      • 8y ago
• naasking 8y ago
  > IMHO, at some point, the software development industry is going to have to come together and find a way to collectively audit the most widely used packages That will never work. Widespread auditing practices will never solve such problems. What the software development industry should do is move towards capability-secure languages where such attacks are virtually impossible.