Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Could the XZ backdoor been detected with better Git/Deb packaging practices?

optimizedbyotto.com

Post reply on HN
Print view View original

91–100 of 116 posts

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#91

Post by jiggawatts »

schuyler2d wrote: post #70
jiggawatts wrote: post #58

Earlier quoted context omitted.

Okay, how , could someone like Jia Tan sneak code into a codebase where commits can only be made by authenticated users with staff accounts on a private network? Versus… a random email offers to help, someone says “sure!”, and… that’s it. That’s the entire hurdle. Google did discover a Chinese hacker working for them on the payroll. That kind of thing does occur, but it’s rare. It’s massively harder and more risky.

Well, xz is a rare event too. There's no knowing how many backdoors were added by small network companies or contractors. But there's rarely accountability when it happens because the company would rather cover it up, or just not ask too many questions about that weird bug

> xz is a rare event too.

The discovery of the hack is rare, sure. Once a decade kind of thing.

The implication is that Jia Tan is a professional, and XZ was one of many irons on the fire.

Don’t be like Trump!

Don’t confuse positive tests with cases!

Jia Tan surely had many other attacks going.

Surely he’s not the only one.

Famously, there are two kinds of large organisations: those that have been hacked, and those that don’t yet know they’ve been hacked.

The open source community was the latter.

Now they’re the former.

Some of you all are still playing catch up.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#92

Post by array_key_first »

tedunangst wrote: post #63
kragen wrote: post #57

Earlier quoted context omitted.

I think the difference is that the undoubtedly numerous times that this has happened with Microsoft and other proprietary-software vendors, the users weren't in a position to find out.

Why not? This wasn't found by source review. The computer was slow, somebody looked into why. The bug was discovered via analysis of binary artifacts, and only then traced back to the source. Bruce Dawson does this all the time on Windows. https://randomascii.wordpress.com/category/uiforetw-2/

Proprietary software typically does everything within its power to stop you introspecting it.

Also, Windows is just suspicious in general. It's slow, everything makes network requests. Finding malware in Windows is a needle in a haystack. For some perspectives, Its all malware.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#93

Post by array_key_first »

jiggawatts wrote: post #91
schuyler2d wrote: post #70

Earlier quoted context omitted.

Well, xz is a rare event too. There's no knowing how many backdoors were added by small network companies or contractors. But there's rarely accountability when it happens because the company would rather cover it up, or just not ask too many questions about that weird bug

> xz is a rare event too. The discovery of the hack is rare, sure. Once a decade kind of thing. The implication is that Jia Tan is a professional, and XZ was one of many irons on the fire. Don’t be like Trump! Don’t confuse positive tests with cases! Jia Tan surely had many other attacks going. Surely he’s not the only one. Famously, there are two kinds of large organisations: those that have been hacked, and those t…

The main difference is that closed source software is not auditable, so when it is compromised you don't know.

It's safe to assume pretty much all the firmware you're running is vulnerable. It doesn't matter though, because you cannot find out.

The attackers can. You can't. And that's why we still have botnets.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#94

Post by dns_snek »

uecker wrote: post #77
bmandale wrote: post #73

Earlier quoted context omitted.

> even people who (rightly) hate the "curl | bash" combo. You could be running anything. That's true unless I audit every single line, out of potentially millions, in the source of a program I intend to run. If I'm going to do that, then I could audit the ./configure script as well.

This is missing the point. The issue with "configure" is that it is easy to hide malicious code in it because it is so arcane. The issue with "curl | bash" is that - on top - there is not even a proper trust chain and independent verification. "curl | bash" needs to die. Any project who promotes this does not care or does not understand security. "configure" was a necessary evil in the past with all commercial UNIX w…

> "curl | bash" needs to die. Any project who promotes this does not care or does not understand security.

Do you "understand security"? There's a grain of truth to what you're saying, but not more than that. The crux of this problem is with running untrusted binaries (or unreviewed source code) vs. installing something from a trusted repository.

The majority of people either don't know or don't care to review the source code. They simply run the commands displayed on the website, and whether you ask them to "curl | bash" or "wget && apt install ./some.deb" won't make any difference to their security.

Even if you do a "proper trust chain" and digitally sign your packages, that key is served through the same channel as the installation instructions and thus requires trust on first use, just like "curl | bash".

Unfortunately publishing every piece of software through every operating system's default repository isn't very realistic. Someone, somewhere is going to have to install the binary manually and "curl | bash" is as good of a method for doing that as any.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#95

Post by dijit »

acka wrote: post #85
dijit wrote: post #34

Earlier quoted context omitted.

thats not the issue, there will always be prebuilt binaries (hell, deb/rpm are prebuilt binaries). The issue for xz was that the build system was not hermetic (and sufficiently audited). Hermitic build environments that can’t fetch random assets are a pain to maintain in this era, but are pretty crucial in stopping an attack of this kind. The other way is reproducible binaries, which is also very difficult. EDIT: Wel…

My apologies: yes, I edited my comment to try and clarify that I did not mean executable binaries, but rather binary data, such as the test files in the case of XZ.

All good mate, your comment makes a better argument than the weaker one I interpreted it as prior to the edit.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#96

Post by 1970-01-01 »

rcxdude wrote: post #27
1970-01-01 wrote: post #20

>Can we trust open source software? Yes — and I would argue that we can only trust open source software. But should we trust it? No!! That's why we're here! I'm not satisfied with the author's double-standard-conclusion. Trust, but verify does not have some kind of hall pass for OSS "because open-source is clearly better." Trust, but verify is independent of the license the coders choose.

Yes, I would say that being able to view the source code and build it yourself is a necessary but not sufficient condition of properly trusting the software. (which is not quite the same thing as it being open source, but it's relatively rare outside of being a very big customer that you can do this for non-open-source code).

What does it matter if you are able to build it all by yourself if you still don't catch the compromised code? That's what is happening here in reality. OSS is now a layer of safety that is being leveraged into a layer of compromise. Caveat emptor!

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#97

Post by yencabulator »

simoncion wrote: post #32
rcxdude wrote: post #28

Earlier quoted context omitted.

It's not just the commit message, but the fact that it's a single commit with >100k lines changed (though, if that's just a merge commit, it might be not super unusual for that kind of workflow. Though big merge commits are a good place to hide things in git, given that they can introduce their own changes)

> It's not just the commit message, but the fact that it's a single commit with >100k lines changed When you diff the `bash-5.3` tag against the `bash-5.3-rc2` tag, the set of changes is reduced by a ton . It's the same story with previous release commits (at least for as far as I care to go back)... there's a "next version" branch that gets tagged with alpha, beta, and rc releases, and then there's a release commit…

Because historically, what's in a release tarball is not what's in the repository. In many cases, the release tarball of an old C/autoconf project has "half-built". Debian has always worked from the release tarballs, and thus if you "just" import Debian packaging into a VCS, you don't necessarily track every upstream commit, just the releases.

(Independently importing release tarballs into VCS also worked better in the era of a dozen competing VCSes, without reliable export-import pipelines.)

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#98

Post by jacquesm »

dataflow wrote: post #66
jacquesm wrote: post #51

Earlier quoted context omitted.

This is not going to be popular: I think the whole idea that a build system just fetches resources from outside of the build environment is fundamentally broken. It invites all kinds of trouble and makes it next to impossible to really achieve stability and to ensure that all code that is in the build has been verified. Because after you've done it four times the fifth time you won't be looking closely. But if you do…

> I think the whole idea that a build system just fetches resources from outside of the build environment is fundamentally broken I think your phrasing is a bit overbroad. There's nothing fundamentally broken with the build system fetching resources; what's broken is not verifying what it's fetching. Audit the package beforehand and have your build system verify its integrity after downloading, and you're fine.

xz.

nobody verifies all packages that are automatically downloaded all the time, unless there is a problem. We got lucky, that time.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#99

Post by uecker »

dns_snek wrote: post #94
uecker wrote: post #77

Earlier quoted context omitted.

This is missing the point. The issue with "configure" is that it is easy to hide malicious code in it because it is so arcane. The issue with "curl | bash" is that - on top - there is not even a proper trust chain and independent verification. "curl | bash" needs to die. Any project who promotes this does not care or does not understand security. "configure" was a necessary evil in the past with all commercial UNIX w…

> "curl | bash" needs to die. Any project who promotes this does not care or does not understand security. Do you "understand security"? There's a grain of truth to what you're saying, but not more than that. The crux of this problem is with running untrusted binaries (or unreviewed source code) vs. installing something from a trusted repository. The majority of people either don't know or don't care to review the so…

If people install random stuff from the internet, there is no security. That sometimes this is done is no reason to give up and teach people that "curl | bash" is even remotely ok. "curl | bash" is much worse than every other way to install things from the internet, because there is no guarantee that what one persons gets the same what anybody else gets, so any kind of chance to even discover a compromise is lost.

Re: Could the XZ backdoor been detected with better Git/Deb packaging practices?

#100

Post by dns_snek »

uecker wrote: post #99
dns_snek wrote: post #94

Earlier quoted context omitted.

> "curl | bash" needs to die. Any project who promotes this does not care or does not understand security. Do you "understand security"? There's a grain of truth to what you're saying, but not more than that. The crux of this problem is with running untrusted binaries (or unreviewed source code) vs. installing something from a trusted repository. The majority of people either don't know or don't care to review the so…

If people install random stuff from the internet, there is no security. That sometimes this is done is no reason to give up and teach people that "curl | bash" is even remotely ok. "curl | bash" is much worse than every other way to install things from the internet, because there is no guarantee that what one persons gets the same what anybody else gets, so any kind of chance to even discover a compromise is lost.

> because there is no guarantee that what one persons gets the same what anybody else gets, so any kind of chance to even discover a compromise is lost.

This applies to "curl | bash", "download an exe and run it", and everything in between equally. If a malicious binary wants to cover up its tracks it can just delete itself and disappear just like "curl | bash" would.

Feel free to educate users about the importance of installing software from trusted repositories whenever possible but demonizing "curl | bash" like it's somehow uniquely terrible is just silly and misses the point completely.

Post reply on HN