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

361–370 of 482 posts

Re: Timeline of the xz open source attack

#361

Post by somat »

nathell wrote: post #83
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…

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…

I see this as sort of the pivot on how people choose an open source license. When you feel like you are building the thing for others use a gplish license, it has all sorts of clauses around getting everyone to play nice. Building the thing for yourself however, I think the bsd style license makes more sense. you don't really care what anyone else is doing with it, you don't want to form a community. however, because it is trivial to share source code, you do so.

Re: Timeline of the xz open source attack

#362

Post by jsnell »

qerti wrote: post #293
gregwebs wrote: post #203

I think this can be made much more difficult by enforcing a policy of open builds for open source. It shouldn't be possible to inject build files from a local machine. All build assets should come from the source repository. Artifacts should come from Github Actions or some other tool that has a clear specification of where all inputs came from. Perhaps Github could play a role in helping to automate any inconvenienc…

Wasn’t the payload in a blob in the tests, which is in the source repo? If you were to clone the repo then build from source, you’d have the backdoor, right? Surely distros aren’t using binaries sent by maintainers

No. The payload was in the checked in test files, but the test files were inert. They were only activated by the tarball having different build files than the repository (or rather, different build files than would be generated by autotools for the repository), which extracted the payload from the test files and injected it into the output binary.

Re: Timeline of the xz open source attack

#363

Post by shp0ngle »

Did the Jia Tan character actually committed something of value? Looking at the history, he had (there was some stuff with multithreaded compression/decompression); as he kept it in the original license, could it be used going forward?

Re: Timeline of the xz open source attack

#364

Post by naikrovek »

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…

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.

Re: Timeline of the xz open source attack

#365

Post by mcpherrinm »

kevindamm wrote: post #42
mcpherrinm wrote: post #35

Earlier quoted context omitted.

I think it is unauthenticated from the point of view of SSH’s own authentication. The backdoor has its own credential, but the RCE is accessible if you don’t have an account on the system.

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.

The distinction between authentication and authorization is important, but only in the context of what’s checking that auth(n/z) is valid.

For something like SSH which has authentication and authorization as features, I would expect to talk about an RCE in that context, and not the backdoor’s auth features.

This backdoor bypasses both authentication (not requiring an account password, authorized key, etc on the target system) as well as authorization (as it doesn’t check a user against any policy for what commands or users can log in).

Re: Timeline of the xz open source attack

#366

Post by dmitrygr »

Solvency wrote: post #201

Why does it seem like so many open source developers suffer from chronic mental health issues? as shown here, in TempleOS, etc. It's a weird but sad pattern I see all of the time.

Not being paid for your work while others profit from it surely doesn’t help with one’s mental state.

Re: Timeline of the xz open source attack

#367

Post by testplzignore »

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.

I'm not familiar with how distros get the source code for upstream dependencies. I'm trying to understand what Andres meant when he said this:

> One portion of the backdoor is solely in the distributed tarballs

Is it that the tarball created and signed by Jia had the backdoor, but this backdoor wasn't present in the repo on github? And the Debian (or any distro) maintainers use the source code from tarball without comparing against what is in the public github repo? And how does that tarball get to Debian?

Re: Timeline of the xz open source attack

#368

Post by Hackbraten »

pixl97 wrote: post #276
TacticalCoder wrote: post #206

Earlier quoted context omitted.

> There are a whole lot of binary test cases in software. That's not how I read GP's point. If even binary blobs in test cases are a place where backdoors are, now as a matter of fact, hidden then, certainly, among the folks advocating for binary drivers in FOSS, there are some who are already --or planning to-- add backdoors there. Binary blobs are all terrible, terrible, terrible ideas. Builds should be 100% reprod…

Then you figure out how to build a 'source' test case of a bad zip, or bad jpg, or word document or whatever else exists out there. Also figure out how to test that your bit4bit perfect binary isn't doing the wrong damned thing in your environment with actual real data.

In cryptography, there's the concept of a nothing-up-my-sleeve number. [1]

Instead of obscure constants, you use known constants, or at least simple methods to derive your constants.

You can do the same thing to come up with your test cases. Bad zip? Construct a good zip of 10 files, each containing the first 10,000 prime numbers. Then corrupt the zip by seeking to position (100/pi) and write a thousand zeroes there.

Bad JPEG? Use Imagemagick to render the first 1000 prime numbers as text into a JPEG file, then apply a simple nothing-up-my-sleeve corruption operation.

There are still cases where this approach isn't going to work: that new icon, helpfully proposed by a contributor, meant to be used in production, might contain malicious code, steganographically embedded. I think there's little you can do to prevent that.

[1]: https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

Re: Timeline of the xz open source attack

#369

Post by cryptonector »

mseepgood wrote: post #20
jhoechtl wrote: post #16

> merges hidden backdoor binary code well hidden inside some binary test input files. [...] Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves. So much for the folks advocating for binary (driver) blobs in OSS t support otherwise unsupported hardware. It's either in source form and reproducable or it's not there.

Not just for hardware support: https://github.com/serde-rs/serde/issues/2538

!!

Re: Timeline of the xz open source attack

#370

Post by ant6n »

sebstefan wrote: post #133
apantel wrote: post #113

Earlier quoted context omitted.

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

> If they want things done quickly they can do it themselves

I mean they kind of did. And that was the problem.

Post reply on HN