Live data from Hacker News

XZ Utils Backdoor

en.wikipedia.org

11–20 of 23 posts

Re: XZ Utils Backdoor

#11

This really illustrates a broad security issue with open source development and methodology. Who vets contributors, maintainers and submissions? Answer: Unknown in many (if not most) cases. Unless you have the time and expertise to do so yourself; it is purely based on trust.

Contributors and their submissions are vetted by maintainers. New maintainers are ideally vetted by existing maintainers. This can obviously break down in undermaintained projects.

New maintainers are ideally vetted by existing maintainers

This ideal obviously did not happen here.

And there are no consequences for those who fail to do so.

Re: XZ Utils Backdoor

#12

Earlier quoted context omitted.

That's not unique to open source or open development.

Anonymity is the unique aspect of open source that opens the door for malicious activity without consequences.

Well, no; there's plenty of proprietary software without a human name attached (let alone a name that you could possibly verify is real), and there are FOSS projects that only take contributions from people who have identified themselves in some capacity.

Re: XZ Utils Backdoor

#13
The behemoth that is autotools mostly helped to conceal the backdoor (and contributed to the payload)

It's an old legacy technology that needs to die out from all forms of distributions (looking at you GNU)

Re: XZ Utils Backdoor

#14
post #3

> The Debian development team declined to remove the affected images, stating that they were development builds that should not be used on real systems in place of newer, clean container versions. Classic Debian security management

Not that I approve the Debian decision here, but calling it "classic" seems a bit of a stretch?

Do you have many more examples to call that a "classic" Debian security behaviour?

Re: XZ Utils Backdoor

#15

Earlier quoted context omitted.

Anonymity is the unique aspect of open source that opens the door for malicious activity without consequences.

Well, no; there's plenty of proprietary software without a human name attached (let alone a name that you could possibly verify is real), and there are FOSS projects that only take contributions from people who have identified themselves in some capacity.

Well, no; there's plenty of proprietary software without a human name

A human name is not required for legal accountability.

A human name is required in order to be legally employed.

None of this applies to open source in many (if not most) cases --- the subject one being an example.

Re: XZ Utils Backdoor

#17

Earlier quoted context omitted.

Well, no; there's plenty of proprietary software without a human name attached (let alone a name that you could possibly verify is real), and there are FOSS projects that only take contributions from people who have identified themselves in some capacity.

Well, no; there's plenty of proprietary software without a human name A human name is not required for legal accountability. A human name is required in order to be legally employed. None of this applies to open source in many (if not most) cases --- the subject one being an example.

My point was more that there's plenty of software that is not FOSS and is also not published by an identifiable legal entity, traditionally appearing as freeware/shareware for Windows/macOS. And even if there does appear to be some sort of legal entity (human or company), how many people are going to check that a company even exists on paper before installing the random .exe from its website?

Re: XZ Utils Backdoor

#18
post #3

> The Debian development team declined to remove the affected images, stating that they were development builds that should not be used on real systems in place of newer, clean container versions. Classic Debian security management

Not that I approve the Debian decision here, but calling it "classic" seems a bit of a stretch? Do you have many more examples to call that a "classic" Debian security behaviour?

Like this: https://jblevins.org/log/ssh-vulnkey ?

Re: XZ Utils Backdoor

#19

Earlier quoted context omitted.

Well, no; there's plenty of proprietary software without a human name attached (let alone a name that you could possibly verify is real), and there are FOSS projects that only take contributions from people who have identified themselves in some capacity.

Well, no; there's plenty of proprietary software without a human name A human name is not required for legal accountability. A human name is required in order to be legally employed. None of this applies to open source in many (if not most) cases --- the subject one being an example.

There's tons of utter garbage commercial software. There's commercial software with intentionally built in backdoors and information stealing. Most of it gets zero accountability, nor do the sites that distribute it, nor the ad networks that find viewers for it.

Just like there's basically no reputational harm anymore for leaking all your users details for most leaks

Re: XZ Utils Backdoor

#20

Earlier quoted context omitted.

Well, no; there's plenty of proprietary software without a human name A human name is not required for legal accountability. A human name is required in order to be legally employed. None of this applies to open source in many (if not most) cases --- the subject one being an example.

My point was more that there's plenty of software that is not FOSS and is also not published by an identifiable legal entity, traditionally appearing as freeware/shareware for Windows/macOS. And even if there does appear to be some sort of legal entity (human or company), how many people are going to check that a company even exists on paper before installing the random .exe from its website?

My point was more that there's plenty of software that is not FOSS and is also not published by an identifiable legal entity

Yes, installing any software of "unknown origin" is a gaping security hole --- whether FOSS or not.

The fact that some people do dumb stuff does not negate the fact that a lot (if not most) FOSS fits in this category. Anonymous maintainers and contributors is pretty normal operating procedure which equates to zero accountability.

The common retort is, "Well, the source is available for review". But as this example shows, this is a very weak indicator of security or safety. A review is often not done before (or even after) distribution --- and certainly not with a malicious actor in charge.

Post reply on HN