Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

Post reply on HN
Print view View original

211–220 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#211

Post by bombcar »

chpatrick wrote: post #72
mrkramer wrote: post #64

Earlier quoted context omitted.

So did he plan all this from the beginning or somewhere down the line he went full yolo?! I am looking at his mailing chat[0] and he seemed pretty enthusiastic about improving and fixing XZ. [0] https://www.mail-archive.com/search?l=xz-devel@tukaani.org&q...

I mean if I was working for a state and had the job of compromising xz that's exactly what I would do.

From what I've seen (and I've not seen much, mind you) - someone went through and carefully categorized various libraries by the ability to be injected into OpenSSH on the target systems AND those that were lightly maintained, if at all.

xz was the winner, but there are likely others that could have been used.

Re: What we know about the xz Utils backdoor that almost infected the world

#212

Post by 01HNNWZ0MV43FF »

growse wrote: post #161
binkHN wrote: post #59

Earlier quoted context omitted.

> 4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane. I couldn't agree more. Coming from the BSD world, systemd is a shock to the system; it's monstrous and has tendrils everywhere.

If you actually come from BSD, you'd hopefully recognize a set of different utilities combined to form a holistic system released under a single name. It's not a new idea. Besides, the gpp is incorrect: systemd dependencies are not needed for initialisation notifications.

I think there's a low-effort solution to GP: Just split off the notification function for now.

There's a dilemma here: Make a huge number of tiny libraries and people complain about left-pad. Make a monolith and this type of attack can happen. If left-pad is more preventable, let's go that way. The fact that C and C++ have tons of overhead in producing a package is their problem to deal with through better tooling.

Re: What we know about the xz Utils backdoor that almost infected the world

#213

Post by bombcar »

markus_zhang wrote: post #184
michaelsbradley wrote: post #180

Earlier quoted context omitted.

Next logical step in this misguided way of thinking: “do a great service to the world by subverting open source software until maintainers get their due”. No, the ends do not justify the means.

Sometimes good ends can ONLY be brought by bad means. Like, realistically, how would you convince the Forbes 500 to increase spending on software security? They won't budge if no one is knocking the doors. In general, it is in human nature that we prefer to mend the situation as late as possible, as long as it is not too late, instead of curing a disease before it develops. People who do the first thing are praised a…

The result will be Fortune 500 companies spending millions and billions on "Security Companies" who pocket the money and produce lots of paperwork absolving everyone of any form of blame, whilst the actual maintainers will still get a can of diet code and a misspelt acknowledgment somewhere.

Re: What we know about the xz Utils backdoor that almost infected the world

#214

Post by zouhair »

AshamedCaptain wrote: post #69

Why do they say "almost" infected the world? At least 3 quite popular Linux distributions (arch, gentoo, and opensuse tumbleweed) ended up shipping the backdoor _for weeks_ , and it was most definitely working in at least tumbleweed. For weeks! A backdoored ssh! Hardly "almost".

Also, what about those that are not yet discovered?

Re: What we know about the xz Utils backdoor that almost infected the world

#215

Post by evandale »

XorNot wrote: post #104
farmdve wrote: post #51

Earlier quoted context omitted.

Which to me is a very carefully orchestrated thing. You don't just spend 2 years of your life doing that. No loner would pre-plan this to such an extent and create sockpuppet accounts for all this.

That's because you're a normal, well adjusted person. Consider TempleOS[1] which was created by a programmer having a series of manic episodes which he believed was God's instruction to create 640x480 pixels of perfection. He spent the rest of his life on this. People vastly underestimate the tenacity of individual fixated people: so much so that in the physical world victims usually feel isolated by their peers who…

TempleOS feels a little different because Terry was fairly well-known in the community and didn't try to hide his identity. I'm pretty sure he went to conferences and has met with actual people who could verify his identity.

I haven't seen proof that Jia Tan is a real person and to me that's the most malicious part of the attack. I'm pretty confident that whoever is hiding behind the Jia Tan identity is a well adjusted individual (or group) and knows exactly what they're doing. It feels far too coordinated and careful to chalk up to a psychotic episode or manic behavior.

Re: What we know about the xz Utils backdoor that almost infected the world

#217

Post by saulpw »

thiht wrote: post #182
mapasj wrote: post #11

I’m guessing the original maintainer of xz handed responsibilities to Jia Tan without ever seeing him/her or at least sharing a phone call. Is that common to only communicate only through email/github? I guess some maintainers of open source projects will be more cautious after this story.

What does it change? Assuming that either: - Jia Tan was initially a trustworthy actor that subsequently became malicious (maybe they were paid or compromised somehow) - Jia Tan was always malicious, but played the long game by starting with legitimate contributions/intent for 1-2 years How would meeting them for real have any impact?

If you look at their early commit history, "Jia Tan" was always a devious actor.

It's easy to think that they would just have made a video call, but it is a lot harder to lie convincingly over sync videochat than over async text. And a lot harder still to lie in person, and esp over multiple meetings.

Not to say it's impossible, people get scammed in person all the time! But it raises the bar, for sure.

Re: What we know about the xz Utils backdoor that almost infected the world

#218

Post by smikesix »

humansareok1 wrote: post #130

This represents a massive failure of the Open Source model and it's worth thinking carefully about as more and more people advocate for fully open source AI models. People could spend a lot of time on token safety features only to have them backdoored by a sneaky PR and it's not clear what level of damage this could cause in the near future.

thats not an issue with open source, but an issue with trust and structure. in closed source it can also happen and it would be even harder to spot, since you have no clue what is going on and there would be maybe 1-2 ppl in the whole world that could identify that issue.

with open source anyone can. the joke is that he found it because the ssh login felt too long. this dude needs a medal.

what needs to be controlled are system relevant libraries that open up such possibilites and also not including not code data into builds. any binary blob is bad, anything that cant simply be read is bad. if you put in code, ppl will control it and most of the time see what it does.

but if you hide the real code in a binary blob, such files should not be included in builds, but shipped separately

Re: What we know about the xz Utils backdoor that almost infected the world

#219

Post by belthesar »

binkHN wrote: post #59
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

> 4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane. I couldn't agree more. Coming from the BSD world, systemd is a shock to the system; it's monstrous and has tendrils everywhere.

I read recently that systemd does not recommend that you link to libsystemd to participate in systemd-notify message passing. The API for talking to it is quite simple, and vendors are encouraged to implement a compliant interface rather than loading all of libsystemd into your program to manage this. This of course would mean maintaining your own compliant interface as API changes happen, which is likely why it isn't done more frequently. It seems to me that there would be a lot of value in systemd stubbing out libraries for the various functions so that dependent projects could link to the specific parts of systemd it needs. That, or some other way to configure what code gets load when linking libsystemd. Full disclosure, I've not looked at libsystemd to see if this is already possible or if there are other recommendations by the project.

Re: What we know about the xz Utils backdoor that almost infected the world

#220

Post by MichaelZuo »

sophacles wrote: post #100
kuschku wrote: post #78

Earlier quoted context omitted.

> Re the falsifying working hours, wouldn’t these boffins be able to automate Git commits at certain times or even pass instructions to another team who is working the late night shift to post these changes etc. Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies. You'd basically have to have a team of devs working at really od…

> Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies. What sort of nonsense is this? Have you ever actually known any software developers? A huge number of them keep odd hours, moreso in the infosec sphere. They wouldn't need to automate anything, just start working hours that match the timezone that they're faking... If it re…

I would have to agree with kushku, it’s a very very high bar to fake thousand of timestamps over several years in a consistent way that doesn’t attract suspicion under forensic scrutiny.

Of course this is post facto so not that helpful until after something serious happens.

If there was some sort of reputation system that could do this analysis automatically then that would be very useful.

Post reply on HN