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

311–320 of 379 posts

Re: Social engineering takeovers of open source projects

#311

Post by another2another »

josephg wrote: post #100
arp242 wrote: post #71

Earlier quoted context omitted.

[flagged]

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…

It did at least reveal the playbook, and that you have to get pretty creative to hide things in plain sight.

I'm sure any binary blobs in OSS software, no matter what the reason for having them will be viewed with suspicion, and build scripts get extra inspection after that.

Maybe I'm naive in thinking that some people are already looking into packages that are included in all base Linux builds? Including simplifying the build env, and making sure that the the build tools themselves (cmake, pkgconfig, gmake, autotools etc) are also not compromised.

Re: Social engineering takeovers of open source projects

#312

Post by [deleted] »

__MatrixMan__ wrote: post #109
triblemaster wrote: post #54

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.

[deleted]

Re: Social engineering takeovers of open source projects

#313

Post by drtgh »

IMHO, Open Source is often misunderstood by companies as free code as in cheap, when in fact it should be seen as collaborative code that aims to avoid redundancy, saving companies countless hours of development, research, fixing compatibility issues and so on, due to such collaborative union between all the developers, mainly the maintainer(s), albeit at the cost of sometimes excessively generic non-performing code, and, here we go, albeit at the cost of potential security vulnerabilities that keep requiring an investment that has been largely ignored.

Perhaps companies should take the necessary reversal for the security of their business and create roles within the organization as guys who exclusively and actively revise the code being used, at the same time as internally classifying the integrity of genuine maintainers to ensure that bad guys don't get paychecks from either the company and the community, by showing facts.

It doesn't solve the problem, but I think it should be a generalized procedure, not just something that very few big companies seem to be doing, and one can see it's not enough.

Ironically, most companies ignoring the issue appear to be targets.

Although it did cross my mind that maybe such companies are not just misunderstanding open source as free code as in cheap, but maybe they also consider the security issues and repercussions as cheap; and if this is what is happening, maybe governments across the glove should impose large fines for data leaks and vulnerabilities in their systems, proportional to the company's revenues, proportional as in making them invest in security. in addition to what the article suggest.

I don't know. I'm just thinking loudly, certainly the problem is not easy to solve.

Re: Social engineering takeovers of open source projects

#314

Post by protomolecule »

wiseowise wrote: post #205
bee_rider wrote: post #177

Earlier quoted context omitted.

Web of trust, but all commits must be signed by at least 3 intelligence agencies from rival countries.

Russia, China, Iran and NK cock-block development for years, because the MR “doesn’t represent their interests”.

You mean like the US blocks all efforts to ban putting weapons in space?

Re: Social engineering takeovers of open source projects

#315

Post by kibwen »

guappa wrote: post #277
akx wrote: post #276

Earlier quoted context omitted.

The recovery codes I've seen tend to have been 10 8-digit sequences. If you don't have a printer and care about recovery codes, those are easy enough to transfer manually onto dead-tree material using a stylus-like handheld device that deposits graphite or ink onto the surface it touches.

Except that you need to decipher your own handwriting years after having written it. And you also need to remember where you safely stored it.

When I know it's important to decipher something later, I have a 100% accurate decoding rate on my own handwriting, so that's not a problem. It's not hard to write clearly and carefully. In addition, they give you ten codes to use, so you'd need to make indecipherable errors in all of them. Also, having a safe place to store documents is table stakes for adulthood.

Re: Social engineering takeovers of open source projects

#316

Post by api »

victorbjorklund wrote: post #56
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…

> Compromising people is the core competency of intelligence, happens all the time, and most cases probably never come to public knowledge. Yea. It would almost be strange if security service didnt consider the route of getting "kompromat" on a developer to make them "help" them.

I’m reading all this with sadness realizing that one of the Internet’s last remaining high trust spaces is being destroyed.

Re: Social engineering takeovers of open source projects

#317

Post by sneak »

glodalitazic wrote: post #200
voiper1 wrote: post #197

Earlier quoted context omitted.

So the long game is rival countries are secretly collaborating, so we secretly have world peace!

Imagine all war stops and noone knows it

Global violent deaths have been trending downward consistently since ww2, even given our new “permanent war” status. We simply just don’t have large-scale wars anymore.

Re: Social engineering takeovers of open source projects

#318

Post by whatevaa »

wiseowise wrote: post #218
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…

Typescript has zero dependencies.

Yup, that commenter did exactly what he told others not to do, bashed on something without checking if he's right. Typical bashism. Typescript is from a single big vendor with all the tooling.

React is a different story. By itself it's from a single big vendor, but all the tooling is tons of random packages and scripts...

Re: Social engineering takeovers of open source projects

#319

Post by Calavar »

another2another wrote: post #311
josephg wrote: post #100

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…

It did at least reveal the playbook, and that you have to get pretty creative to hide things in plain sight. I'm sure any binary blobs in OSS software, no matter what the reason for having them will be viewed with suspicion, and build scripts get extra inspection after that. Maybe I'm naive in thinking that some people are already looking into packages that are included in all base Linux builds? Including simplifying…

The de facto standard serialization library for Rust, serde, started using binary blobs to speed up builds only a few months before the xz back door was discovered. Lots of people asked the author to include build scripts so they could (re)generate the blobs on their own and his response was basically if you want it, fork it.
Post reply on HN