Live data from Hacker News

Social engineering takeovers of open source projects

openssf.org

121–130 of 379 posts

Re: Social engineering takeovers of open source projects

#121
First I think that it is wrong to single out this issue on Open Source projects.

For example, since the first versions of app stores, when you are an app developer you would receive a lot of messages from random shady dudes ready to buy your application if it had a few users.

Also, the xz thing was kind of pretty smart, but it is also a thing in mind of most OSs developers that you can't trust any random contributor and so that you will be very careful of really knowing someone before giving some privilege.

Just look how the debian policies were designed or that things like "pull requests" were invented for Open Source projects where everyone in a project used to be allowed to push whatever in private ones before.

Re: Social engineering takeovers of open source projects

#122
post #117
post #107

Earlier quoted context omitted.

You can always use the "we have no idea" argument because you can't prove something doesn't exist. Go find evidence. It's been over a month since xz and thus far we have zero additional incidents. And if you look at the specifics of xz attack: that wouldn't work for most projects because most don't have binary test files.

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.

Most commonly-used projects are watched by a bunch of people, or diffed on updates. These are not in-depth reviews, but should catch most of it. So yes, people are looking, and have been looking for a long time.

The reason Jia Tan could do their thing is because 1) the main meat was in a binary test file, 2) the code to use that seemed relatively harmless at a glance, and 3) people were encouraged to use the .tar.gz files instead of git clone. Also you need to actual get maintainer status, which is not as easy as it sounds.

I've been thinking of inserting a "// THIS LINE IS MALICIOUS, PLEASE REPORT IF YOU SEE IT" in some of my projects to see how long it would take. I bet it would be pretty fast either after commit or after tagging a release.

Re: Social engineering takeovers of open source projects

#123

Earlier quoted context omitted.

How about simply paying the maintainers and then getting stuff done like the classical business does.

Well yes, sounds great, but it doesn't really address the security problem. Now you've just got the bad guys getting two paychecks instead of one and the good guys getting one paycheck instead of zero.

> bad guys getting two paychecks instead of one

1 to 2 paychecks = 100% increase.

> good guys getting one paycheck instead of zero

0 to 1 paycheck = infinity increase.

With a known baseline of "good paychecks", financial analytics can pursue identification of "bad paychecks".

Re: Social engineering takeovers of open source projects

#124

Earlier quoted context omitted.

The most secure systems are those that are also resistant to rubber hose cryptography.

"Rubber Hose Cryptography" comes in the form of a PR. "Rubber Hose Cryptanalysis" comes in the back door and waits for you in the dark.

No, it 'comes in the form of' a rubber hose...

Re: Social engineering takeovers of open source projects

#125
post #122
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.

Most commonly-used projects are watched by a bunch of people, or diffed on updates. These are not in-depth reviews, but should catch most of it. So yes, people are looking, and have been looking for a long time. The reason Jia Tan could do their thing is because 1) the main meat was in a binary test file, 2) the code to use that seemed relatively harmless at a glance, and 3) people were encouraged to use the .tar.gz…

Maybe

  // this line is an external audit test - a free gift card to the first person to report finding it.

Re: Social engineering takeovers of open source projects

#126
post #21

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

> 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.

Yes.

We also need to encourage user scripting of first party library APIs on devices.

iOS Shortcuts are a step in the right direction, but they need better tooling to maintain and distribute source-controlled shortcuts.

Re: Social engineering takeovers of open source projects

#127
post #117
post #107

Earlier quoted context omitted.

You can always use the "we have no idea" argument because you can't prove something doesn't exist. Go find evidence. It's been over a month since xz and thus far we have zero additional incidents. And if you look at the specifics of xz attack: that wouldn't work for most projects because most don't have binary test files.

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.

Re: Social engineering takeovers of open source projects

#128
post #107

Earlier quoted context omitted.

If someone gets stabbed in the eye, we find out about it. So our statistics on eye-stabbing are probably accurate. We literally have no idea how many xz-style compromises are out there in the wild. We got really lucky with xz - it was only found because the backdoor was sloppy with performance and a microsoft employee got curious. But we have no data on all the times we got unlucky. How many packages in the linux eco…

You can always use the "we have no idea" argument because you can't prove something doesn't exist. Go find evidence. It's been over a month since xz and thus far we have zero additional incidents. And if you look at the specifics of xz attack: that wouldn't work for most projects because most don't have binary test files.

I'm nobody so you have no reason to believe me - but there have indeed been other, very prominent projects targeted in very similar attacks. We're still inside the responsible disclosure window.. hell, even in the blog post we're commenting on, three JS projects were targeted in failed attempts. That's 4 public projects now..

Re: Social engineering takeovers of open source projects

#129
post #122
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.

Most commonly-used projects are watched by a bunch of people, or diffed on updates. These are not in-depth reviews, but should catch most of it. So yes, people are looking, and have been looking for a long time. The reason Jia Tan could do their thing is because 1) the main meat was in a binary test file, 2) the code to use that seemed relatively harmless at a glance, and 3) people were encouraged to use the .tar.gz…

> I've been thinking of inserting a "// THIS LINE IS MALICIOUS, PLEASE REPORT IF YOU SEE IT" in some of my projects to see how long it would take.

Tools that use LLMs to review code will catch such projects.

Re: Social engineering takeovers of open source projects

#130
post #107

Earlier quoted context omitted.

You can always use the "we have no idea" argument because you can't prove something doesn't exist. Go find evidence. It's been over a month since xz and thus far we have zero additional incidents. And if you look at the specifics of xz attack: that wouldn't work for most projects because most don't have binary test files.

I'm nobody so you have no reason to believe me - but there have indeed been other, very prominent projects targeted in very similar attacks. We're still inside the responsible disclosure window.. hell, even in the blog post we're commenting on, three JS projects were targeted in failed attempts. That's 4 public projects now..

History may record XZ alongside Spectre/Meltdown as industry turning points for "too wide to see".
Post reply on HN