I'm not so certain that the `safe_fprintf` to `fprintf` swap was ever itself meant to be malicious. There's some speculation about the addition of strerror but again.
Social engineering takeovers of open source projects
41–50 of 379 posts
Re: Social engineering takeovers of open source projects
#42Earlier quoted context omitted.
Maybe not so impossible. Start with making a list of projects that are everywhere. Inside every Linux distribution, inside every react/angular/vue/etc project, … Then check which companies support those projects with active development, and calculate a rating. Are the companies located inside democracies or are they mostly from china or Russia? It’s probably not that many packages in the end. A few thousand high impa…
Backdoor attempts won't be that obvious. The xz incident just had a random unaffiliated burner account and nothing of any clear national origin.
I wanted to make a different point. If for example Google or Red Hat were deeply involved within the xz project, there might have been more people reviewing the code. The evil changes to xz were easy to overlook, but not impossible to notice.
Especially the added "accidential" semicolon made me think about probabilities. I think in a code review I would notice that with a probability of 10-20%. So if 10 people would've looked at it, there might have been quite a low chance to get away with it.
Having some high profile companies involved into an open source project the risk score would drop in my opinion, which would highlight the projects that are completely community maintained, and might be more susceptible.
Having such a list might be a security threat by itself though, because attackers would focus on the "low risk" projects first.
Re: Social engineering takeovers of open source projects
#43Earlier quoted context omitted.
Just for the main project, or for all/most packages on crates.io?
Every repository and team under rust-lang on github.
That's great, but I think that's not enough. This would need to extend to crates.io, I'm sure there are some packages, that are very commonly used and not part of rust-lang.
Re: Social engineering takeovers of open source projects
#44> Enable two-factor authentication (2FA) or Multifactor Authentication (MFA).
Not on any third party system, where you're locked out forever if you lose your second factor. Fuck that!
Only self-hosted, where you can recover via physical access.
(That should actually be the first advice: host the stuff yourself. People lose control of projects due to hosting them on third party services. Be the guy who can pull the power cord out of the wall.)
Re: Social engineering takeovers of open source projects
#45This is only going to get worse with Large Language Models. Let's imagine a somewhat knowledgeable individual, could craft both emails, messages and even commits with a bunch of prompts. Those will relate deeply to the project.
I don't think this is going to be a big issue. Those attacks have to be high-profile attacks. If you look at the xz backdoor, there was some top notch engineering behind it.
If we ever reach a level of LLMs being able to do that, we don't need any open source contributors any more. We just tell tell the LLM to program an operating system and it will just do it.
Re: Social engineering takeovers of open source projects
#46I'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?"
Looking at some of these cases, each PR on their own doesn’t look suspicious, but it was what they all built up to — in some cases from multiple bad actor contributors that, on the surface, weren’t connected.
Re: Social engineering takeovers of open source projects
#47I'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…
One follow up to compromising existing maintainers: This makes the creators or long-term good faith maintainers maybe even more "dangerous" than new maintainers.
Re: Social engineering takeovers of open source projects
#48Earlier quoted context omitted.
Do you have any evidence or real examples to support that? I hear people say similar things but see nothing to suggest LLMs are a particular threat.
The real threat of LLMs is their potential to ruin your day if you use them to assist in your work.
Username checks out
Re: Social engineering takeovers of open source projects
#49[flagged]
This is actually pretty plausible if you consider how big a step forward Nix is in terms of reproducible and auditable open-source packaging. Of course anyone who wants to maintain the supply-chain attack avenue would try to gum up the works.
Re: Social engineering takeovers of open source projects
#50I'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…
>If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor.
Unforuntately it's easy to sandbag being dumb. Just because someone submits a PR defining constants for 0-999 does not mean they're actually bad at programming.