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

Timeline of the xz open source attack

research.swtch.com

Post reply on HN
Print view View original

421–430 of 482 posts

Re: Timeline of the xz open source attack

#421

Post by thegrim000 »

userbinator wrote: post #86

I think one of the good things to come out of this may be an increased sense of conservatism around upgrading. Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits. Raising the bar for accepting changes can also reduce the churn that makes so much software unstable.

This drove me crazy at previous companies where our build system dependencies were specified with wildcards so they would just auto pull in the latest version whenever you built the project. Not only are there security issues with that, as seen here, but it destroys your ability to have deterministic builds; every time you build the project it might be building against a different set of dependencies. You lose the ability to even compare builds against each other, because even though the builds are for the same exact project code, the dependency binaries might be different, and so the two builds could run differently.

Re: Timeline of the xz open source attack

#422

Post by npteljes »

johnny22 wrote: post #418
npteljes wrote: post #291

Earlier quoted context omitted.

I'm sorry I don't understand your point clearly. Why is it a big problem, and whose problem it is?

The premise of the post I replied to is that the mailing list moderation is currently not great and that it allows people to be abusive. It suggest that we should crowdsource this moderation. I assume they think this will lower the burden. I myself do not think that this is the actual problem. I think the actual problem is that many FOSS communities have fostered an idea that cracking down on certain types of behavio…

I agree with this. In group settings I also look out for group-destructive behavior, and address it as best as I can. I'm the kind of person who thinks that certain rules, while restrictive on the surface, enable a sort of sustainable freedom down the line, similar to how the GPL license works.

Re: Timeline of the xz open source attack

#423

Post by dep_b »

My god, Hans Jansen? You need to be 60 years old to have that name in The Netherlands, it's so stereotypical that it would definitely ring some alarm bells if I saw it.

It's like seeing a "Bill Johnson, real American patriot" account on Twitter: would not believe it at face value.

Re: Timeline of the xz open source attack

#424

Post by 1letterunixname »

psanford wrote: post #193

One big take away for me is that we should stop tolerating inscrutable code in our systems. M4 has got to go! Inscrutable shell script have got to go! Its time to stop accepting that the way we've done this in the past is the way we will continue doing it ad infinitum.

Autotools-based build infra is always crufty, fragile, slow, and fugly. In a lot of cases, it sucks because it's what we have right now without doing the work to replace it with something equally flexible.

Build infrastructure should be minimal, standardized, and not subject to endless special, undocumented fragility.

cmake, just, conan, meson, and bazel (and forks) exist.

But I've still yet to see a proper build system that does feature detection in parallel and concurrently, or supports live, incremental, continuous, cached rebuilding.

Re: Timeline of the xz open source attack

#425

Post by klabb3 »

tadfisher wrote: post #347
comex wrote: post #286

Earlier quoted context omitted.

But the xz backdoor didn’t involve a build script that tried to compromise the machine the build was running on. It involved a build script that compromised the code being built. Sandboxing the build script wouldn’t have helped much if at all. Depending on the implementation, it might have prevented it from overwriting .o files that were already compiled, maybe. But there would still be all sorts of shenanigans it co…

Ultimately you're going to have to be adept at stuff like the Underhanded C Contest to spot this kind of thing in any Turing-complete language, so the idea of auditing the source is unreliable at worst. So I'd take another page from the Java/Maven ecosystem and require hashed+signed binaries, with the possible addition of requiring builds to be performed on a trusted remote host so that at least we can verify the bin…

> to spot this kind of thing in any Turing-complete language

I’m not sure I follow. The bar for passing review and audits is “people can understand it”, at least to the point of preventing smuggling in a custom public keys and other shenanigans – as opposed to “all valid programs in the language”. While I agree Turing-completeness opens up undeniable complexity, it’s the best we got. And there are huge variations in obscurity across languages and tooling.

Re: Timeline of the xz open source attack

#426

Post by runeks »

publius_0xf3 wrote: post #412
sfjailbird wrote: post #398

Earlier quoted context omitted.

It would be intetesting if Lasse Collin published his off-list interactions with 'Jia Tan' and any of the other pseudonyms, to get an even better angle on the social engineering parts. Apparently a large part of the campaign was via private channels to Lasse.

Collin has been writing more extensively on IRC. A screenshot of one of his posts can be seen in [this YouTube video]( https://youtu.be/0pT-dWpmwhA?t=1158 ). He notes that while he was unsatisfied with some of the changes Tan introduced, Tan was nonetheless extremely helpful.

> [...] unsatisfied with some of the changes Tan introduced [...]

That's one way to put it

Re: Timeline of the xz open source attack

#427

Post by dist-epoch »

kevindamm wrote: post #348
dist-epoch wrote: post #346

Earlier quoted context omitted.

Now you're redefining words. Remote code execution means a single thing, running JavaScript when accessing a web page and using SSH as intended is not RCE. https://en.wikipedia.org/wiki/Remote_code_execution https://www.google.com/search?q=Remote+code+execution

I may not have been clear -- I agree that RCE, unqualified, means unauthorized RCE. but then you said there was no such thing as an "authorized" RCE and that's where I beg to differ. Sure, the term isn't used much but it wasn't the clarifying point I wanted to make above, that there is a difference between authenticated and authorized. The links you point to there are about "RCE attack" which also implies not authori…

Your original post:

> in the introductory paragraph it reads "unauthenticated, targeted remote code execution ... I believe this means it was unauthorized, not unauthenticated.

You again:

> agree that RCE, unqualified, means unauthorized RCE

So you agree that your "unauthorized" qualification from your orignal post was unwarranted, since all unqualified RCE are unauthorized.

Now if you want to split hairs, you'll say "but the introductory paragraph said unauthenticated, which is qualified RCE, thus I am still right". ok then

Re: Timeline of the xz open source attack

#428

Post by simultsop »

pixl97 wrote: post #184
mseepgood wrote: post #7

Never allow yourself to be bullied or pressured into action. As a maintainer, the more a contributor or user nags, the less likely I am to oblige.

The issue here is the attackers will quickly move away from an individual attacking you to the group attacking you. The person writing the infected code will never be a jerk to you at all. You'll just suddenly see a huge portion of your mailing list move against you ever so slightly. We've complained about bots in social media for a long time, but how many people in open source discussions are shady manipulative enti…

This is so true, distrusting the guys never being jerk to you while others do is the hardest thing ever. Intentions will never be public :/

Re: Timeline of the xz open source attack

#429

Post by iso8859-1 »

carols10cents wrote: post #260
iso8859-1 wrote: post #146

Earlier quoted context omitted.

What about just using 'web of trust', for example with GPG? If the user's key is signed by people that met up with the actual person, it would be much harder to make fake identities.

What would prevent the sock puppet accounts from signing each others' keys?

They could do that, but you'd be able to see that nobody/few outside their cluster signed any of their keys.

Let's say they have fake passports and physically appear at key signing parties. Now you're screwed because even your peers (that you thought know how to validate identities using passports) will get fooled.

Read more on GPG's trust levels: https://www.gnupg.org/gph/en/manual/x334.html

Re: Timeline of the xz open source attack

#430

Post by rsc »

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

I don't think there's necessarily an assumption that it was Russia or China this time (the Chinese-sounding name is almost a dead giveaway that it's someone other than China), but the security world does believe quite strongly that it has been Russia (SolarWinds) and China (Juniper) before, so they are the usual examples.
Post reply on HN