XZ Utils Backdoor
en.wikipedia.org
XZ Utils Backdoor
1–10 of 23 posts
Re: XZ Utils Backdoor
#2This 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.
Re: XZ Utils Backdoor
#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
Re: XZ Utils Backdoor
#4This 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.
That's not unique to open source or open development.
Re: XZ Utils Backdoor
#5>While xz is commonly present in most Linux distributions,
Not Slackware since Slackware does not patch xz or many other utilities. Plus it does not use systemd. From what I remember a patch was put in to give systemd extra functionality and someone used that patch to sneak in the backdoor.
Re: XZ Utils Backdoor
#6Given this was backdoor was likely funded by a nation-state actor and very carefully obfuscated, the fact that it was discovered within a month and never rolled out to production releases, shows that the open source process mostly worked. Not saying it couldn't be better.
Re: XZ Utils Backdoor
#7>While xz is commonly present in most Linux distributions, Not Slackware since Slackware does not patch xz or many other utilities. Plus it does not use systemd. From what I remember a patch was put in to give systemd extra functionality and someone used that patch to sneak in the backdoor.
The xz attach happened cuz systemd's library dynamically linked against xz for compression of various tools in systemd and a downstream patch for openssh (IIRC) was used to link against libsystemd to use some founctions for the sd-notify protocol.
This wasn't exactly necessary since the protocol has been stable for external use for ages (since its inception IIRC) and is relatively trivial to implement.
Since the attack happened openssh gained native support for the sd-notify protocol, the sd-notify man page has an example implementation that is freely usable and libsystemd now only loads xz (and most of its other libraries) when explicitly requested by one of the tools via `dlopen`.
Re: XZ Utils Backdoor
#8This 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.
Re: XZ Utils Backdoor
#9Given this was backdoor was likely funded by a nation-state actor and very carefully obfuscated, the fact that it was discovered within a month and never rolled out to production releases, shows that the open source process mostly worked. Not saying it couldn't be better.
I kinda disagree. This was luck. A dev on an unrelated project happened upon it and was diligent enough to dig in. A single change to any number of variables would have meant disaster.
I worked at a company that got red teamed. The pen testers were inside the network and were only found by a random employee who happened to be running little snitch and got a weird pop-up
Nobody celebrated the fact that the intrusion was detected. It was pure luck, too late, and the entire infosec leadership was fired as a result.
Like this xv issue, none of the usual systems meant to detect this attack seemed to work, and it was only due to the diligence of a single person unrelated to the project was it not a complete show.
Re: XZ Utils Backdoor
#10This 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.
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.