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

261–270 of 379 posts

Re: Social engineering takeovers of open source projects

#261

Post by guappa »

throwaway2037 wrote: post #192

> This approach bears strong resemblance to the manner in which “Jia Tan” positioned themselves in the XZ/liblzma backdoor. No, it doesn't. I stopped after read this. Jia's "attack" was near state level actor stuff. A bunch of emails asking/begging for commit access sounds like a 16 year old sending emails from the basement of his parent's house.

It's openssf… All of their posts are basically "install our github action, get our scorecard!". Which I personally think is completely useless.

If they want open source maintainers to do boring compliance stuff, they can pay them.

I won't be doing that for free for sure.

Re: Social engineering takeovers of open source projects

#262

Post by guappa »

__loam wrote: post #247
krishadi wrote: post #245

I hope there is a better way to maintain open source projects without being overly cautious and suspicious of every PR someone makes. Maintaining open source projects is hard, and this is going to slow down development on many projects. And, rightly so, it's better to make a good code base, rather than one that is littered with backdoors. I wonder what could make this situation better for the maintainers of open sour…

Public funding for security maintenance.

And serious taxation of tech companies.

Re: Social engineering takeovers of open source projects

#263

Post by raxxorraxor »

chipdart wrote: post #183
MenhirMike wrote: post #120

Earlier quoted context omitted.

> defining constants for 0-999 That person might just be an old school Java <5 developer.

That person might just be a regular Java developer who works on a project which onboarded Checkstyle, and can't disable it's MagicNumber check. https://checkstyle.sourceforge.io/checks/coding/magicnumber....

Man, I hate such tools. Do I run into problems when I try to convert seconds to minutes?

Larger problem than magic numbers ever could be.

Re: Social engineering takeovers of open source projects

#264

Post by guappa »

transpute wrote: post #110
ChrisMarshallNY wrote: post #3

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

Scoring framework: https://securityscorecards.dev/ Code: https://github.com/ossf/scorecard April 2024 ranking of OSS projects by criticality, 100MB CSV: https://commondatastorage.googleapis.com/ossf-criticality-sc...

The scorecard stuff is flawed.

You want to decide if something is secure or insecure but without reading the code. It's never going to have any correlation.

Re: Social engineering takeovers of open source projects

#266

Post by _fizz_buzz_ »

gkbrk wrote: post #236
throwaway2037 wrote: post #195

Earlier quoted context omitted.

Why did Eclipse org get so much and Apache org none/less? In my experience, the footprint of Apache exceeds anything else in enterprise programming.

Tons of modern and really critical development happens on Eclipse-based environments. Two examples I can think of off the top of my head are - DBeaver (very widely used to connect to production databases) - STM32Cube IDE (for embedded development in all sorts of devices)

TI's Code Composer Studio is also eclipse based.

Re: Social engineering takeovers of open source projects

#268

Post by guappa »

arccy wrote: post #259
guappa wrote: post #196

Earlier quoted context omitted.

> who has contributed over time When major security players insist that using GPG is bad, there is no way of knowing if bob@bob.bob is the same account that it was last month or not.

you can sell/steal keys just as easily as accounts

Ok. Can you get my private key? Feel free to respond to this comment with my private GPG key.

I think guessing a password and getting lucky is much easier.

Re: Social engineering takeovers of open source projects

#269

Post by somenameforme »

saagarjha wrote: post #254
somenameforme wrote: post #162

Earlier quoted context omitted.

I think you're going overboard on what's required. Take anybody who is simultaneously offered a substantial monetary incentive (let's say 4 years of total current/vesting comp), and also threatened with the release of something that we'll say is little more than moderately embarrassing. And this dev is being asked to do something that stands basically 0 risks of consequences/exposure for himself due to plausible deni…

This doesn't look intentional at all, because this is basically like how 90% of memory disclosure bugs look

Absolutely. And that's the point I'm making here. It is essentially impossible to discern between an exploit injected due to malice, and one injected due to incompetence. It reminds one of the CIA's 'simple sabotage field manual' in this regard. [1] Many of the suggestions look basically like a synopses of Dilbert sketches, written about 50 years before Dilbert, because they all happen, completely naturally, at essentially any organization. The manual itself even refers to its suggestions as "purposeful stupidity." You're basically exploiting Hanlon's Razor.

[1] - https://www.openculture.com/2015/12/simple-sabotage-field-ma...

Re: Social engineering takeovers of open source projects

#270

Post by josephg »

caf wrote: post #127
Mtinie wrote: post #117

Earlier quoted context omitted.

Are people really looking though? Are all open source libraries being run through extensive performance profiling to look for known heuristics? Are they being looked at line by line for aberrations? I don’t have confidence that people are looking for evidence of potential exploitation because of reasons like the ones you bring up. So we’re back to we just don’t know.

With hindsight it's not the runtime behaviour of the library that you'd want to test - the weakest point in the chain is where the distributed source .tar.gz can't be regenerated from the project repository.

For how many projects is that actually checked? I bet barely any.

Its especially difficult because most projects aren't built in a reproducible way. You should be able to uncompress and compare a source tarball. But if you get a binary and the source code used to generated that binary, there's no way to tell that they match.

Post reply on HN