4 ms·

Anyone know how this was found and whether that process can be automated? There are likely a lot more packages that are infected with the same technique. I loo

by zawerf 8y ago

Anyone know how this was found and whether that process can be automated? There are likely a lot more packages that are infected with the same technique. I looked at the linked commits: https://github.com/dominictarr/event-stream/commits/master https://github.com/dominictarr/event-stream/commits/master and it looks so surprisingly normal. I am pretty sure I wouldn't have caught it even if I was code reviewing it. Did someone heroically rerun every package's build process to see if the minified output was tampered with?

gnulinux 8y ago
For what it's worth: it'd be undecidable to catch all vulnerabilities even if you very precisely define the semantics of your virtual machine, because it'd require knowing whether a certain line of code will be executed, which is known to be as hard as the halting problem. Practically, maybe? Maybe one can use ML to check codebase for suspicious code. But in an ecosystem like npm no matter what protection you have against hackers, someone will try very hard and inject vulnerabilities like this. You should defend yourself and use checksums for deps and execute only trusted code.
- zawerf 8y ago
  Not really asking for perfect/decidable. Just wondering out loud on how to detect even one of the other active exploits that are surely in the wild. This one was live for 3-4 months before it got found by luck? For example I would really appreciate if they added something to detect/warn when a package needs eval or http requests permissions (yes, I know npm packages don't have a concept of permissions). Anyway your commonly repeated advice on how to defend yourself isn't practical (short of not using npm). The dependency that got me was nodemon. That ought to be "trusted code" with 17k github stars, 1 million downloads per week but apparently not. As I said already, even if I did check the commits to all my dependencies, I don't think I would've caught this one. It's a one line change in the minified build file of a transitive dependency nested 4 deep. All the commits around it are very normal looking.
  - gnulinux 8y ago
    I wasn't intending to say reading every single commit of your dependencies is practical. I was arguing that unless you do that, you get absolutely no guarantee of security. If you take code for granted because it has 17k internet points, you're putting yourself at risk. I can't see how this is not very simple.
    - zawerf 8y ago
      It's "very simple" that you will also "get absolutely no guarantee of security" unless you personally rewrite every line of code you use in a provable/verifiable language, design and manufacture your own hardware, hide in a cave to avoid all social engineering, and so on. Hopefully you see why your advice is similarly impractical.

by zawerf 8y ago

gnulinux 8y ago

For what it's worth: it'd be undecidable to catch all vulnerabilities even if you very precisely define the semantics of your virtual machine, because it'd require knowing whether a certain line of code will be executed, which is known to be as hard as the halting problem. Practically, maybe? Maybe one can use ML to check codebase for suspicious code. But in an ecosystem like npm no matter what protection you have against hackers, someone will try very hard and inject vulnerabilities like this. You should defend yourself and use checksums for deps and execute only trusted code.

zawerf 8y ago
Not really asking for perfect/decidable. Just wondering out loud on how to detect even one of the other active exploits that are surely in the wild. This one was live for 3-4 months before it got found by luck? For example I would really appreciate if they added something to detect/warn when a package needs eval or http requests permissions (yes, I know npm packages don't have a concept of permissions). Anyway your commonly repeated advice on how to defend yourself isn't practical (short of not using npm). The dependency that got me was nodemon. That ought to be "trusted code" with 17k github stars, 1 million downloads per week but apparently not. As I said already, even if I did check the commits to all my dependencies, I don't think I would've caught this one. It's a one line change in the minified build file of a transitive dependency nested 4 deep. All the commits around it are very normal looking.
- gnulinux 8y ago
  I wasn't intending to say reading every single commit of your dependencies is practical. I was arguing that unless you do that, you get absolutely no guarantee of security. If you take code for granted because it has 17k internet points, you're putting yourself at risk. I can't see how this is not very simple.
  - zawerf 8y ago
    It's "very simple" that you will also "get absolutely no guarantee of security" unless you personally rewrite every line of code you use in a provable/verifiable language, design and manufacture your own hardware, hide in a cave to avoid all social engineering, and so on. Hopefully you see why your advice is similarly impractical.