> Now we have to run a background check when someone wants to help? The problem is in the tools. I don't agree with this comment, really. But -- there's almost always room for improvement w/tools. IIUC this unpacks encrypted JS bytecode and then executes it? Is there any way to statically know whether this could happen? "var newModule = new module.constructor;" ... newModule['_compile']() From what terribly little I…
Backdoor in event-stream library dependency
421–430 of 509 posts
Re: Backdoor in event-stream library dependency
#422Earlier quoted context omitted.
And then attackers would just wait that N days before pushing exploits.
No, I meant every pushed change has to wait N days before being published to users.
Re: Backdoor in event-stream library dependency
#423The practice of handing control of open-source packages to new maintainers is old and well-established. You can go to Sourceforge and request to take control of any old, low-impact, unmaintained repository and Sourceforge administration will likely grant it to you after a considerable delay and some investigation (at least they used to do so in the past, not sure if they will continue to after all this mess). The responsibility to ensure, that new versions of packages haven't been subverted by malicious actors, have always lied with people, who brought those packages into distribution — the package maintainers. Unfortunately, NPM does not have any "maintainers" in the traditional sense — package authors can't be trusted to remain impartial, and "administrators" just sit on their backs, waiting for devs to fill their repository with quality software. There is zero oversight — you can do anything with your packages as long as it does not outright contradict local law, including openly selling them to hackers, openly incorporating backdoors, and even sabotaging entire package ecosystem by unilaterally deleting hundreds of popular packages.
Covert transfer of control should not even be possible in centralized repository like NPM. If you want to give your package to someone, that act should be registered with repository administration, and future users of package should be warned of it — just like users of services and goods are commonly informed when an existing company changes it's organizational structure. It is one thing to privately give access to Github repo to someone. It is entirely different thing to hand over a repository package — which is automatically distributed onto large number of computers around the world. In later case authors, who failed to announce the change of ownership to repository maintainers, should bear full monetary responsibility for their actions.
Re: Backdoor in event-stream library dependency
#424Tl;dr: event-stream repo was injected with an attack that crawls your dependencies trying to find “copay-dash”. It then attacks it to steal all your bitcoin. The attacker was given maintenance rights to the repo by simply emailing the owner, who gave the rights freely. The owner and npm didn’t do a background check. Because of the MIT license, the owner has no liability/responsibility for his actions.
Re: Backdoor in event-stream library dependency
#425Earlier quoted context omitted.
Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…
Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…
Re: Backdoor in event-stream library dependency
#426Earlier quoted context omitted.
No, I meant every pushed change has to wait N days before being published to users.
Doesn't make sense if the "owner" abandoned the project and N goes to infinity. Then we have the same problem. If you're producing open source software, you have ALL the right in the world to abandon a project for arbitrarily large N days. If you don't want vulnerabilities, don't run code from untrusted sources, simple as that. This whole discussion is a farce. The reason open source comes with a license attached to…
Re: Backdoor in event-stream library dependency
#427I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…
This isn't the first time that has happened — the story with Google Chrome extensions being sold to hackers should have tought NPM, composer etc. a lesson. Maybe someone should finally sue them to drive the point home?
Re: Backdoor in event-stream library dependency
#428Earlier quoted context omitted.
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 ag…
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 c…
Re: Backdoor in event-stream library dependency
#429https://github.com/GovAuCSU/DRAT
Disclaimer: I am not a dev, just a pentester by trade so the code is probably ugly as fuck for many of you =))
Re: Backdoor in event-stream library dependency
#430Earlier quoted context omitted.
Doesn't make sense if the "owner" abandoned the project and N goes to infinity. Then we have the same problem. If you're producing open source software, you have ALL the right in the world to abandon a project for arbitrarily large N days. If you don't want vulnerabilities, don't run code from untrusted sources, simple as that. This whole discussion is a farce. The reason open source comes with a license attached to…
It makes a lot of sense if you realize many people who don't actively spend time maintaining something might still have a desire to spend 10 seconds glancing at others' changes to make sure their own rears don't get burned.