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

Social engineering takeovers of open source projects

openssf.org

Post reply on HN
Print view View original

151–160 of 379 posts

Re: Social engineering takeovers of open source projects

#151

Post by vundercind »

tschwimmer wrote: post #50
andix wrote: post #33

Earlier quoted context omitted.

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.

How incredibly wasteful.

You can form most useful numbers with just ten singe-digit constants, some casting, and string concatenation.

Re: Social engineering takeovers of open source projects

#152

Post by jongjong »

phendrenad2 wrote: post #137
jongjong wrote: post #90

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…

I suspect that the bad actors aren't merely benefitting from this situation, they're probably actively encouraging it, in GitHub issue discussions, on Reddit, in the comment sections of YouTube videos, here on HN. Maybe I'm paranoid.

I think this is a reasonable assumption for most high exposure projects. There are state actors from all sides who want to inject backdoors into software and they all benefit from complexity.

It could indicate that governments are more focused on offense than defense.

It seems to be a logical consequence of our short term corporate and political mindset. Offense is the best defense, they say... Ok, but not at scale when your opponents also possess the same weapons as you do; then you both end up worse off.

Re: Social engineering takeovers of open source projects

#153

Post by Thorrez »

mistrial9 wrote: post #61

it appears that this organization is repeatesly agitating for "threats" publicity in open source.. what is the motivation? https://news.ycombinator.com/from?site=openssf.org

They're an open source security foundation. Their entire purpose is to fight those threats. One way to help flight them is to bring awareness to them.

Re: Social engineering takeovers of open source projects

#155

Post by wrsh07 »

andix wrote: post #13

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…

I'm sure some security researcher is doing this, but we could easily create a visualization of "who has contributed over time" and identify transitioning of maintainers automatically just from git.

This might be worth doing and contributing to a site like bestofjs or libraries.io (I don't really use that one though!)

Re: Social engineering takeovers of open source projects

#156

Post by 01100011 »

michelsedgh wrote: post #9

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 sorts of attacks as those listed in the article("please review my change ASAP because it needs to go into the next release before the deadline!").

I don't know what to do about this. You could subject approved submitters to better background checks. You can improve automated threat detection and code analysis. You can switch to safer-by-default languages that make backdoors and malicious behavior more obvious.

I wonder if the same issue exists in other engineering fields? Has anyone ever bribed an engineer to make a bridge or a water supply less robust?

Re: Social engineering takeovers of open source projects

#157

Post by 01100011 »

pcloadletter_ wrote: post #10

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.

I think the only feasible option, due to the shortage of SWE talent, is a combination of automation, tooling and safer languages. We need better threat analysis systems, and we need to rely more on safe-by-default languages that make program behavior more obvious.

Re: Social engineering takeovers of open source projects

#158

Post by xpe »

arp242 wrote: post #108
andix wrote: post #83

Earlier quoted context omitted.

We know about the failed attempts, we have no idea about the successful ones, and the ones that are going to be successful in the future.

You can always use this line because you can never prove something doesn't exist. Go find evidence. It's been over a month.

Your choice of language in your comments (in this thread, not in general) isn’t bolstering your argument.

Why not be curious rather than just dismissive? This seems to be people just talking past each other at this point.

There have been a lot of changes in the last ~five years that point in the direction of supply chain security being at greater risk.

Evidence comes in many forms. The relevance of evidence depends on what part of the problem you are looking at.

Also, it is rational to talk about the probability by which different evidence is likely to be surfaced!

I think it is possible you are sensitive to people making such claims for self-interested purposes. Fair? But I don’t think it’s fair to assume that of commenters here.

Re: Social engineering takeovers of open source projects

#159

Post by xpe »

andix wrote: post #33
bsuvc wrote: 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…

Who can share a threat model with specific probability estimates on this? FWIW, I’m less interested in the particular estimates (priors) and more interested in the structure.
Post reply on HN