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

81–90 of 116 posts

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

#81

Post by normie3000 »

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).

> 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.

And certainly a condition of the "verify" step?

With closed-source software, you can (almost) _only_ trust.

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

#82

Post by dijit »

jacquesm wrote: post #54
mananaysiempre wrote: post #47

Earlier quoted context omitted.

First of all, even if that were true, that wouldn’t have much to do with hermetic builds as I understand the term. You could take the release tarball and build it on an air-gapped machine, and (assuming the backdoor liked the build environment on the machine) you would get a backdoored artifact. Fetching assets from the Internet (as is fashionable in the JavaScript, Go, Rust, and to some extent Python ecosystems) doe…

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 nobody is going to be reviewing because everybody believes that it has been reviewed.

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

It’s not like we’re pushing our ideas of transparency on the projects… and even if we were, it’s not like we are reviewing them either they will have their own reviewers and the only people left are package maintainers who are arguably more dangerous.

There is an existential nihilism that I’ve just been faced with when it comes to security.

unless projects become easier to reproduce and we have multiple parties involved in auditing then I’m a bit concerned.

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

#83

Post by rcxdude »

1718627440 wrote: post #46
johnny22 wrote: post #45

Earlier quoted context omitted.

many folks make a distinction between source available and open source.

The latter meaning: accepts patches, or what?

Accepting patches isn't a requirement, but it roughly means that you can make your own changes, publish those changes, and use the software for whatever you want. These don't automatically come with being allowed to view the source code.

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

#84

Post by TheDong »

jiggawatts wrote: post #79
TheDong wrote: post #52

Earlier quoted context omitted.

> Something that the XZ back door made me realise is that the fundamental difference between proprietary and open source software is not the price or source availability for most of its users — no not developers! - it is the reputation and protected brand of the former and the anonymity of the latter. You're making a distinction not between open source and proprietary software but rather between hobbyist and corporat…

Some fair points, but: > hobbyist and corporate software. OpenSSL was maintained by like two guys in their spare time, and underpinned trillions of dollars worth of systems and secure transfers. Would you categorise that as “hobbyist”? The semantics matter, so I’m going to agree with you and clarify that my concern is with the risks associated with “effectively anonymous contributors allowed” software, where personal…

Okay, so you won't use OpenSSL because it's not proprietary enough. What do you use instead?

You pay for nginx plus? Oops, that uses openssl. F5 load balancers since you want to get even more proprietary and expensive? Some of those used OpenSSL too.

Microsoft IIS? Lemme tell you about the history of absolutely bafflingly bad vulnerabilities in that software, far worse than open source nginx ever had.

Effectively anonymous contributions are not what caused heartbleed, they're not what caused the vast majority of breaches and hacks into proprietary software companies nor the vast majority of vulnerabilities.

Bad code is what causes these bugs, and as far as I can tell, the easiest recipe to bad vulnerable code is to have a manager repeatedly tell an engineer "deliver this by friday or you're fired", which happens much less in free software projects.

I'm just trying to get a coherent idea of what you think the right thing to do here is.

How do I stay secure? What OS do I use that doesn't include a ton of open source components and reviews every line of code that goes into it? As far as I can tell, this has already excluded ChromeOS (based on open source packages, many imported without reading all the LoC), macOS (even worse, and an even greater history of vulnerabilities)... I guess windows is the best by this standard? But statistically it's also the most vulnerable, so it doesn't seem like this standard has gotten us to a logical conclusion, does it?

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

#85

Post by acka »

dijit wrote: post #34
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…

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.

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

#86

Post by dessimus »

jiggawatts wrote: post #50

Something that the XZ back door made me realise is that the fundamental difference between proprietary and open source software is not the price or source availability for most of its users — no not developers! — it is the reputation and protected brand of the former and the anonymity of the latter. We have no clue who “Jia Tan” is, a name certain to be a pseudonym. Nobody has seen his face. He never provided ID to a…

Something like this has happened in the proprietary world: the SolarWinds supply chain attack. IIRC, they were releasing breached versions for about a year, and I think it became known only when the US Government came knocking on SolarWinds door. SolarWinds potentially vetting every employee through HR had zero effect on preventing a supply chain attack.

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

#87

Post by [deleted] »

jiggawatts wrote: post #58
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.

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.

[deleted]

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

#88

Post by XorNot »

Groxx wrote: post #39
sanjams wrote: post #19

Earlier quoted context omitted.

I agree, but perhaps OP is suggesting that the hand-crafted data can be generated in a more transparent way. For example, via a script/tool that itself can be reviewed.

could have, absolutely. should not have been in any commit , which is basically necessary to prevent this case, almost definitely not. it's normal, and requiring all data to be generated just means extremely complicated generators for precise trigger conditions... where you can still hide malicious data. you just have to obfuscate it further. which does raise the difficulty, which is a good thing, but does not make i…

It would be reasonable for error case data though to be thoroughly explained, and it must be explainable since otherwise what are you testing and why does the test exist?

The xz exploit depended on the absence of that explanation but accepting that it was necessary for unstated reasons.

Whereas it's entirely reasonable to have a test that says something like: "simulate an error where the header is corrupted with early nulls for the decoding logic" or something - i.e. an explanation, and then a generator which flips the targeted bits to their values.

Sure: you _could_ try inserting an exploit, but now changes to the code have to also surface plausible data changes inline with the thing they claim is being tested.

I wouldn't even regard that as a lot of work: why would a test like that exist, if not because someone has an explanation for the thing they want to test?

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

#89

Post by jacquesm »

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…

Autotools is a hot mess. Anything complex is going to be a rich environment for exploits of all kinds. The more silent the exploit the bigger the chance that it will spread widely.

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

#90

Post by goodpoint »

crote wrote: post #30
goodpoint wrote: post #21

Earlier quoted context omitted.

The author is incorrect. Keeping the packaging files under git is done out of convenience but it does not help for security and reproducibility. The packages uploaded in Debian are what matters and they are versioned.

And how are you supposed to verify that the right packages have been uploaded? The easiest way to verify that is by using a reproducible automated pipeline, as that moves the problem to "were the packaging files tampered with". How do you verify the packaging files? By making them auditable by putting them in a git repository, and for example having the packager sign each commit. If a suspicious commit slips in, it'l…

Actually the uploads in Debian are signed and the build process is reproducible and audited.

Distros do not need to update packages on each and every upstream commit.

Post reply on HN