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

131–140 of 482 posts

Re: Timeline of the xz open source attack

#131

Post by dugite-code »

jddil wrote: post #121
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…

Never understood why our industry seems unique in our willingness to do unpaid work for giant corps. Your compression library isn't saving the world, it's making it easier for amazon to save a few bucks. You have the right to be paid for your time. It's valuable. I enjoy coding too... but the only free coding I do is for myself. Use a proper license, charge for your time and stop killing yourself doing unpaid hobby p…

> why our industry seems unique in our willingness to do unpaid work for giant corps.

Because it never starts that way. It scratches an itch, solves an interesting puzzle and people thank and praise the work. Deep down we all want to be useful, and it helps that it looks great on a résumé.

After it's established the big corps come along, but the feeling of community usefulness remains. It's also why so many devs burn themselves out, they don't want to disapoint.

Re: Timeline of the xz open source attack

#132

Post by chubot »

duped wrote: post #116
chubot wrote: post #103

Something to add to the timeline: when did this avenue of attack become available? It only happened in the last 10 years apparently. Why do sshd and xz-utils share an address space? When was the sshd -> systemd dependency introduced? When was the systemd -> xz-utils dependency introduced? --- To me this ARCHITECTURE issue is actually bigger than the social engineering, the details of the shell script, and the details…

I don't think these questions are that interesting. SSHD shared an address space with xz-utils because xz utils provides a shared library, and that's how dynamic linking works. sshd uses libsystemd on platforms with systemd because systemd is the tool that manages daemons and services like sshd, and libsystemd is the bespoke way for daemons to talk to it (and more importantly, it is already there in the distro - so y…

and that's how dynamic linking works -- really ignorant comment

Read the lobste.rs thread for some quotes on process separation and the Unix philosophy.

There are mechanisms other than dynamic linking -- this is precisely the question.

Also, Unix supported remote logins BEFORE dynamic linking existed.

---

What about sshd didn't work prior to 2015?

Was the dependency worth it?

not particularly surprising given the kitchen sink architecture of systemd

That's exactly the point -- does systemd need a kitchen sink architecture?

---

The questions are interesting because they likely lead to simple and effective mitigations.

They are interesting because critical dependencies on poorly maintained projects may cause nation states to attack single maintainers with social engineering.

Solutions like "let's create a Big tech funded consortium for security" already exist (Linux foundation threw some money at bash in 2014 after ShellShock).

That can be part of the solution, but I doubt it's the most effective one.

Re: Timeline of the xz open source attack

#133

Post by sebstefan »

apantel wrote: post #113
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 Jia Tan character was never rude. If you make rudeness the thing that throws a red flag, then ‘nice’ fake accounts will bubble up to do the pressuring.

Pressuring the maintainer is already rude in itself and being polite about it won't help them

If they want things done quickly they can do it themselves

Re: Timeline of the xz open source attack

#134

Post by kevindamm »

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.

What makes you say that? SSH, RDP, even hitting a web service are all valid cases of authorized remote code execution. It's not the remote or execution parts that are bad.

Re: Timeline of the xz open source attack

#135

Post by BuildTheRobots »

xyst wrote: post #108

Timeline reads like a "pig butchering" or romance scam. Except the goal is not money, but control. Attackers find a vulnerable but critical library in the supply chain. Do a cross check on maintainers or owners of the code (reference social media and other sources to get more information). Execute social engineering attack. Talk to maintainer(s) "off list" to gain rapport. Submit a few non-consequential patches that…

I'm amazed more people aren't talking about the "off list" part or asking Colin if he's willing to provide those emails/conversations.

Re: Timeline of the xz open source attack

#136

Post by stockhorn »

I feel like release tarballs shouldnt differ from the repo sources. And if they do, there should be a pipeline which generates and upload the release artifacts....

Can somebody write a script which diffs the release tarballs from the git sources for all debian packages and detects whether there are any differences apart from the files added by autotools :)?

Re: Timeline of the xz open source attack

#137

Post by sigmar »

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.

That would be true if you could ban the person from using new emails, but I don't think that's true when the thread if rife with sock puppet accounts. You ban the first rude email account, then there will be 2 new accounts complaining about both the lack of commits and the "heavy-handed mailing-list moderation" stifling differing views.

Re: Timeline of the xz open source attack

#138

Post by sloowm »

chubot wrote: post #103

Something to add to the timeline: when did this avenue of attack become available? It only happened in the last 10 years apparently. Why do sshd and xz-utils share an address space? When was the sshd -> systemd dependency introduced? When was the systemd -> xz-utils dependency introduced? --- To me this ARCHITECTURE issue is actually bigger than the social engineering, the details of the shell script, and the details…

Another point relevant on the timeline is when downstream starts using binaries instead of source.

I think people are flying past that important piece of the hack. Without that this would not have been possible. If there is a trusted source in the middle building the binaries instead of the single maintainer and the hacker this attack becomes extremely hard to slip by people.

Re: Timeline of the xz open source attack

#139

Post by nindalf »

delfinom wrote: post #85
tommiegannert wrote: post #29

Earlier quoted context omitted.

The Jigar Kumar nudges are so incredibly rude. I would have banned the account, but perhaps they contributed something positive as well that isn't mentioned. I wonder if it would be possible to crowdsource FOSS mailing list moderation.

Yea people are too accepting of allowing asshats like the Jigar messages. Simple ban and get the fuck out. Too often I've dealt with people trying to rationalize it as much as "o its just cultural, they don't understand". No, get the fuck out. But hey I'm a NYer and telling people to fuck off is a past time.

Jigar was the same person/group as Jia. They were the bad cop and Jia was the good cop. Banning wouldn't have changed anything. Even if Jigar had been banned, the maintainer would still have appreciated the good cop's helpful contributions in contrast to the unhelpful bad cop. Jia would have become a maintainer anyway.

Re: Timeline of the xz open source attack

#140

Post by duped »

chubot wrote: post #132
duped wrote: post #116

Earlier quoted context omitted.

I don't think these questions are that interesting. SSHD shared an address space with xz-utils because xz utils provides a shared library, and that's how dynamic linking works. sshd uses libsystemd on platforms with systemd because systemd is the tool that manages daemons and services like sshd, and libsystemd is the bespoke way for daemons to talk to it (and more importantly, it is already there in the distro - so y…

and that's how dynamic linking works -- really ignorant comment Read the lobste.rs thread for some quotes on process separation and the Unix philosophy. There are mechanisms other than dynamic linking -- this is precisely the question. Also, Unix supported remote logins BEFORE dynamic linking existed. --- What about sshd didn't work prior to 2015? Was the dependency worth it? not particularly surprising given the kit…

I don't think it's acceptable to create a subprocess for what's effectively a library function call because it comes from a dependency.

The problem is the design of rtld and the dynamic linking model, where one shared library can detect and hijack the function calls of another by using the auditing features of rtld. Hardened environments already forbid LD_PRELOAD for injection attacks like this, but miss audit hooks.

My point is that just saying we should use the Unix process model as the defense for supply chain attacks is like using a hammer to fix a problem that needs a scalpel.

> What about sshd didn't work prior to 2015?

systemd notifications, from what it sounds like.

Post reply on HN