Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in event-stream library dependency

github.com

Post reply on HN
Print view View original

201–210 of 509 posts

Re: Backdoor in event-stream library dependency

#201

Post by trickstra »

meowface wrote: post #160
jhardy54 wrote: post #48

Earlier 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…

Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.

exactly, transferring a package to an unknown person is not only giving them access to the code but also to all the people who already trust that code

Re: Backdoor in event-stream library dependency

#202

Post by sroussey »

geocar wrote: post #99
bcherny wrote: post #9

It looks like no one is even sure what the code actually does? Or am I misreading that thread.

It's attacking a particular package -- some package out there depends on ps-tree directly or indirectly, and its description is the secret key.

Which means there is a finite list to check, unless the package is something internal and not on npm.

Re: Backdoor in event-stream library dependency

#203

Post by trickstra »

ryandrake wrote: post #118
SpicyLemonZest wrote: post #31

Earlier quoted context omitted.

No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.

Why would someone update to a new version of a dependency if they don’t trust the new maintainer? Can’t you pin dependencies to a particular version with npm? In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

that assumes you know that the maintainer changed

Re: Backdoor in event-stream library dependency

#204

Post by gwbas1c »

To the outsider, these threads assume so much context that they don't make sense. (Of course, if you are a computer or you have intimate knowledge of these tools, and these threads make perfect sense!)

Who, what, where, why, and how need to be answered.

Usually when there's a link like this on hacker news, one of the highly moderated comments explains the situation in ways that don't require as much context as a typical commiter would have.

Re: Backdoor in event-stream library dependency

#205

Post by kurtisc »

Klathmon wrote: post #64
floatingatoll wrote: post #14

Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.

Code review can't catch determined malicious actors. It just isn't a viable protection against that kind of attack. Take a look at the underhanded c contest for plenty of proof where even very senior developers told up front that there is a backdoor in the code often can't find it! And they can't all be blamed on C being C, many of them would work the same in any language. I don't know the solution, but shaming users…

Most malicious actors aren't determined, they're lazy and will take the path of least resistance. Code review will catch out those.

Re: Backdoor in event-stream library dependency

#206

Post by ummonk »

21 wrote: post #182
programmarchy wrote: post #123

Earlier quoted context omitted.

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…

> Lieutenants gain authority based on the merit of their contributions Meritocracy is an outdated discriminatory practice. https://postmeritocracy.org/ https://www.theguardian.com/commentisfree/2017/mar/20/merito...

To be clear, you're arguing that people should be judged on their identity and background rather than the merit of their contributions?

Re: Backdoor in event-stream library dependency

#207

Post by AdmiralAsshat »

Seems like we need a linter that can look for binary, hex, or otherwise encrypted-looking data in source code (I have no idea how you'd teach the linter to look for anything that "looks like gibberish"--I'd leave that to people smarter than me). From past experience with other popular apps that get backdoored with bitcoin miners, anything intentionally obfuscated in what is supposed to be an open source application is almost always suspicious.

Re: Backdoor in event-stream library dependency

#208

Post by evan_ »

sroussey wrote: post #202
geocar wrote: post #99

Earlier quoted context omitted.

It's attacking a particular package -- some package out there depends on ps-tree directly or indirectly, and its description is the secret key.

Which means there is a finite list to check, unless the package is something internal and not on npm.

from the github issue it looks like a couple people are working on that using publicly available lists, and they've even found a few valid decryption keys, but none that turn the payload into executable javascript

Re: Backdoor in event-stream library dependency

#209

Post by JustSomeNobody »

ianwalter wrote: post #181

People have to understand that the Node.js ecosystem is different than in other programming languages/platforms. Modules are composed from smaller modules with a granularity so small that it is almost unique. When you're publicly publishing something low-level to npm you really should understand that the community may build on top of it to the point where it is used by many modules and as a result used by many end-us…

So much irony here. So, the community can be careless and just import whatever, but the maintainer can't pass maintainership on to someone else without it being dubbed careless? Shouldn't this whole situation be the fault of the community because they let in a bad actor? Society is great when everyone is benefiting, but something goes wrong and out comes the pitchforks.

Re: Backdoor in event-stream library dependency

#210

Post by kurtisc »

lmm wrote: post #59
floatingatoll wrote: post #14

Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.

Lack of code signing is what's harmful here. My maven projects' dependencies are technically all pinned, but updates are just a "mvn versions:use-latest-releases" away. But, crucially, I have a file that lists which GPG key IDs I trust to publish which artifacts. If the maintainer changes, the new maintainer will sign with their key instead, my builds will (configurably) fail, and I can review and decide whether I wa…

Would you have distrusted this maintainer though? If someone takes it over and publishes what appear to be real bug-fixes, I'd imagine most people would trust them. The same goes for trusting forks, or trusting the original developer not to hand over access.
Post reply on HN