What can be done to protect open source devs from next xz backdoor drama?
- Reference: 1712419934
- News link: https://www.theregister.co.uk/2024/04/06/register_kettle_xz/
- Source link:
An infected machine would have allowed someone with knowledge of the backdoor to gain remote control over the box via its SSH daemon. Though the dependency – [1]poisoned by a rogue contributor – made its way into some bleeding-edge or to-be-officially-released Linux distros, such as Debian Unstable, Fedora 40, and Fedora Rawhide, it was spotted and thwarted before being widely deployed, which could have been a disaster.
Is this an example of [2]open source fragility or strength? What can we do about securing popular bits of code that end up in tons of applications and servers? Do multi-billion-dollar corporations that feed off free work done by others need to step up and help here? Our [3]Kettle series is back for our journos to discuss exactly this, which you can watch below.
Joining the show this week is Thomas Claburn, who covered the xz near-fiasco for us; The Register 's cybersecurity editor Jessica Lyons; our editor Chris Williams; and your host Iain Thomson. This episode was produced by Brandon Vigliarolo.
As well as replaying our chat in the player above, you can listen via your favorite podcast distributor: [4]RSS and MP3 , [5]Apple , [6]Amazon , [7]Spotify , and [8]YouTube . And feel free to share your views too in the comments. ®
[9]
Get our [10]Tech Resources
[1] https://www.theregister.com/2024/03/29/malicious_backdoor_xz/
[2] https://www.theregister.com/2024/04/01/xz_backdoor_open_source/
[3] https://www.theregister.com/Tag/Kettle
[4] https://feeds.simplecast.com/Vnvf8Fkd
[5] https://podcasts.apple.com/us/podcast/the-register-kettle/id1713589041
[6] https://music.amazon.com/podcasts/fe62a659-3451-496b-b064-f30744c2ad65/the-register-kettle
[7] https://open.spotify.com/show/3SkH00VOX02KYNaAbYzajj
[8] https://www.youtube.com/watch?v=ltjMA7PLxdE
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZhHF96JkTn8Y9nKBaNVl7AAAAEg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[10] https://whitepapers.theregister.com/
> ... used by countless systems...
A bit of hype here, I think. It was found in releases used primarily for beta testing, which the article carefully failed to make clear.
Not to say it's not a problem, but it needs addressing, not hyping.
"carefully failed to make clear"
Task failed successfully.
Nice selective quoting there... the original says "ordinarily used by ..." meaning xz the package, not restricting it just to the compromised version.
> What can be done to protect open source devs from next xz backdoor drama?
1) Further strengthening the open-source motto of "It will be done when its done". Users need to be patient. Anyone applying pressure should possibly raise suspicion going forwards.
2) Reducing dependencies. Developers should not be afraid of writing new wheels that actually fit the problem. Too much crap, dragged in (especially from PIP/NPM/crates.io/CPAN) is just bad engineering. Open-source software has a real dependency issue.
3) systemd is bad engineering. Pulling everything into a mega-system, sprawling / entwining dependencies was predicted to be a bad idea. Ultimately this ended up being the case via the hooks into even well engineered software (OpenSSH).
> Do multi-billion-dollar corporations that feed off free work done by others need to step up and help here?
No. God no!
People keep saying "stop using so many dependencies" and never offer a real alternative, just "well why aren't you writing them all yourself?" which is logic so laughable even a 5 year old would question it. No, how about you write them all for me? Why don't you write my command argument parser? Why don't you write my serializer? Oh, and make sure they aren't buggy, ideally I'd like you to spend maybe 5 years on each of them to make sure they're flawless and have the features I want.
This cargo cult behavior is just because NPM made such a mess of things. One language's bad ecosystem is being used as an excuse to rant at everyone who wants to reuse code without any solutions, and it's pathetic and childish.
*Real* solutions I see are experiments where people turn libraries into WASM modules that are sandboxed by default. Ideally, all of a library's logic would be sealed in a sandbox and only it's I/O would be of any consequence, which is far simpler to constrain. I think there's even a Rust project that's doing this, I forget the name though.
People really need to stop this "stop reusing so much code" fallacy, it makes no sense and nobody will never listen to it.
> What can be done to protect open source devs from next xz backdoor drama?
Abandon devops. Bring sysadmins back.
Is this because sysadmins are justifiably paranoid, or that devs are typically narrowminded?
Open Source Quality Institutes
https://www.tbray.org/ongoing/When/202x/2024/04/01/OSQI
get the government to pay