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

121–130 of 482 posts

Re: Timeline of the xz open source attack

#121

Post by jddil »

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 projects that cause nothing but stress.

Re: Timeline of the xz open source attack

#122

Post by Fnoord »

singularity2001 wrote: post #115
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…

You may want to read Kevin Mitnick on how (relatively) easy it is to infiltrate physical spaces.

Mitnick, at this point, has deceased.

Read up on red teaming and social engineering in general. Many more examples of red teaming are available, for example. I thoroughly enjoy these specific stories on Darknet Diaries podcast.

Re: Timeline of the xz open source attack

#123

Post by cesarb »

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.

> Far too many people, including developers, seem to just accept upgrades as always-good instead of carefully considering the risks and benefits.

Another example of this was log4j: if you were still using the old 1.x log4j versions, you wouldn't have been vulnerable to the log4shell vulnerability, since it was introduced early in the 2.x series. The old 1.x log4j versions had other known vulnerabilities, but only if you were using less common appenders or an uncommon server mode or a built-in GUI log viewer (!); the most common use of log4j (logging into a local file) was not exposed to any of these, and in fact, you could remove the vulnerable classes and still have a functional log4j setup (see for instance https://www.petefreitag.com/blog/log4j-1x-mitigation/ which I just found on a quick web search).

Did log4shell (and a later vulnerability which could only be exploited if you were using Java 9 or later, because it depended on a new method which was introduced on Java 9) lead people to question whether always being on the "latest and greatest" was a good thing? No, AFAIK the opposite happened: people started to push even harder to keep everything on the latest release, "so that when another vulnerability happens, upgrading to a fixed version (which is assumed to be based on the latest release) will be easy".

Re: Timeline of the xz open source attack

#124

Post by mattxxx »

A service that measured "credibility" or "activity" of a username/email could be really useful here. At least, it would be a leading indicator that something _might_ be up. In particular the aside here about the email addresses are suspect:

https://research.swtch.com/xz-timeline#jia_tan_becomes_maint...

would be useful info for Lasse Collins before taking the pressure campaign seriously.

Re: Timeline of the xz open source attack

#125

Post by oefrha »

kashyapc wrote: post #55
rsc wrote: post #45

Earlier quoted context omitted.

Open source fundamentally does not work that way. There are many important open source contributors who work pseudonymously. Google's Know, Prevent, Fix blog post floated the idea of stronger identity for open source in https://security.googleblog.com/2021/02/know-prevent-fix-fra... and there was very significant pushback. We learned a lot from that. The fundamental problem with stronger identity is that spy agencies…

While "open source" fundamentally doesn't work that way, the point here is about maintainers , not regular contributors. Identity of new maintainers must be vetted (via in-person meetups and whatever other mechanisms) by other "trusted" maintainers whose identities are "verified". I realize, it's a hard problem. (And, thanks for the link to the "Know, Prevent, Fix" post.) PS: FWIW, I "win my bread" by working for a c…

I’ve worked with a few very talented pseudonymous developers on the Internet over the years. I can’t think of any way to vet their identities while maintaining their anonymity (well, it’s basically impossible by definition), plus if you’re talking about in-person meetups, traveling from, say, Asia to North America isn’t cheap and there could be visa issues. The distinction between maintainers and non-maintainers isn’t that meaningful because non-maintainers with frequent and high quality contributions will gain a degree of trust anyway. The attack we’re discussing isn’t about someone ramming obviously malicious code through as a maintainer, they passed or could have passed code review.

Re: Timeline of the xz open source attack

#126

Post by sloowm »

edg5000 wrote: post #70

I wonder, once the attacker gained commit permissions, were they able to rewrite and force push existing commits? In that case rolling back to older commits may not be a solution. If my speculation is correct then the the exact date on which access was granted must then first be known, after that a trusted backup of the repo from before that date is needed. Ideally Lasse Collin would have a daily backup of the repo.…

The way the hack works is incredibly sophisticated and has specifically sought out how to get past all normal checks. If messing with some commits would be possible this entire rube goldberg hack would not have been set up.

Re: Timeline of the xz open source attack

#127

Post by [deleted] »

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.

[deleted]

Re: Timeline of the xz open source attack

#128

Post by cesarb »

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…

> As for why systemd links against xz, I don't know, and it's a bit surprising that an init system needs compression utils

It's for the journal. It can be optionally compressed with zlib, lzma, or zstd. That library had not only the sd_notify function which sshd needed, but also several functions to manipulate the journal.

Re: Timeline of the xz open source attack

#129

Post by lolinder »

riskable wrote: post #97
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…

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.

Funding all of these deep dependencies may have helped in this case but wouldn't address the root of the problem, which is that every business out there runs enormous amounts of unsandboxed third party code. Funding may have helped xz specifically from falling to pressure to switch to a malicious maintainer, but it does nothing about the very real risk that any one of the tens of thousands of projects we depend on has always been a long con.

The solution here has to be some combination of a dramatic cut back on the number of individual projects we rely on and well-audited technical solutions that treat all code—even FOSS dependencies—as potentially malicious and sandboxes it accordingly.

Re: Timeline of the xz open source attack

#130

Post by chubot »

JeremyNT wrote: post #117
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…

It's certainly a reasonable question to ask in this specific case. In hindsight Debian and Red Hat both bet badly when patching OpenSSH in a way that introduced the possibility of this specific supply chain attack. > If so, we should be proactively removing and locking down other dependencies, because it will likely be an effective and simple mitigation. I think this has always been important, and it remains so, but…

Yup, "trusted computing base" is classic concept that we've forgotten

Or we pay lip service to, but don't use in practice

Post reply on HN