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

401–410 of 482 posts

Re: Timeline of the xz open source attack

#401

Post by ajoberstar »

sloowm wrote: post #138
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.

That's not what happened. Downstream was building from source, that source just had malicious code in it.

One part was binary, the test file (pretty common), but checked into the repo. One part was in the build config/script, but was in the source tarball and not in the repo.

Re: Timeline of the xz open source attack

#402

Post by rstuart4133 »

naikrovek wrote: post #364
tadfisher wrote: post #347

Earlier quoted context omitted.

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…

reproducible builds never made sense to me. if you trust the person giving you the hash, just get the binary from them. you don't need to reproduce the build at all. if you trust that they're giving you the correct hash, but not the correct binary, then you're not thinking clearly.

Actually, this xz-utils was a sort of reproducible build issue. But the twist it is wasn't the binary not built reproducibly. It was the tar ball. The natural assumption is it just reflected the public git repository. It didn't.

Debian's response is looking to be mandating the source must come from the git repository, not a tar ball. And it will be done using a script. And the script must produce the same output every time, ie be reproducible. Currently Debian's idea of "reproducible" means it reflects the source Debian distributes. This change means it will reproducibly reflect the upstream sources. That doesn't mean it will be the same - just that it's derived in a reproducible way.

As for trusting the person who gave you the hash: that's not what it hinges on. It hinges on the majority installing a binary from a distro. That binary can be produced reproducibly, by an automated build system. Even now, Debian's binaries aren't created just once by Debian. There are Debian builders all around the planet creating the binary, and verifying it matches what's being distributed.

Thus the odds of the binary you are running not being derived from the source are vanishingly low.

Re: Timeline of the xz open source attack

#403

Post by psanford »

cryptonector wrote: post #352
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.

What's inscrutable code? Was it m4 or sh or the combination of the two? Who will pay for all the rewriting you want done? Or even just for the new frameworks that are "scrutable"? How do we guarantee that the result is not inscrutable to you or others? There is so much knee-jerking in this xz debacle. (And I say this / ask these questions with no love for autoconf/m4/sh.)

I think this is pretty straight forward. Don't accept PRs for code that cannot be reasoned about easily.

Re: Timeline of the xz open source attack

#404

Post by dralley »

ok123456 wrote: post #236
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.

People have been bullied out of 'nice' communities. See the 'Actix' debacle in Rust.

While I don't condone some of the treatment he received, that situation was extremely different.

A user reported a safety issue, the maintainer said it was safe. Then it was proven that it was in fact unsafe, and the maintainer justified it with performance. Then a PR was filed which was safe and did not regress performance, and the maintainer rejected it with "this patch is boring"

The behavior of both sides was deeply unacceptable. If someone identifies a legitimate issue and files a PR to fix it, don't insult them by calling the patch "boring" and don't reject it solely on that basis.

Re: Timeline of the xz open source attack

#405

Post by pabs3 »

2devnull wrote: post #149
jrochkind1 wrote: post #31

This seems very difficult to defend against. What is a project with a single burnt-out committer to do?

Check the GitHub profile of anybody that commits. Is there a photo of the person? Can you see a commit history and repos that help validate who they seem to be. In this instance, noticing the people emailing to pressure you have fake looking names that start with adjacent letters and the same domain name. Be more paranoid.

Only non-paranoid people have a photo of themselves online.

Re: Timeline of the xz open source attack

#406

Post by berniedurfee »

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.

There was definitely good cop/bad cop going on. That’s a really powerful psychological tool.

Re: Timeline of the xz open source attack

#407

Post by berniedurfee »

pixl97 wrote: post #166
nathell wrote: post #83

Earlier quoted context omitted.

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…

Not just nation state actors. All that data is available to anyone with a credit card from legit data dealers.

Re: Timeline of the xz open source attack

#408

Post by deathanatos »

__float wrote: post #230
deathanatos wrote: post #198

> Evan Boehs observes that Jigar Kumar and Dennis Ens both had nameNNN@mailhost email addresses This is the second time I've read this "observation", but this observation is just wrong? Jigar's email is "${name}${number}@${host}", yes, but Dennis's is just "${name}@${host}" — there's not a suffixed number. (There's a 3, but it's just a "leetcode" substitution for the E, i.e., it's semantically a letter.) (They could…

Where are the email addresses visible? I've also seen this a few times, but never the actual addresses.

In the OP, many of the links (e.g., "first, innocuous patch") lead to mail-archive.com. From there, click the button with the name that appears after "Reply via email to", and it will open your email client, with the To: filled in with the email of the person.

Re: Timeline of the xz open source attack

#409

Post by mmcwilliams »

matsur wrote: post #267
__float wrote: post #230

Earlier quoted context omitted.

Where are the email addresses visible? I've also seen this a few times, but never the actual addresses.

eg "Hans Jansen" is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

I'm maybe naive in assuming that there is some kind of investigation going on that isn't playing out in public, but I would assume that years of emails going through Microsoft servers might make the identities of the cohorts in this attack difficult to hide?

Re: Timeline of the xz open source attack

#410

Post by duped »

kibwen wrote: post #395
duped wrote: post #360

Earlier quoted context omitted.

What would that accomplish? It certainly wouldn't have stopped this attack. > 99.9% of all projects have the capability to be built with trivial declarative rulesets. Only if you forbid bootstrapping, which all projects ultimately rely on at some point in their supply chain.

> What would that accomplish? It certainly wouldn't have stopped this attack. We could write an entire PhD thesis on the number of dire technical failings that would need to be addressed to stop this attack, so while this alone wouldn't have stopped it, it would have required the actor to come up with another vector of code injection which would have been easier to find. > Only if you forbid bootstrapping Codebases t…

Concretely, what security issues are solved by forcing the build specification language to be Turing incomplete? My guess is the answer is "none."

At worst, you're actually creating more holes. The reason autoconf/automake exist and M4 scripts are innocuous in the first place is because the build system uses an underpowered language and developers have to turn to code generation to get around it.

If you kneecap the build system's language you're not solving problems. You're creating them.

> it would have required the actor to come up with another vector of code injection which would have been easier to find.

If make was standardized and could programmatically determine the environment its run under and write full programs then the attack vector wouldn't exist in the first place.

> Codebases that bootstrap are the 0.1%.

We have different experiences, because ime it's close to 100% especially when you include transitive dependencies. When you care about supply chain security you care about being able to bootstrap from sources for your code and all your dependencies, and it's almost guaranteed that one of your dependencies needs to be bootstrapped.

Post reply on HN