Timeline of the xz open source attack • Hacker News Board

Re: Timeline of the xz open source attack

#161

Post by dylan604 » Tue, Apr 02, 2024, 3:09 PM UTC

phicoh wrote: post #94

nrawe wrote: post #78

"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…

I think a problem is that there doesn't seem any way to automatically check this. If we assume that anything that is used during build time can be malicious then figuring out those dependencies is already hard enough. Mapping that to organizational stability is one step further.

This is where the but FOSS is reviewable so it is trusted falls down. This situation is a prime example of how that fallacy is misconstrued. By being FOSS didn't make it trustworthy, it just meant that people had a fighting chance to find out why when something does happen. That's closing the barn door after the horses already left.

I'm not knocking FOSS at all. I just think some people have the concept twisted. Just like the meme of being written in Rust means the code is fast/safe from the mere fact it was written in Rust. I don't write Rust, but if I did, I guarantee that just from sheer not knowing WTF I'm doing would result in bad code. The language will not protect me from myself. FOSS will not protect the world from itself, but it does at least allow for decent investigations and after action reports.

Re: Timeline of the xz open source attack

#162

Post by mistrial9 » Tue, Apr 02, 2024, 3:10 PM UTC

kashyapc wrote: post #105

riskable wrote: post #97

Earlier quoted context omitted.

This event should be a wake-up call to businesses everywhere: It's not just a small number of "core" FOSS projects that need their support (funding and assistance!). Before this event who was thinking about a compression library when considering the security of their FOSS dependencies? The scope of "what FOSS needs to be supported and well-funded" just increased by an order of magnitude.

Yeah, as I note elsewhere in this thread, the OpenSSL "Heartbleed" saga should've taught some lessons, but alas, it's "classic" human nature to repeat our mistakes.

no - funding is going to places where profit is returned on investment, NOT to the tedious and long-term work that all of this sits on. It is not "human nature" because tedious, high-skill maintenance is done by humans, which built the infrastructure and continue to be crucial.

There is no accountability and in fact high-five and star shots for those taking piles of money and placing it on more piles of money, instead of doing what appears to be obvious to almost everyone on this thread -- paying long-term engineers.

Re: Timeline of the xz open source attack

#163

Post by pixl97 » Tue, Apr 02, 2024, 3:11 PM UTC

zoeysmithe wrote: post #107

phicoh wrote: post #98

Earlier quoted context omitted.

I think there is a fundamental difference between how corporations used to work and how open source typically works. In a traditional corporation, people would come to an office. It would be known where they live. If you would require something like (code) review, it becomes a lot harder to plant something. Obviously not impossible, but hard for all but the most dedicated attackers. In contrast, with open source and…

tbf, most security issues aren't from some insider, but outsiders discovering exploits. The insider scenario here is extremely rare both in commercial and FOSS software. Corporate insiders do stuff like this too, its just how often do we hear about it? FOSS has high visibility but closed source doesn't. Think of all the shady backdoors out there. Or what Snowden and others revealed. On average a 100% FOSS organizatio…

>Corporate insiders do stuff like this too, its just how often do we hear about it?

Pretty much never.

One particular terrible case I saw was when a developer left a testing flag in a build that got pushed to production and used for years. Had you set the right &whatever flag in the URL you'd have unauthenticated access to everything. It was discovered years after the fact when the software was no longer in supported status, so nothing was ever wrote up about it and told to the users. "They shouldn't have been using it by now anyway, no use in bad press and getting users worried".

Re: Timeline of the xz open source attack

#164

Post by gquere » Tue, Apr 02, 2024, 3:14 PM UTC

dist-epoch wrote: post #104

kevindamm wrote: post #42

Earlier quoted context omitted.

That's the basis for my preferring the term relating to authorization. The two terms have distinct and well-defined meanings in the domain. They're both critical aspects of security but for different reasons.

Remote code execution already implies unauthorized. There is no such thing as authorized remote code execution.

There totally is authenticated RCE, for instance a PHP page that contains a RCE but needs a prior authentication to access the resource.

All RCEs are classified in either unauthenticated or authenticated, the former being the worst (or best if you're a researcher/hacker).

Re: Timeline of the xz open source attack

#165

Post by michaelt » Tue, Apr 02, 2024, 3:14 PM UTC

lukaslalinsky wrote: post #63

goku12 wrote: post #49

Earlier quoted context omitted.

There is a good chance that everyone in that thread except the original maintainer is in on the act. It's likely that all those accounts are managed by a single person or group. Targeting just one account for rudeness isn't going to help, if that's true.

It does help on the social/psychological side. If you, as an open source project maintainer, have a policy that such rudeness is not acceptable, you are much less likely to become a successful victim of a social attack like this.

It's entirely possible for an evildoer to make someone feel bad while remaining completely polite.

First send a message to the mailing list as "Alice" providing a detailed bug report for a real bug, and a flawless patch to fix it.

Then you reply to the mailing list as "Bob" agreeing that it's a bug, thanking "Alice" for the patch and the time she spent producing such a detailed bug report, then explaining that unfortunately it won't be merged any time soon, then apologising and saying you know how frustrating it must be for Alice.

Your two characters have been model citizens: Alice has contributed a good quality bug report, and code. Bob has helped the project by confirming bug reports, and has never been rude or critical - merely straightforward, realistic and a bit overly polite.

Re: Timeline of the xz open source attack

#166

Post by pixl97 » Tue, Apr 02, 2024, 3:15 PM UTC

nathell wrote: post #83

lukaslalinsky wrote: post #24

The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into…

It makes Rich Hickey’s „Open Source Is Not About You” [0] particularly poignant. As a hobbyist developer/maintainer of open source projects, I strive to remember that this is my gift to the world, and it comes with no strings attached. If people have any expectations about the software, it’s for them to manage; if they depend on it somehow, it’s their responsibility to ensure timely resolution of issues. None of this…

>having been slowed down by mental issues

Anyone and everyone in the OSS world should be concerned about this too. You have nation state level actors out there with massive amounts of information on you. How much information have you leaked to data brokers? These groups will know how much debt you're in. The status of your relationships. Your health conditions and medications? It would not take much on their part to make your life worse and increase your stress levels. Just imagine things like fake calls from your bank saying that debt of yours has been put in collections.

Re: Timeline of the xz open source attack

#167

Post by kashyapc » Tue, Apr 02, 2024, 3:16 PM UTC

mistrial9 wrote: post #162

kashyapc wrote: post #105

Earlier quoted context omitted.

Yeah, as I note elsewhere in this thread, the OpenSSL "Heartbleed" saga should've taught some lessons, but alas, it's "classic" human nature to repeat our mistakes.

no - funding is going to places where profit is returned on investment, NOT to the tedious and long-term work that all of this sits on. It is not "human nature" because tedious, high-skill maintenance is done by humans, which built the infrastructure and continue to be crucial. There is no accountability and in fact high-five and star shots for those taking piles of money and placing it on more piles of money, instea…

No counter-argument; fully agree. FWIW, that's what I was referring to when I said, "fat companies" (and executives) glossing over the important tedious here[1].

[1] https://news.ycombinator.com/item?id=39905802

Re: Timeline of the xz open source attack

#168

Post by Inf0s3c » Tue, Apr 02, 2024, 3:17 PM UTC

nrawe wrote: post #78

"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…

Also in security and 100% tired of the code slingers who get annoyed by security reviews

Here on HN it’s been derided as “company just checking a box for compliance but adds no functionality. It slows us down when we want to disrupt!” - developer of yet another todo list or photo editor app…

Buffer overflows and the like are one thing. Notions from this blog that certain normal files won’t be well reviewed is a bad smell in software. Innocuous files should be just as rigorously reviewed as it’s all part of the state of the machine

“This is how it’s always worked” is terrible justification

Startup script kiddies git pulling the internet, and single maintainers open source projects aren’t cutting it; if it’s that important to the whole those in charge of the whole need to make sure it’s properly vetted.

I’m an EE first; this really just makes me want to see more software flashed into hardware.

Re: Timeline of the xz open source attack

#169

Post by jrochkind1 » Tue, Apr 02, 2024, 3:18 PM UTC

nrawe wrote: post #78

"It's also good to keep in mind that this is an unpaid hobby project." ~ Lasse Collin, 2022-06-08. As someone working in security, the fact that _foundational_ pieces of the computing/networking rely on motivated individuals and essentially goodwill is mind blowing. There are great aspects to the FOSS movement, but the risks – particularly the social engineering aspects as demonstrated here – and potential blast radi…

What it reminds me of, is my reoccuring thought, not just about open source but including this aspect, that we've built up a society based on software, that we could literally only afford because we've done it unsustainably. The economy could not bear the costs of producing all this software in an actual reliable sustainable way. So... now what.

Re: Timeline of the xz open source attack

#170

Post by cb321 » Tue, Apr 02, 2024, 3:18 PM UTC

intunderflow wrote: post #145

rsc wrote: post #40

Earlier quoted context omitted.

lcamtuf's two posts argue that this may simply not be an open-source maintainer's job to defend against. ("The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russian or Chinese intelligence services. Spies are stopped by spies.") That doesn't mean we shouldn't try to help burnt out committers, but the problem seems very hard. As lcamtuf also says, many th…

Why the assumption this is a Russian or Chinese intelligence service? Western governments aren't above this sort of conduct: https://www.mail-archive.com/cryptography@metzdowd.com/msg12...

Why are people assuming it's any intelligence service/state actor? With cryptocurrency valuations, it would seem like remote rooting gajillions of machines would be highly incentivized for a private person/collective. Not to mention other financial incentives. Our digital infrastructure secures enormous value much of which can be pilfered anonymously.

I admit, the op has a "professional/polished vibe" to me as well, but we seem to know very little except for what work time/zones were preferred by the possibly collective/possibly singular human(s) behind the Jia Tan identity. Does anyone have slick linguistic tools to assess if the writer is a single author? Maybe an opportunity to show off.. It's sort of how they caught Ted Kaczynski.

It also absolutely makes sense to think of all the state actors (I agree including as you say the US/UK) as part of the ongoing threat model. If the KGB/Ministry of State Security/NSA/MI6 were not doing this before then they surely might in the future. Maybe with more gusto/funding now! They all seem to have an "information dominance at all costs" mentality, at least as agency collectives, whatever individuals inside think.