[HN Gopher] Social engineering takeovers of open source projects
___________________________________________________________________
Social engineering takeovers of open source projects
Author : mooreds
Score : 124 points
Date : 2024-05-05 19:53 UTC (3 hours ago)
(HTM) web link (openssf.org)
(TXT) w3m dump (openssf.org)
| ChrisMarshallNY wrote:
| This is a great write-up.
|
| It's a very serious issue. I don't really know if there is any
| "one solution." I suspect that each project needs to set its own
| bar, and that any dependency that falls out of maintenance should
| be removed as quickly as possible (which was good practice,
| beforehand, but even more important, now).
|
| _[EDITED TO ADD]_
|
| I would also think about "scoring" the sensitivity of projects.
| Things like cryptography and low-level drivers would be highest-
| rated, while user-space chrome might not be as important.
| dvh wrote:
| We've been adding features for 30+ years to open source software,
| they become so complex only very few people understand them
| anymore. Recently I looked into jfet level 2 implementation in
| ngspice, expecting familiar equations, but through series of
| small changes and maybe some DRY too, the code is almost
| unrecognizable. When graybeards finally retire, there will be
| lots of shrugs.
| zer00eyz wrote:
| Your average American could quit working for 5 million dollars.
| They could live comfortably for the rest of their lives off
| that money, if well invested (read EFT for sp500)
|
| 5 million bucks is change for you average government.
|
| "Amazon made billions on my project and if I turn a blind eye
| to this I can retire, fuck them..."
|
| Sponsorship, for good or bad makes a lot of decisions simple.
| imachine1980_ wrote:
| what the heck( im not american but this sound dumb so i check
| numbers), last year usa federal government spend 18420.42 per
| capita being 50% deficit i doubt that you decide spend the
| budget of 271 persons in this, 4.4 million developers in usa
| saying that 1 % of those are open source meaning that you are
| paying 200.000.000.000 two hundred billions thats a quarter
| of military budget only in maintaing current problems i don't
| say you cant speed "few hundred dollars" a month per
| developers, of critical open source infrastructure, and force
| them to have strong contingency plans.
| SgtBastard wrote:
| Friend, I read the comment that you're replying to that if
| hostile governments wanted to backdoor our software supply-
| chains, it wouldn't cost that much to corrupt an open
| source maintainer.
|
| Whereas, if it was the norm for well used OS projects to be
| sponsored, it's far less likely to be tempted by relatively
| small bribes.
| chiph wrote:
| Anyone who has played Eve Online is familiar with this process.
| Gain membership, become a valued contributor to the corp, then
| betray it for profit.
| glenstein wrote:
| And one difficulty here I believe is that those intent on
| social engineering think about it in more sophisticated terms
| than their targets, which perhaps is obvious.
|
| And part of the process can be a kind of performative
| incredulity at the very suggestion that they are part of a
| campaign of hostile takeover, even if it's exactly accurate. I
| suppose you could even have unfortunate circumstances where
| parts of an open source community are unwitting advocates of
| being co-opted.
|
| And I think you probably see a parallel in state-based
| information warfare, where part of the objective isn't just to
| spread misinformation, but to shift cultural norms so that the
| transmission of misinformation is inherently easier, which can
| involve sewing distrust in institutions or expertise, or
| normalizing a gish gallop argumentative style.
|
| I'm perhaps stating the obvious here, but I suppose the upshot
| is that human psychology can be targeted in a programmatic way,
| and there might need to be something in the way of a normalized
| infosec-oriented doctrine relating to the stewardship of open
| source programs as an intentional countermeasure.
| zer00eyz wrote:
| >> And I think you probably see a parallel in state-based
| information warfare, where part of the objective isn't just
| to spread misinformation, but to shift cultural norms so that
| the transmission of misinformation is inherently easier,
| which can involve sewing distrust in institutions or
| expertise, or normalizing a gish gallop argumentative style.
|
| TikTok springs to mind when reading this...
| dgfitz wrote:
| Not going to quote the whole thing, but yes hard agree.
| Contrasting this factual opinion with the opinions in the
| "sell TikTok" hn threads is quite a delta.
| michelsedgh wrote:
| 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 compared to closed sourced
| software? Usually the argument for open source is because
| everyone can read the code, its less vulnerable but now because
| everyone can write the code and have big incentives to do
| malicious stuff, doesn't it make open source worse?
| janosdebugs wrote:
| The problem is, we don't know. I've seen PRs that could be
| curious students, or it could be a first try to see if we are
| paying attention. It's really easy these days to produce a
| halfway decent looking PR for someone in their first year of
| uni and my worry is that an increased volume of low to medium
| quality contributions will lead to maintainer fatigue.
| Depending on the project, that may be the point where pressure
| can be applied to share maintainership.
| pcloadletter_ wrote:
| Good warning for the future... but what about the past? Any
| thoughts on retroactively looking at behavior for existing OS
| projects? Seems like an impossible amount of work.
| andix wrote:
| 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 impact/risk projects probably.
| int0x29 wrote:
| Backdoor attempts won't be that obvious. The xz incident just
| had a random unaffiliated burner account and nothing of any
| clear national origin.
| andix wrote:
| 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.
| andix wrote:
| Maybe we need a reporting system for maintainer changes of bigger
| projects. Some list where they get published and people can keep
| an eye on it.
|
| Those changes of maintainers need to be synced to package
| distribution sites like npm.js or Debian packages and put in
| context with versions/releases.
|
| In Europe this was introduced for banks after the banking crisis.
| If a bank does any organizational change, a report is sent out to
| all member states of the EU right away and any of the 27 national
| bank agencies can check if they notice something unusual. It
| might be possible to bribe a few people in your own country, but
| it's really hard to bribe all responsible people in 26 other
| countries.
| PartiallyTyped wrote:
| > Maybe we need a reporting system for maintainer changes of
| bigger projects. Some list where they get published and people
| can keep an eye on it.
|
| The rust project does it. There's a repo with all [active]
| members and their permissions on github, etc. These get
| synchronized and updated every time there's a change.
| GauntletWizard wrote:
| This is, in my eyes, one of the most important parts of
| "Infrastructure as Code". You should make the list of who has
| what permissions a critical artifact, as immutably part of
| the repo as any other change.
| andix wrote:
| Just for the main project, or for all/most packages on
| crates.io?
| PartiallyTyped wrote:
| Every repository and team under rust-lang on github.
| andix wrote:
| 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.
| piecerough wrote:
| This 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.
| andy99 wrote:
| 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.
| TechDebtDevin wrote:
| The real threat of LLMs is their potential to ruin your day
| if you use them to assist in your work.
| kemotep wrote:
| Are you asking for evidence that LLM's can be used to write
| emails and chat messages?
| smsm42 wrote:
| Maybe one day it will happen, but right now LLM-generated
| persona would likely set off every alarm bell for a lot of
| people. LLMs have very recognizable style, and it usually falls
| right into the uncanny valley.
| andix wrote:
| 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.
| sim7c00 wrote:
| i dont think maintainer changes is even the endgame for this
| stuff. its hard to get a new person in, but a nation state can
| likely more trivially attack a current maintainer.. everyone has
| a button somewhere. the only solution to this is tooling which
| can flawlessly reason about code changes being malicious or not,
| being applied to every change in a project. and then still its a
| lost cause. a lot of issues and vilnerabilities come from how
| softwarw interoperates witj other software. will you be able to
| reason about all possible package combinations and how they are
| secure or not when they come together in certain ways?
|
| it should be easier to write systems from scratch, rather than to
| have to use third party code for everything. computers currently
| are not condusive to this. they need to be built different, to
| allow software to be built different.
|
| maybe while we are at it we can also make it so computers reduce
| complexity in peoples lives instead of adding to it.
| bsuvc wrote:
| 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?"
| andy99 wrote:
| It's not the new contributors you have to watch, it's the
| sleeper contributor who has built up a solid reputation and
| then is "activated". At least that's how I understand XZ.
| Uehreka wrote:
| It's both. The fact that one happened recently does not
| preclude the other.
| andix wrote:
| 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 people is
| the core competency of intelligence, happens all the time, and
| most cases probably never come to public knowledge.
| runjake wrote:
| 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.
| smsm42 wrote:
| It's a pity they don't give any details about the "attempted
| takeover" - are they available elsewhere?
| devaiops9001 wrote:
| The recent NixOS """community""" fiasco was a super obvious
| attempt to derail the NixOS project to make way for America's
| adversaries to ruin NixOS, and make NixOS useless for defense
| purposes.
|
| At this point the only option is for the NixOS project founder to
| fork a new project under a new name/brand and for all of the
| quality talent, the ones without mental health problems
| specifically, to follow the NixOS founder to the new project
| under the new brand, leaving all the batshit mentally ill people
| to ruin the existing NixOS brand, as unfortunate as that is.
| nicce wrote:
| Any good links about fiasco?
| haunter wrote:
| https://news.ycombinator.com/item?id=40166912
|
| https://news.ycombinator.com/item?id=40196068
|
| https://news.ycombinator.com/item?id=40199153
| puffybuf wrote:
| It doesn't even have to be a server like ssh. It could be a
| client side project engineered to somehow deliver all your ssh
| keys or bitcoin wallets. There is no reason backdoors couldn't
| stealthily phone home from client side applications.
| andix wrote:
| The crazy thing about the xz issue was, that xz is not even a
| dependency of openssh, but of systemd. And the xz backdoor
| exploited the systemd integration of openssh. This exploit was
| invisible to people that tested plain openssh without one of
| the most common integrations into Linux.
| fancyfredbot wrote:
| Doesn't have to be a takeover. If I'm a state actor I'll maintain
| a few projects specifically so I can hide backdoors in them.
| When/if one gets popular and I decide to backdoor them I'll claim
| it was a social engineering takeover.
| Arch-TK wrote:
| 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.
| kazinator wrote:
| [delayed]
___________________________________________________________________
(page generated 2024-05-05 23:00 UTC)