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

281–290 of 482 posts

Re: Timeline of the xz open source attack

#281

Post by [deleted] »

lmkg wrote: post #268
maerF0x0 wrote: post #258

Two points I'd be interested in discussing. 1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired ma…

Regarding point 1: The timeline in the linked article describes some communications as "pressure emails." I've heard the theory, but haven't seen solid evidence, that the pressure emails weren't just regular impatience from outside devs, but actually part of the attack . To convince the primary maintainer into granting access to another party.

[deleted]

Re: Timeline of the xz open source attack

#282

Post by PUSH_AX »

maerF0x0 wrote: post #258

Two points I'd be interested in discussing. 1. It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way (and selected for their access). Why play the long game of let's find a lone package, w/ a tired maintainer, and then try to get in good with them vs. Let's survey all packages w/ a tired ma…

> It seems a lot of people are assuming Jia Tian was compromised all along. I haven't seen a reason to believe this was a long play, but rather that they were compromised along the way

So I assume Jia has spoken out since? How do you go this long without realising someone else is making plays as you?

Re: Timeline of the xz open source attack

#283

Post by j1elo »

Fnoord wrote: post #239
ceejayoz wrote: post #175

Earlier quoted context omitted.

So becoming an open source maintainer will involve an in-person trip to an interrogation? The xz attack involves, in significant part, a maintainer burned out and happy to accept offered help. I don't think making it substantially harder to receive genuine help is likely to improve the situation.

I just wanted to bring up that technique (it is not unique to CIA; LE also uses it). I never asserted the technique would've been useful in this very situation. However, in your framing you ignored the option of video conferencing. Also, you are forgetting bringing up 'are you trying to pull xz to me?' is a yellow flag towards the person who said it. It isn't definite, it just makes people raise up, it gathers the at…

I made the original comment and must say that it was only meant as a joke. But, maybe some cases would merit using it.

This is of course based on the fact of how the xz attack needed a couple of apparently innocent community members to start being too pushy, to the point of almost bullying the author and pointing fingers to their supposed passivity towards maintaining the project.

To some levels of such behavior, after all that has happened, one could reasonably (even if just jokingly) wonder if it's not a similar attempt. IMO, being framed as a possible attacker would probably either calm the shit out of some too entitled users, or provoke them into even more whining.

Now seriously, there is the thing about attitude that I wish was more popular among FOSS maintainers in order to have a mentally healthy relationship with their role: the ability to work on their own terms and not forget even for a split second that this is all a hobby activity. That FOSS licenses are explicitly written to allow A LOT of freedoms such as hiring 1st or 3rd party support services, forking, or whatever else but not to demand anything from the author.

Re: Timeline of the xz open source attack

#285

Post by RedShift1 »

wongarsu wrote: post #241
hyperman1 wrote: post #221

Earlier quoted context omitted.

Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…

Most of these could still be covered with IO limited to the project files though. There is a sizable movement in the Rust ecosystem to move all build-time scripts and procedural macros to (be combined to) WASM. This allows you to write turing-complete performant code to cover all use-cases people can reasonably think of, while also allowing trivially easy sandboxing. It's not perfect, for example some build scripts d…

How does the sandboxing help if the compiler and/or build scripts or whatever modifies its own output?

Re: Timeline of the xz open source attack

#286

Post by comex »

wongarsu wrote: post #241
hyperman1 wrote: post #221

Earlier quoted context omitted.

Java's Maven is an interesting case study, as it tried to be this:. A standard project layout, a standard dependency mechanism, pom.xml as standard metadata file, and a standard workflow with standard target(clean/compile/test/deploy). Plugins for what's left. There might have been a time where it worked, but people started to use plugins for all kinds of reasons, quite good ones in most cases. Findbugs, code coverag…

Most of these could still be covered with IO limited to the project files though. There is a sizable movement in the Rust ecosystem to move all build-time scripts and procedural macros to (be combined to) WASM. This allows you to write turing-complete performant code to cover all use-cases people can reasonably think of, while also allowing trivially easy sandboxing. It's not perfect, for example some build scripts d…

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 could have played to sneakily inject code.

I’d argue that Rust’s biggest advantage here is that build scripts and procedural macros are written in Rust themselves, making them easier to read and thus harder to hide things in than autotools’ m4-to-shell gunk.

But that means it’s important to build those things from source! Part of the movement you cite consists of watt, which ships proc macros as precompiled WebAssembly binaries mainly to save build time. But if watt were more widely adopted, it would actually make an attacker’s life much easier since they could backdoor the precompiled binary. Historically I’ve been sympathetic to dtolnay’s various attempts to use precompiled binaries this way (not just watt but also the serde thing that caused a hullabaloo); I hate slow builds. But after the xz backdoor I think this is untenable.

Re: Timeline of the xz open source attack

#287

Post by tamimio »

Aurornis wrote: post #87
sebstefan wrote: post #69

Maybe one of the outcomes of this could be a culture change in FOSS towards systematically banning rude consumers in Github issues, or, just in general, a heightened community awareness making us coming down on them way harder when we see it happen.

The attackers will leverage any culture that helps them accomplish their goals. If being rude and pushy doesn’t work, the next round will be kind and helpful. Don’t read too much into the cultural techniques used, because the cultural techniques will mirror the culture at the time.

Spot on. The counter should be sound regardless of any social or cultural context, a process where being polite or rude, pushy or not is irrelevant.

Re: Timeline of the xz open source attack

#288

Post by nebulous1 »

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…

In "Ghost in the Wires" Kevin Mitnik details one of the ways he obtained information was via a law enforcement receptionist* who he managed to trick into believing he was law enforcement over the phone. He obtained information this way multiple times over multiple years, and fostered a phone based friendship with this woman. He seemed to have no qualms in doing this.

He was also turned on by multiple people who he considered close friends. In the book it did not seem that he had considered that it might not be a "them" problem.

*my details may be off here, I read it some time ago

Re: Timeline of the xz open source attack

#289

Post by TheKarateKid »

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.

About a decade ago, the industry shifted from slow, carefully evaluated infrequent updates (except for security) to frequent, almost daily updates that are mandatory. I'd say this was pioneered by the Chromium team and proved to be beneficial. The rest of the industry followed.

Now we're in a position where most projects update so quickly, that you don't really have a choice. If you need to update one component, there's a good chance it will require that many more as dependencies in your project will require an update to be compatible.

The industry as a whole sacrificed stability and some aspects of security for faster advancements and features. Overall I'd say the net benefit is positive, but its times like these that remind us that perhaps we need to slow things down just a little and do a bit of a course correction to bring things into a better balance.

Re: Timeline of the xz open source attack

#290

Post by jodrellblank »

coldpie wrote: post #196
jodrellblank wrote: post #157

Earlier quoted context omitted.

> " It's not a perfect solution " Is it a solution at all? Say Oracle offer Lasse Collin $200k for maintaining xz but he doesn't want to work for Oracle so he refuses, then what? Amazon offer Lasse $200k but they require fulltime work on other open source packages which he isn't experienced with or interested in, so he refuses, then what? Google employ someone else for $200k but they can't force Lasse Collin to hand…

I think you've misunderstood my suggestion. I said the job has two responsibilities. No more. You added a bunch of other responsibilities, I'm saying those wouldn't be allowed. It would be in the employment agreement that is purely payment for doing the maintainership tasks they were already doing. It would be a culture expectation that the company not apply pressure on maintainers. > but if they just employ 'open so…

Leaving aside issues of how it could work, Lasse Collin wasn't the one who saw this attack and stopped it so how would paying him have helped against this attack?

> "Lasse would suggest Tan as a suitable replacement. Big Company's hiring pipeline would approach Tan and start the hiring process (in person interviews, tax docs, etc etc). At some point they would realize Tan isn't a real person and not hire him"

What if they find that Tan is a real person but he doesn't want to work for Amazon or legally can't (This is before knowing of his commits being malicious, we're assuming he's a fake profile but he could be a real person being blackmailed)? Collin can't leave? Collin has to pick someone else out of a candidate pool of people he's never heard of? Same question if they find Tan isn't a real person - what then; is there an obligation to review all of Tan's historical commits? Just committing under a pseudonym or pen name isn't a crime, is it? Would the new maintainer be obliged to review all historic commits or audit the codebase or anything? Would Amazon want their money back from Lasse once it became clear that he had let a bad actor commit changes which opened a serious security hole during his tenure as maintainer?

> "No. Not doing the maintenance tasks would make everyone mad, violating one of the two job responsibilities."

What he was doing already was apparently ignoring issues for months and making people like Jigar Kumar annoyed. Which is fine for a volunteer thing. If "Jigar Kumar" is a sock-puppet, nobody knew that at the time of their posts; Lasse Collins' hypothetical employer wouldn't have known and would surely be on his case about paying him lots of money for maintenance while complaints are flowing on the project's public mailing list, right? Either they're paying him to do what he was doing before (which involved apparently ignoring work and making some people mad) or they're paying him to do more than he was doing before (which is not what you said).

It doesn't seem like it would work - but if it did work it doesn't seem like it would have helped against this attack?

Post reply on HN