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

101–110 of 116 posts

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

#101

Post by [deleted] »

tredre3 wrote: post #72
jart wrote: post #16

Folks have been ringing the alarm bell for a decade. https://www.nongnu.org/lzip/xz_inadequate.html xz is insane because it appears to be one of the most legitimately dangerous compression formats with the potential to gigafry your data but is exclusively used by literal turbonormies who unironically want to like "shave off a few kilobytes" and basically get oneshotted by it.

Turbonormies, as you say, tend to use gzip not xz. Which is sad because gzip is just as bad for archiving. A few bytes changed and your entire file is lost (in a .tar.gz it means everything is lost). Frankly, tarballs are an embarrassing relic, and it's not the turbonormies that insist they're still fit for purpose. They don't know any better, they'll do what people like you tell them to do.

[deleted]

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

#102

Post by jart »

Delk wrote: post #42
jart wrote: post #16

Folks have been ringing the alarm bell for a decade. https://www.nongnu.org/lzip/xz_inadequate.html xz is insane because it appears to be one of the most legitimately dangerous compression formats with the potential to gigafry your data but is exclusively used by literal turbonormies who unironically want to like "shave off a few kilobytes" and basically get oneshotted by it.

The question of whether the xz format is a good choice for long-term archival is entirely unrelated to backdoors or open source supply chain security.

No they're the same. Why do you think xz was targeted? It's a giant slippery hairball.

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

#103

Post by 1oooqooq »

acka wrote: post #31

I believe the XZ compromise partly stemmed from including binary files in what should have remained a source-only project. From what I remember, well-run projects such as those of the GNU project have always required that all binaries—whether executables or embedded data such as test files—be built directly from source, compiling a purpose-built DSL if necessary. This ensures transparency and reproducibility, both of…

how do you test your software can decompress files created with old/different implementations?

the exploit used the only solution for this problem: binary test payload. there's no other way to do it.

maybe including the source to those versions and all the build stuff to then create them programmatically... or maybe even a second repo that generates signed payloads etc... but its all overkill and would have failed human attention as the attack proved to begin with.

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

#104

Post by mananaysiempre »

dijit wrote: post #82
jacquesm wrote: post #54

Earlier quoted context omitted.

Focusing on the technical angle is imo already a step too far. This was first and foremost a social engineering exercise, only secondary a technical one.

this is very true, and honestly troubles me that it’s been flagged. Even I’m guilty of focusing on the technical aspects, but the truth is that the social campaign was significantly more difficult to understand, unpick and is so much more problematic. We can have all the defences we want in the world, but all it takes is to oust a handful of individuals or in this case, just one: or bribe them or blackmail them- then…

> I mean, we all just accept whatever the project believes is normal right?

Not in this thread we don’t? The whole thing has been about the fact that it wasn’t easy for a distro maintainer to detect the suspicious code even if they looked. Whether anyone actually does look is a worthy question, but it’s not orthogonal to making the process of looking not suck.

Of course, if we trust the developer to put software on our machine with no intermediaries, the whole thing goes out the window. Don’t do that[1]. (Oh hi Flatpak, Snap. Please go away. Also hi NPM, Go, Cargo, PyPI; no, being a “modern programming language” is not an excuse.)

[1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job....

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

#105

Post by uecker »

dns_snek wrote: post #100
uecker wrote: post #99

Earlier quoted context omitted.

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 o…

With a binary, one can compare a hash or store a copy on the binary on another computer. And one person doing this might be enough to figure out something is wrong. But even if people don't, it needs additional effort by the attacker to search for the binary and clean up their tracks, which also creates more opportunities for detection. It is really not at all comparable to "curl | bash". You sound like the people who told me two decades ago that reproducible builds are a waste of time.

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

#107

Post by 0rdinal »

aborsy wrote: post #106

Couldn’t the submission to the Debian be possible only under real identities so that people take responsibility for what they submit? A random person or group nobody has ever seen or knows submitted a backdoor.

1. How could Debian effectively verify an identity?

2. Some people may want to remain pseudonymous for legitimate reasons.

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

#108

Post by dns_snek »

uecker wrote: post #105
dns_snek wrote: post #100

Earlier quoted context omitted.

> 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 o…

With a binary, one can compare a hash or store a copy on the binary on another computer. And one person doing this might be enough to figure out something is wrong. But even if people don't, it needs additional effort by the attacker to search for the binary and clean up their tracks, which also creates more opportunities for detection. It is really not at all comparable to "curl | bash". You sound like the people wh…

> With a binary, one can compare a hash

You lift a suspected binary from a machine that's under suspicion. You hash it and it matches a known good file. You declare victory, pat yourself on the back, and return it back into service. 3 months later all of your data is exfiltrated because you assumed that your attacker is an idiot.

> it needs additional effort by the attacker to search for the binary

Additional effort:

    #include "stdio.h"
    #include "unistd.h"
    
    void main() {
      char path[512];
      readlink("/proc/self/exe", path, sizeof(path));
      unlink(path);
      printf("Poof, I disappeared from: %s\n", path);
    }
> You sound like the people who told me two decades ago that reproducible builds are a waste of time.

Except I wouldn't say that because these ideas are completely unrelated. Define your threat model and specify what problem you're trying to solve. Don't be the type of person who encrypts passwords because they heard that encryption is good for protecting data.

You demonized curl|bash because it "doesn't have a proper trust chain" and attacked the project for "not understanding security" with really weak arguments, now you're retreating all the way back to claim some fringe benefits to maybe-possibly discover the source of infection, and only if your attacker is lazy not to try to cover their tracks.

Continuing that argument like it's the same one you originally presented is quite a disrespectful way of wasting people's time: https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

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

#109

Post by aborsy »

0rdinal wrote: post #107
aborsy wrote: post #106

Couldn’t the submission to the Debian be possible only under real identities so that people take responsibility for what they submit? A random person or group nobody has ever seen or knows submitted a backdoor.

1. How could Debian effectively verify an identity? 2. Some people may want to remain pseudonymous for legitimate reasons.

It’s not straightforward.

The developers (at least important ones) could register with Debian project, just like they would with a company: submit identity and government documents, proof of physical address, bank account, credit card information, IdP account, .. It would operate like an organization.

The lead developers could meet and know each other through regular meetings. Kind of web of trust with in person verification. There are already online meetings in some projects.

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

#110

Post by simoncion »

yencabulator wrote: post #97
simoncion wrote: post #32

Earlier quoted context omitted.

> 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 t…

I think you're either confused, or have attached your comment to the wrong parent?

My observations and questions were about the GNU bash git repo and how (and why) the bash maintainers do release branching and tagging. They were not about how the Debian folks handle their packaging.

Post reply on HN