Live data from Hacker News

Social engineering takeovers of open source projects

openssf.org

211–220 of 379 posts

Re: Social engineering takeovers of open source projects

#211

Well after the XZ attack, I was thinking how common this can be. Good to know that at least im not the only one and others inside the community are wondering about this. I hope someone is smart or lucky enough to find a solution to at least be able to lessen the impact of these attacks. I still wonder how many more of these are there, and my question is because of these attacks, isn’t open source more prone to these…

Many open source projects just don't get enough attention for the 'many eyes' benefit of OSS to occur. Many projects are neglected and poorly maintained, with little participation from the users. I don't think OSS is particularly special though. If a state actor threw cash around they could find folks at many big companies to do their bidding. In my experience, commercial software reviews are susceptible to the same…

> Has anyone ever bribed an engineer to make a bridge or a water supply less robust

Of course, this happens all the time, check the consequences of any earthquake in any corrupt country for the more visible examples

Re: Social engineering takeovers of open source projects

#212
post #170

I recently had a xz moment where the rust zip crate was taken over by a single person and the original crate was completely replaced. I'm still not sure if this was legit or not: https://github.com/zip-rs/zip-old/issues/446

That does look suspicious.

Re: Social engineering takeovers of open source projects

#213

There's an awkward reckoning in open source software about inclusivity and protecting the long-term security of projects coming. Authors from several countries were already suspicious, such as Iran. Anyone from Russia and China or unknown places are all potential risks now. Combined with recent inclusive ideologies, it’s gonna cause hard conversations. There will be a furthering in segmenting the Internet. Why fight…

I don't see how blocking contributions from people in Russia etc will help. Malicious actors can simply falsely claim to be American. Is GitHub going to start verifying citizenship? Even if GitHub did that, it likely wouldn't be too hard to fake.

> Is GitHub going to start verifying citizenship?

As an American company they must presumably already do this to avoid violating sanctions, and least for anyone giving them money. It’s not a huge stretch to imagine they could also do so for free tier users.

Re: Social engineering takeovers of open source projects

#214

So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library, so they control it from inception? Great that we'll finally get state-sponsored open-source development :D

> So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library

This already happened.

*cough* React *cough*

Ask yourself, why would rogue AI and famous human impersonator Mark (short for Mark Zero Ai) Zuckerberg make an open-source UI library for everyone to use? /tinfoil

That said, who knows, maybe it already happened.

Re: Social engineering takeovers of open source projects

#215
post #170

I recently had a xz moment where the rust zip crate was taken over by a single person and the original crate was completely replaced. I'm still not sure if this was legit or not: https://github.com/zip-rs/zip-old/issues/446

Honestly, from reading this it seems like people blew it _way_ out of proportion. Someone forked the project to make updates because the original maintainer seemed to be not doing much, the original maintainer came back to say that they were correct to ask about maintenance because they didn't expect to do any more work due to health issues and then volunteered to transfer the crate to the person who forked on their own, which the person who forked it accepted.

It's kind of bizarre to me because I don't really understand what mental model could lead to not taking any action earlier than this if the was things turned out is so upsetting. If they were happy to keep using it exactly as is because no updates were needed, why not just pin the dependency to that version exactly (and republish their own fork if they were worried about old versions being "yanked" and not being able to use it for anything new or offline)? If they did expect some form of updates over time, where did they expect them to come from when the existing maintainer felt they were unable to continue given health issues? Any attempt to find some other solution to future ownership would be heavily scrutinized by the exact people who commented on this issue with strong opinions and don't seem to have much empathy for the health issues, which would defeat the entire purpose of trying to take time away from work for their health.

I'm surprised that this needs to be said, expecting people to put in extra work to project you from what happens to their projects when they literally can't keep maintaining them due to health issues will never work, and it's also just an awful way to treat people. If you have serious concerns about how situations like this could be exploited by malicious actors, you should be paying much closer attention to the status of your dependencies and taking actions to insulate yourself from potential fallout long before some like this happens. If you've gotten to this point under the assumption that you can just veto any change in ownership that you don't trust, you're already too late.

Re: Social engineering takeovers of open source projects

#216

So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library, so they control it from inception? Great that we'll finally get state-sponsored open-source development :D

If it's an everybody uses it solution it will eventually be reimplemented as a part of the environment, like the browser or the kernel. The lifetime is limited and linking to a library like that wouldn't mesh very well there.

Re: Social engineering takeovers of open source projects

#217
post #211

Earlier quoted context omitted.

Many open source projects just don't get enough attention for the 'many eyes' benefit of OSS to occur. Many projects are neglected and poorly maintained, with little participation from the users. I don't think OSS is particularly special though. If a state actor threw cash around they could find folks at many big companies to do their bidding. In my experience, commercial software reviews are susceptible to the same…

> Has anyone ever bribed an engineer to make a bridge or a water supply less robust Of course, this happens all the time, check the consequences of any earthquake in any corrupt country for the more visible examples

Yeah, for sure. I was mainly thinking about, say, a foreign state actor doing the bribing and not just the usual grift/embezzlement/corruption.

Re: Social engineering takeovers of open source projects

#218

I've been saying for years, over and over, that we need to focus on simple architecture and improve our coding standards but I keep getting ignored. People keep making software and tools more complex... "Just use TypeScript" they say, "Just use React, with Typescript" then they end up with literally thousands of unnecessary dependencies. The bad guys are laughing at our collective ignorance and naivety. Now probably…

Typescript has zero dependencies.

Re: Social engineering takeovers of open source projects

#219
post #33
post #22

I'm a maintainer (one of many) of an open source project, and this topic has been on my mind a lot lately as I review PRs. I am more suspicious of PRs from new contributors by default now. Of course I keep these suspicions to myself, but besides simply reviewing code for all the regular things, I now ask myself "what sort of sneaky thing could they be doing that appears benign on the surface?"

That's great that you are considering this more now. But the xy story taught us, that every contributor is dangerous, the most dangerous ones are probably the most helpful and most skilled contributors. If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor. Another thing that was not talked about a lot: There are many ways to compromise existing maintainers. Compromising…

> Another thing that was not talked about a lot: There are many ways to compromise existing maintainers.

Also not talked about a lot - there are many ways to compromise existing software engineers who are paid to work on proprietary software systems.

Re: Social engineering takeovers of open source projects

#220
post #170

I recently had a xz moment where the rust zip crate was taken over by a single person and the original crate was completely replaced. I'm still not sure if this was legit or not: https://github.com/zip-rs/zip-old/issues/446

This is not a ‘xz moment’, as a sibling comment said, it is norm in open-source.

Someone with more time forked the repo, included the changes that were necessary, build up trust and then this eventually get merged. Now obviously there is no guarantee they will never act up in the future, but this is not different than for the original owner.

Trust is a necessity to open-source reliably functionning, because it in parts makes up for the lack of money, and allow to move fast.

XZ is the exception. And frankly there is not much to do against it.

Post reply on HN